Self-Hosting BTCPay Server for Bitcoin Payment Processing

We have been accepting cryptocurrency payments at ASH since 2022. The initial setup ran on BitPay’s hosted service. The costs and operational characteristics did not align with our business model long-term. We migrated to self-hosted BTCPay Server in mid-2022 and have been operating it in production since.

This post documents what we built, what the operational reality is, and what the alternative would have cost. The economics work for specific operator profiles. The technical complexity is bounded but real.

Why we considered the migration

Our initial BitPay setup worked but had specific issues for our business model.

Cost economics

BitPay charged 1% per transaction. For our transaction volumes (approximately €4,000-€8,000 monthly in cryptocurrency receipts at the time), the 1% fee was €40-80 per month. The absolute cost was modest but the percentage represented direct margin erosion.

Self-hosted alternatives charge no processing fees beyond network costs. The savings compound at higher volumes.

Custodial concerns

BitPay holds funds during transactions before settlement. The custodial period is brief but creates dependency. If BitPay had operational issues, our payment processing would be affected.

Self-hosted alternatives are non-custodial. Payments go directly to our wallet without intermediary custody.

Brand positioning

We sell privacy and self-hosting to customers. Operating customer-facing payment processing through a hosted service that requires KYC compliance creates a positioning inconsistency.

Self-hosted payment processing aligns better with the broader brand positioning.

Geographic considerations

Some of our customer base has interactions with BitPay limited by jurisdictional considerations. Customers in specific regions face limited service from hosted providers.

Self-hosted infrastructure is jurisdictionally flexible.

The combination of factors made the self-hosted alternative attractive for our specific situation.

What BTCPay Server is

BTCPay Server is an open-source Bitcoin payment processor that operators run on their own infrastructure. It connects to a Bitcoin node, generates payment addresses for customers, monitors the blockchain for incoming payments, and notifies the operator when payments arrive.

The architecture includes:

• A Bitcoin full node (Bitcoin Core or compatible)
• NBXplorer (for blockchain monitoring)
• The BTCPay Server application
• Optional Lightning Network Daemon for Lightning payments
• A database (PostgreSQL typically) for application state

The operator runs all components. No third-party service involvement.

The setup process

The initial setup took approximately two weeks of careful work.

Week 1: Infrastructure and node sync

Server provisioning. A dedicated server with adequate resources:

• 32GB RAM
• 8 CPU cores
• 2TB NVMe storage (for Bitcoin blockchain plus operational overhead)
• Good network connectivity

Operating system setup. AlmaLinux 9 with standard hardening for our environment.

Bitcoin Core installation and initial blockchain sync. The full sync took approximately 24-36 hours given good network conditions and storage performance.

Various supporting services (PostgreSQL, nginx, system monitoring) installed and configured.

Week 2: BTCPay configuration

NBXplorer installation and configuration to connect with Bitcoin Core.

BTCPay Server installation. The official deployment options support various configurations; we chose the Docker-based deployment for operational consistency with our other infrastructure.

BTCPay initial configuration:

• Store creation for our ASH brand
• Wallet configuration with watch-only XPub from our hardware wallet
• Lightning Network Daemon setup
• Authentication and access control
• Notification setup

Test transactions to verify the end-to-end flow worked correctly.

Integration with our internal customer management system through BTCPay’s webhook API.

After week 2: Production transition

Gradual customer migration from BitPay to BTCPay. New customers started on BTCPay; existing customers transitioned over several weeks as their renewal cycles came up.

After two months of parallel operation, BitPay was retired completely.

The operational characteristics

After two years of production operation:

Reliability

The infrastructure has operated reliably with bounded issues. Specific operational events over two years:

• One brief outage during a server migration (planned, with customer communication)
• One Bitcoin node sync issue requiring manual intervention (4 hours of degraded service)
• Several minor BTCPay version upgrades (operational but bounded)
• Approximately monthly routine maintenance windows

The cumulative downtime over two years is approximately 30 hours. The uptime equates to roughly 99.85%.

Cost economics

Direct operational costs:

• Server hosting: €120/month
• Domain and SSL: €15/year
• Operational time: approximately 5-8 hours per month average

Total monthly cost: approximately €130/month plus operational time.

Comparable BitPay cost at our current volumes: approximately €200-400/month in processing fees plus the same operational time (the operational complexity does not disappear with hosted services; it transfers to integration management).

The economics favor self-hosted by 30-60% on direct costs at our volumes.

Customer experience

From the customer’s perspective, the payment flow is essentially identical to BitPay or other Bitcoin processors. Customer initiates payment, scans QR code or copies address, sends Bitcoin, receives confirmation.

Lightning Network payments complete in seconds rather than the 10+ minute Bitcoin on-chain confirmations. Lightning is preferred by most of our customers for amounts under €500.

