Skip to content
BTC · Lightning · Self-hosted BTCPay

Bitcoin Web Hosting
without a processor in between.

Most "Bitcoin hosting" providers accept BTC through a third-party processor that sees both sides of the transaction. We run our own BTCPay Server with our own Bitcoin and Lightning nodes. The transaction flow is direct: your wallet to ours.

Quick answer

Bitcoin web hosting describes infrastructure where the customer pays for service using BTC instead of fiat. Quality providers run their own BTCPay Server (open-source self-hosted payment infrastructure) and Bitcoin Core full node, so no third-party processor sits between customer and provider. Lightning Network handles small payments (~€100 or less) with instant settlement and sub-cent fees. On-chain BTC settles in 30-60 minutes with three confirmations. Pricing is identical to fiat payment methods. No KYC required. About 50% of our crypto-paid invoices are in BTC.

Key facts about Bitcoin web hosting

  • BTCPay Server: Open-source, self-hosted, BIP21-compatible payment processor. Maintained by the BTCPay Server Foundation. Used by us and other operators who want non-custodial BTC acceptance (btcpayserver.org).
  • Lightning Network: Layer-2 protocol on Bitcoin enabling instant near-zero-fee payments. Per the Wikipedia article on Lightning Network, the network has grown to thousands of nodes and millions in capacity.
  • Confirmation time: On-chain settles in ~30-60 minutes (three confirmations). Lightning settles in seconds.
  • Fees: On-chain fees fluctuate with mempool congestion (typically €0.50-€5 for a hosting invoice). Lightning fees are typically under one cent regardless of amount up to channel capacity.
  • Customer share at ASH: 50% of crypto-paid invoices are BTC. The rest split between XMR (25%), stablecoins (15%), and other altcoins (10%).
  • Lightning channels: Our node maintains approximately 50 channels with major routing nodes (LNBIG, ACINQ, Bitfinex, Bitrefill, OpenNode). Capacity sufficient for typical invoice volume.
  • Refund policy: Standard refund window applies regardless of payment method. BTC refunds require customer-provided refund address since on-chain BTC does include source address visibility but stored payment addresses are not retained.
  • Privacy properties: BTC is pseudonymous, not anonymous. Chain analysis can deanonymize transactions. For privacy-grade use cases, Monero is structurally stronger than Bitcoin.

The operational difference between processor-based and self-hosted BTC acceptance

Most providers that advertise "Bitcoin hosting" are using a third-party payment processor. The processor maintains its own Bitcoin infrastructure, generates invoice addresses, watches the chain for incoming transactions, and notifies the hosting provider when payment arrives. Common processors historically have included BitPay, Coinbase Commerce, NowPayments, Blockonomics, and several smaller services. Each processor has different terms, fee structures, and KYC requirements.

The structural problem with processor-based acceptance is that the processor knows both sides of the transaction. The processor's records link your identity to the hosting provider's identity. The processor's compliance posture is shaped by its banking relationships, which are subject to regulatory pressure that the underlying Bitcoin protocol is not. Several processors have been forced to introduce KYC for amounts that previously flowed without identity verification. Several have been forced to discontinue service to certain merchant categories. Several have been forced to share customer data with tax authorities under jurisdictional pressure.

BTCPay Server is open-source self-hosted infrastructure that replicates the functionality of a payment processor without the third-party intermediation. The provider runs BTCPay on their own server. The BTCPay instance interfaces with a Bitcoin Core full node (also self-hosted) that is connected to the Bitcoin peer-to-peer network. Customer BTC payments flow from the customer's wallet directly to addresses derived from the provider's wallet, watched by the BTCPay/Bitcoin Core stack. No third party has visibility into the transaction beyond what the public blockchain already exposes.

We made the decision to run BTCPay rather than use a processor because the privacy properties of the chain are weakened by adding a processor. Bitcoin is already pseudonymous, not anonymous. Adding a processor that maintains a KYC database mapping wallet addresses to customer identities makes the deanonymization easier rather than harder. For our customer base, this was a non-starter. The operational cost of running BTCPay is real but acceptable given what it preserves.

