Deploy BTCPay Server
Bitcoin payments with BTCPay Server, Bitcoin Core, NBXplorer and Postgres.
nbxplorer
Just deployed
Just deployed
/var/lib/postgresql/data
bitcoind
Just deployed
/data
btcpayserver
Just deployed
/datadir
Deploy and Host BTCPay Server on Railway
BTCPay Server is a free, open-source, self-hosted Bitcoin payment processor. It creates invoices, point-of-sale apps, donation pages and payment requests, and connects to online stores through plugins and its Greenfield API. Payments go straight to a wallet you control, with no intermediary and no processing fees.
About Hosting BTCPay Server
This template runs the same components as BTCPay's official Docker deployment: BTCPay Server, NBXplorer (its blockchain indexer), Bitcoin Core and PostgreSQL. It is set up for Bitcoin mainnet with a pruned node, so it can accept real payments once the node has synced. Bitcoin Core needs roughly 25 GB of disk, which exceeds the Hobby plan's 5 GB volume limit, so deploy it on Railway Pro. The first sync takes hours to days, and BTCPay shows a syncing banner until then. The first account you register becomes the server administrator, so create it right after deploying.
Common Use Cases
- Accepting on-chain Bitcoin payments in an online store through BTCPay's WooCommerce, Shopify and other integrations
- Running a point-of-sale, donation or crowdfunding page without a payment intermediary
- Sending invoices and payment requests to customers from the dashboard or the Greenfield API
Dependencies for BTCPay Server Hosting
btcpayserver/btcpayserver:2.4.4nicolasdorier/nbxplorer:2.6.17btcpayserver/bitcoin:31.1-1(Bitcoin Core 31.1, as used by BTCPay's official Docker deployment)- Railway PostgreSQL
- Railway Pro plan for the Bitcoin Core volume
Deployment Dependencies
- BTCPay Server documentation
- BTCPay Server 2.4.4 release
- BTCPay Server Docker deployment
- NBXplorer
- BTCPay wallet setup
- Railway volumes
Implementation Details
| Service | Image | Networking | Persistent storage |
|---|---|---|---|
btcpayserver | btcpayserver/btcpayserver:2.4.4 | Public HTTPS domain on port 49392; health check /api/v1/health | /datadir for server configuration and plugins |
nbxplorer | nicolasdorier/nbxplorer:2.6.17 | Private, port 32838 | None; its state lives in PostgreSQL |
bitcoind | btcpayserver/bitcoin:31.1-1 | Private: RPC 43782, P2P 39388 | /data for blocks and chain state |
Postgres | Railway PostgreSQL | Private | /var/lib/postgresql/data |
BTCPay and NBXplorer create their own databases (btcpayservermainnet and nbxplorermainnet) on first start. NBXplorer reaches Bitcoin Core over RPC with a generated password and over P2P, where the node whitelists it. Railway services cannot share a volume for BTCPay's usual cookie file, so NBXplorer runs without authentication and is reachable only inside the project. Bitcoin Core runs with its wallet disabled, accepts no public connections, and caps uploads at 2000 MiB a day to limit egress charges. After the first administrator account exists, BTCPay closes public registration by default.
Keep private keys off the server. Connect your store to an existing wallet by pasting its extended public key (xpub) or output descriptor. BTCPay then generates receiving addresses without holding any private key, so a compromised server cannot spend your funds. Avoid BTCPay's server-side "hot wallet" unless you understand the risk.
Pruning. The node keeps BITCOIN_PRUNE_MB=10000 (about 10 GB, roughly five to six weeks of blocks). NBXplorer records your wallet's transactions in PostgreSQL as each block arrives, so new invoices and balances work normally. Two limits apply:
- If you connect a wallet that already received funds before the node's pruning window, BTCPay will not show those older transactions. Use the wallet's Rescan feature, which scans the current UTXO set, to recover the balance.
- If NBXplorer is down for longer than the pruning window, run a rescan afterwards so you don't miss payments from that gap.
To keep more history, raise BITCOIN_PRUNE_MB and grow the bitcoind volume to match. Setting it to 0 keeps the full chain, about 800 GB, which needs a 1 TB volume. Increase BITCOIN_DBCACHE_MB (default 2048) to speed up the first sync at the cost of more memory. Lightning Network support is not included.
To test without real funds, set BITCOIN_NETWORK, NBXPLORER_NETWORK and BTCPAY_NETWORK to signet or testnet before the first deploy, and change mainnet in the two database names to match. Railway volumes survive redeploys but are not backups, so back up the Postgres database regularly.
This is a community-maintained deployment package and does not imply affiliation with or endorsement by the BTCPay Server Foundation.
Why Deploy BTCPay Server on Railway?
Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.
By deploying BTCPay Server on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.
Template Content
nbxplorer
nicolasdorier/nbxplorer:2.6.17bitcoind
btcpayserver/bitcoin:31.1-1btcpayserver
btcpayserver/btcpayserver:2.4.4