For on-chain Bitcoin payments, our service activation happens within 1 confirmation (approximately 10 minutes) for small amounts and 3 confirmations (approximately 30 minutes) for larger amounts.

Integration complexity

The integration between BTCPay and our customer management system is webhook-based. BTCPay fires webhooks when invoices are paid; our system receives the webhooks and activates customer services.

The integration is bounded but requires operational discipline. The April 2026 post-mortem on the BTCPay webhook issue documents one specific incident; the integration has been otherwise reliable.

What works well

Two years of production use reveal what works well in this setup.

Direct settlement

Payments arrive directly in our wallet. No custodial intermediary. The “not your keys, not your coins” principle is satisfied.

Lightning Network adoption

Lightning Network has proven valuable for smaller payments. The instant settlement and low fees produce better customer experience than on-chain Bitcoin for typical transaction sizes.

Custom branding

The BTCPay checkout pages are customized with our branding. Customers see ASH-branded payment flows rather than generic third-party processor branding.

Privacy alignment

The operational privacy aligns with our brand positioning. We are not generating extensive transaction data at a third-party processor that could be subpoenaed or breached.

Cost predictability

Operating costs are predictable. The fixed server cost and bounded operational time provide budget certainty unlike percentage-based processing fees that scale with revenue.

Open source advantages

The BTCPay codebase is open source. Issues can be debugged at the code level if needed. Customizations are possible. The community produces ongoing improvements.

Lightning routing

Our Lightning node has accumulated reasonable routing capability over two years. Some of our outbound Lightning costs are offset by routing fee revenue from being a useful intermediary node.

What is operationally demanding

Some aspects require ongoing operational discipline.

Blockchain synchronization

The Bitcoin blockchain grows continuously. Storage requirements grow accordingly. Periodic storage expansion is required.

Pruned nodes can reduce storage requirements. We considered pruning but the full archival node serves multiple purposes (BTCPay, internal verification, supporting other infrastructure) that benefit from full history.

Node maintenance

Bitcoin Core releases require periodic updates. Major releases occasionally require migration steps. The maintenance is bounded but requires attention.

Lightning Network Daemon releases also require updates. The release cadence is faster than Bitcoin Core’s.

Security maintenance

The infrastructure handles cryptocurrency. Security maintenance is more critical than typical infrastructure. Server patches, dependency updates, configuration audits all need regular attention.

We treat the BTCPay infrastructure as security-critical and apply correspondingly careful operational practices.

Wallet management

The wallets receiving payments accumulate balances. Periodic transfers to cold storage are operational discipline. The transfers themselves require careful execution to avoid mistakes.

For Lightning Network, channel management requires ongoing attention. Channels need to be opened, balanced, and occasionally closed.

Customer support

Customer-facing payment issues sometimes require support. Customer’s transaction stuck, customer paid wrong amount, customer paid to wrong address. The support is bounded but requires expertise in Bitcoin specifics.

What we have learned about the alternatives

Our experience informs comparisons with alternatives.

BitPay (hosted)

The original service we used. Functional but expensive for our volume. Custodial. Some jurisdictional limitations.

For very small operators (a few transactions per month), the operational simplicity may justify the cost premium. For our volume, self-hosted is favorable.

OpenNode (hosted)

Hosted Bitcoin/Lightning processor. Lower fees than BitPay (0.5%). Still custodial. Less ecosystem maturity than BitPay.

Could be an alternative for operators wanting hosted but with lower fees. Custodial concerns remain.

Strike (hosted)

Bitcoin and Lightning payment service. Different operational model than BitPay/OpenNode. Specific geographic availability.

Limited applicability for our specific use case.

IBEX Mercado (hosted)

Lightning Network-focused hosted processor. Specific to Lightning payments. Good fit for Lightning-only operations.

Less general-purpose than BTCPay.

Custom self-developed

Some operators build their own Bitcoin processing infrastructure rather than using BTCPay. The complexity is significantly higher; the maintenance burden is significantly higher.

For most operators, BTCPay’s mature open-source implementation is more cost-effective than custom development.

Major exchange APIs

Some operators use Coinbase Commerce, Kraken, or similar exchange APIs. Custodial, exchange-dependent, KYC-required. Different operational model than payment processing.

Not directly comparable to BTCPay self-hosted.

What operators considering similar setup should know

For operators considering self-hosted BTCPay Server:

Volume thresholds

The cost economics favor self-hosted at modest volumes. For very small operations (€500/month in cryptocurrency or less), the operational complexity may not justify the savings.

For meaningful volumes (€2,000+/month), the economics typically favor self-hosted. The break-even varies by operation.

Technical capability requirements

BTCPay can be operated by teams with general DevOps capability. Specialized Bitcoin or Lightning Network expertise is helpful but not required.

For teams without DevOps capability, third-party hosted BTCPay services exist. These provide BTCPay’s functionality with hosted infrastructure operation.

Time investment