BTC payment infrastructure comparison: processor vs self-hosted

PropertyThird-party processorSelf-hosted BTCPay
CustodyProcessor holds funds initiallyProvider holds directly
KYC requiredOften above thresholdsNever (no processor)
PrivacyProcessor links sender to recipientOnly chain visibility
Fees0.5-2% processor feeOnly Bitcoin network fees
Confirmation speedProcessor decidesProvider controls
Fiat conversionOften automaticOptional, at provider discretion
Regulatory exposureSubject to processor's regulatorsSubject only to provider's jurisdiction
Lightning NetworkSome processors offer itDirect node integration
Setup complexityLow (API integration)High (full node + BTCPay)
Operational costPer-transaction feeServer + maintenance overhead

What Lightning Network adds and where it falls short

The Lightning Network is a second-layer protocol that allows Bitcoin payments to settle quickly and with low fees by routing through a network of payment channels that are periodically anchored to the on-chain Bitcoin blockchain. For small payments, Lightning is operationally superior to on-chain BTC because confirmation is near-instant and fees are typically under one cent regardless of the payment size.

For hosting payments, Lightning is most useful for invoices under €100. The customer scans a Lightning invoice (or uses LNURL or BOLT11), the payment settles in seconds, and the service activates immediately. There is no waiting for on-chain confirmation. The user experience is more like a credit card payment than a Bitcoin payment.

For invoices over €100, the economics of Lightning get more complicated. Lightning channels have limited capacity. A channel with €500 of capacity can receive up to €500 in payments before the channel needs to be rebalanced (which happens off-chain through the network) or closed and reopened with fresh capacity (which is an on-chain transaction). Large payments through Lightning require either large channels (expensive to open) or routing through multiple hops (which has reliability issues).

We accept Lightning for invoices up to roughly €100 reliably. We accept on-chain BTC for any size. Customers paying for entry-level VPS service typically use Lightning. Customers paying for dedicated servers or annual contracts typically use on-chain.

Our Lightning node has approximately 50 channels with major Lightning routing nodes (LNBIG, ACINQ, Bitfinex, Bitrefill, OpenNode, and similar). Channel capacity is sufficient for our typical invoice volume. We rebalance channels through Lightning-native rebalancing techniques and occasionally through on-chain channel opens or closes when imbalance accumulates.

What "no KYC" means at the Bitcoin payment layer

Many Bitcoin-accepting services have introduced KYC requirements above certain thresholds. The thresholds vary by service and jurisdiction. Some services require KYC for any payment above $1,000. Some require it above $10,000. Some require it for all payments and use the chain-analysis layer to associate addresses with identities passively.

We do not require KYC for any Bitcoin payment we accept. The signup process requires only an email address and a payment method. The payment method is your Bitcoin wallet, which we do not associate with any identity data. The BTC arrives at our wallet, the invoice settles, the service activates. We do not ask for your name, address, government ID, or business registration. The same is true for all our payment methods, not just BTC.

The "no KYC" property is structural to how we operate, not a feature we have applied selectively. We do not have a KYC database to apply. We do not have a compliance team that would process the KYC. We have made the deliberate choice to not collect this data, which means we cannot reveal what we do not have. This is the operational consequence of the privacy posture we built the business around.

The Bitcoin economy and operational continuity

A meaningful share of our customer base operates within the Bitcoin economy in some way. They sell goods or services for BTC. They hold BTC as a primary store of value. They prefer to transact in BTC rather than convert to fiat. For this segment, paying for hosting in BTC is not a political statement or a privacy measure. It is the path of least resistance.

These customers typically have BTC available in their operational wallets and do not maintain large fiat balances. They pay vendors in BTC. They receive payment in BTC. The conversion friction works against fiat-only providers more than it works against BTC-accepting ones. We are the BTC-accepting provider in their stack.

