BTCPay Server 用 VPS：暗号資産を自前で受け取る

間に入る決済代行には、それぞれの規約、それぞれの KYC、そして残高を凍結するそれぞれのボタンが付いてきます。BTCPay Server はその「間」をなくします。請求書は自分のサーバーで作られ、顧客は自分のウォレットから導出されたアドレスに支払い、支払いは自分の Bitcoin ノードが確認します。止められるのは自分だけです。

すでに bitcoin を受け付けている、あるいはこれから受け付けたいショップ、フリーランス、サービスで、その仕事を企業に任せたくない人向けです。

どのプランを選ぶか

BTCPay は約 7 つのコンテナで動きます。BTCPay アプリ、チェーンを監視する NBXplorer、Bitcoin Core、Postgres、そして Let's Encrypt を自動で扱う前段の nginx です。テストサーバーでは起動直後に約 0.7 GB の RAM を使い、同期中は Bitcoin Core がさらに使いますが、4 GB あれば十分です。本当の制約はメモリではなくディスクです。

専用の IPv4 付きプランが必要です。顧客は HTTPS で BTCPay にアクセスし、Let's Encrypt はポート 80 に届く必要があります。ドイツかフィンランドのうち、注文時に空いているほうを選んでください。決済ページではレイテンシはほとんど問題になりません。そもそも暗号資産を受け取るためのものなので、サーバー代も KYC なしで暗号資産で払えるのは筋が通っています。

インストール

pay.example.com をサーバーに向けてから、新しい Ubuntu 24.04 または Debian 12 で root として：

mkdir BTCPayServer && cd BTCPayServer
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-docker

export BTCPAY_HOST="pay.example.com"
export LETSENCRYPT_EMAIL="you@yourdomain.com"
export NBITCOIN_NETWORK="mainnet"
export BTCPAYGEN_CRYPTO1="btc"
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-save-storage-xxs"
export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAYGEN_LIGHTNING="none"
. ./btcpay-setup.sh -i

収まるかどうかを決めるのは opt-save-storage-xxs です。Bitcoin Core がブロックを 5 GB まで prune します。スクリプトはイメージを取得し、systemd サービス btcpayserver を作ってすべてを起動します。途中で Docker デーモンも再起動するので、ほかのコンテナの横に押し込むより、BTCPay には専用のサーバーを用意する理由がもうひとつ増えます。

ノードを確認します：

bitcoin-cli.sh getblockchaininfo

blocks と headers を比べ、"pruned": true を確認してください。テスト開始から 20 分の時点で、約 972,000 ブロック中およそ 218,000 まで進んでいました。初期のブロックはとても小さいので、ここから所要時間を見積もらないでください。本当の作業はこのあとです。

最初のログイン：今すぐ

https://pay.example.com が応答したらすぐに開いてください。BTCPay は登録ページを表示し、最初のアカウントがサーバー管理者になります。あなたより先に誰かがページを見つけたら、決済サーバーはその人のものになります。登録したら Server Settings → Policies を開き、新規登録の扱いを好みに合わせて設定してください。

次にストアを作り、ウォレットを 拡張公開鍵（xpub） で接続します。ハードウェアウォレットか、デスクトップウォレットのエクスポートから取得できます。BTCPay は請求書ごとに新しいアドレスを導出し、秘密鍵を見ることはありません。何年も履歴のあるウォレットではなく、新しいウォレットか新しいアカウントを使ってください。pruned ノードは、これから起きることを追うのが得意です。

ノードが追いつくまで、BTCPay は同期中であることを表示し、支払いを監視しません。公開はインストールした夜ではなく、同期が終わったあとに予定してください。

本番運用の前に知っておくこと

• 最初の同期は長い。 pruned ノードでも、古いブロックを捨てる前にチェーン全体（700 GB 超）をダウンロードして検証します。当社プランのトラフィックは 1 Gbit/s で無制限なので追加料金はかかりませんが、4 vCPU のサーバーなら日単位で考えてください。リポジトリには高速同期スクリプトもあります。ただしこれは他人の UTXO セットのコピーを信用してこの作業を省くもので、自分でノードを動かす理由の一部を損ないます。
• アップデート。 btcpay-update.sh で BTCPay と依存関係の最新版を取得します。セールの最中ではなく、落ち着いた時間帯に実行してください。
• バックアップ対象。 xpub だけで接続したウォレットなら、コインはサーバー上にありません。失う可能性があるのは Postgres にあるストア設定と請求書の履歴です。そのボリュームをバックアップし、ウォレットのシードはこのサーバーとまったく関係のない場所に保管してください。
• Lightning はあとで。 まずはオンチェーンで始めてください。Lightning には大きなブロック枠、チャネル管理、インバウンド流動性が必要で、それ自体がひとつのプロジェクトです。必要な Pro プランはお問い合わせいただければ用意します。

私の考え：1 日 1 回 bitcoin を受け取る小さなショップなら、Small-IP 上の BTCPay がいちばんすっきりした構成です。カード決済や法定通貨での出金が必要なら、これは向いていません。

関連記事

• VPS で自分の Bitcoin ノードを動かす：ウォレットの検証だけが目的なら、ノード単体で
• VPS で自分の Monero ノードを動かす
• Crypto VPS：サーバー代を暗号資産で支払う
• 独自 IP のウェブサイト向け VPS：顧客を BTCPay に送るショップ側
• ufw ファイアウォールの設定方法