Initial setup takes 1-2 weeks of focused work. Ongoing operations take a few hours per month for routine maintenance plus periodic larger maintenance windows.

The time investment is bounded but real. Plan for it explicitly.

Hardware considerations

The Bitcoin node requires significant storage (currently approximately 600GB for the blockchain, growing). Storage expansion planning matters.

CPU and memory requirements are modest by modern server standards. The infrastructure is not unusually expensive.

Security considerations

The infrastructure handles cryptocurrency. The security posture should match.

Standard security practices (patching, hardening, monitoring) apply. Additional cryptocurrency-specific considerations (cold storage discipline, key management, transaction verification) add to the security work.

Backup and recovery

Bitcoin wallet backup is critical. Backup procedures should be documented and tested.

For Lightning Network, the backup situation is more complex due to channel state. Specific procedures apply for Lightning backups.

Customer support implications

Self-hosted processing means customer support questions about payments come to your team rather than the processor. Customer support capacity for cryptocurrency-specific questions is needed.

For operations with established customer support, the additional load is bounded. For smaller teams, the load may be more significant.

The bigger picture

Our BTCPay deployment is part of a broader pattern of self-hosted infrastructure across our operations.

We operate self-hosted email infrastructure (PowerMTA, Postal). We operate self-hosted DNS (for specific operational needs). We operate self-hosted analytics (replacing third-party services). We operate self-hosted crypto rate aggregation (covered in another post). We operate self-hosted monitoring and alerting.

The cumulative effect is operational independence from third-party services. The independence aligns with our brand positioning and reduces operational risk from third-party service changes.

The cost of operational independence is real. Each self-hosted service requires ongoing maintenance. The cumulative maintenance burden grows with the number of services.

For our specific operation, the trade-off favors self-hosted. The cumulative time investment is bounded; the cumulative cost savings and risk reduction are meaningful.

For other operators considering similar paths, the trade-off depends on specific operational factors. Operations with privacy alignment, specific brand positioning, or operational risk tolerance for third-party dependency benefit from self-hosted. Other operations may not.

What we expect over time

Looking forward at our BTCPay operation:

The infrastructure continues operating. The basic deployment is stable; ongoing maintenance is bounded.

The Bitcoin and Lightning Network technology continues evolving. Some changes may produce operational implications. We track major developments and adapt as needed.

BTCPay Server continues development. Regular releases bring improvements. We update on regular cadence (typically quarterly).

Customer cryptocurrency adoption continues. The portion of our revenue arriving in cryptocurrency continues growing slowly. The infrastructure scales appropriately.

New cryptocurrency payment options may emerge. We evaluate as relevant but the current setup serves our needs well.

The trajectory is incremental improvement of existing infrastructure rather than wholesale replacement. The investment continues paying back.

Practical recommendations

For operators considering whether to deploy self-hosted BTCPay:

Honest assessment of requirements

If cryptocurrency payments are strategic, the self-hosted investment makes sense. If they are operationally marginal, hosted services may be more cost-effective.

Pilot deployment

Set up BTCPay in a test environment before production migration. The test deployment validates that your team can operate the infrastructure.

Plan migration carefully

If migrating from hosted to self-hosted, plan customer transition. Don’t switch suddenly; provide overlap during the migration.

Document operational procedures

The operational procedures (backup, recovery, customer support, security incidents) should be documented before they are needed.

Build incident response capability

Cryptocurrency-specific incidents happen. Plan for them. The first time you respond to an incident should not be unprepared.

Maintain relationships with operational community

The BTCPay community provides support and operational learning. Engagement with the community produces faster problem resolution and better operational discipline.

Plan for sustained operation

Self-hosted BTCPay is not a one-time deployment. It requires sustained operational investment. Plan for the long-term commitment.

The honest summary

Self-hosted BTCPay Server is operationally viable for our use case. The setup investment was bounded. The ongoing operation is sustainable. The economics favor our specific situation.

The setup is not magic. It requires technical capability, operational discipline, and ongoing maintenance. Operations that cannot provide these should use hosted alternatives.

The benefit is real for operators whose situation aligns with the self-hosted model. Cost savings, custodial independence, brand alignment, jurisdictional flexibility all contribute.

For other operators considering similar paths: the technical work is achievable. The operational discipline is required. The benefit accumulates over time for operations whose model aligns.

We continue operating BTCPay Server in production. The infrastructure serves us well. The customers we work with who care about the privacy alignment of their payment processing see consistency between our brand positioning and our actual operations. The work continues; the benefits continue accumulating; the customer relationships built on operational consistency continue strengthening.

For new operators getting started with cryptocurrency payments: BTCPay Server is a credible option. The community is supportive. The documentation is comprehensive. The technical work is bounded. The operational discipline is achievable. The strategic alignment with self-hosted philosophy is meaningful for operators whose brand or operational situation values that alignment.