The use cases within this segment vary widely. Cryptocurrency exchanges (small-to-medium, not the major centralized ones) hosting on us because their primary banking relationships are with crypto-friendly banks that we already work with. Bitcoin podcast networks paying for streaming infrastructure. Lightning Network service operators paying for the servers that host their Lightning infrastructure. Crypto wallet providers hosting their non-custodial wallet UI. Hardware wallet companies hosting their firmware update servers and customer support tooling.

For these customers, the value proposition of our service is not "we accept Bitcoin" because that is the baseline. The value is that we accept Bitcoin competently (self-hosted, fast Lightning, reasonable confirmation requirements, no surprise compliance), the underlying hosting is operationally serious, and we understand the customer's threat model.

What our Bitcoin-paying customers actually run on us

The workloads our BTC-paying customers run on us span several categories.

Cryptocurrency-related content and tools

Bitcoin media sites, exchange comparison sites, wallet review sites, mining calculator sites. The content is legal in any jurisdiction we operate in, but the businesses are sometimes denied service by mainstream hosts due to "high-risk" classifications inherited from payment processor taxonomies. We do not classify customers this way.

Bitcoin and Lightning service infrastructure

Lightning routing nodes that need uptime guarantees, merchant payment processors hosting BTCPay instances for their own customers, exchange backends, mining pool servers. These are infrastructure-intensive workloads that need real hosting, not just shared hosting with a Bitcoin payment option.

Email infrastructure for crypto-related senders

Newsletter publishers covering crypto markets, transactional email for crypto applications, customer support tooling. The email infrastructure is our primary specialty and the Bitcoin payment is a convenience for the customer profile.

General hosting paid in BTC for unrelated reasons

The fourth category is general web hosting for customers who happen to pay in BTC for unrelated reasons (jurisdictional convenience, privacy preference, currency control workaround). The hosting workload is generic web hosting. The Bitcoin acceptance is what made us their choice over alternatives.

How pricing works with volatile cryptocurrency

Our pricing is denominated in EUR. The Bitcoin amount you owe at any given moment is calculated from the EUR price using our self-hosted crypto rates feed, which fetches from CoinGecko every thirty minutes and caches the result. When you generate an invoice, the rate locks for sixty minutes. You have that window to send the BTC.

If the price moves significantly between when you locked the invoice and when you send the payment, your transaction will either over-pay or under-pay relative to the current spot rate. We treat both conditions reasonably. If you over-pay by a small amount, we credit the excess to your account balance. If you under-pay by a small amount, we still settle the invoice if the underpayment is within our tolerance (typically 2%). For larger discrepancies, we contact you to discuss.

The recommended pattern for customers with predictable hosting needs is to maintain an account credit balance in BTC. You pre-pay a larger BTC amount, the balance shows on your account in BTC and EUR equivalents, and monthly invoices draw down. This pattern minimizes transaction overhead and avoids the operational complexity of timing individual payments to market conditions.

For customers who do not want to hold a BTC balance with us (which is reasonable because we are a hosting provider not a custodial wallet), the alternative is timing payments close to invoice due dates. The system tolerates this. Invoices are generated approximately seven days before the due date, leaving a window for payment that does not require precise timing.

Bitcoin vs Monero for hosting: when each makes sense

The choice between paying in BTC versus XMR for hosting is mostly about threat model and operational preference.

Bitcoin makes sense when: you already hold BTC operationally, your threat model does not include sophisticated chain analysis, you value Lightning Network's instant settlement for small payments, you want the broader liquidity and exchange availability that BTC offers.

Monero makes sense when: your threat model includes any financial surveillance, you want privacy as a default property rather than an opt-in, you anticipate that the link between your identity and hosting could become valuable to an adversary, you operate in jurisdictions where banking with crypto-related vendors is itself a flag.

Many of our customers use both. They pay smaller routine invoices in BTC via Lightning for convenience, and they use Monero for the privacy-grade signup payment or for larger annual contracts where the privacy properties matter more.

Related operational reading