VPSCrypto
每一个托管式加密支付处理商，在替你挪动哪怕一聪之前，都要先问两件事：你是谁，以及能不能允许它在钱经手期间替你保管。这两条，都是别人替你的生意做的决定。BTCPay Server 做的是同一份工作 — 发票、汇率、结账页面、webhook、收银台 — 只是把它写成了你自己运行的软件：不用开户，不抽成，客户的钱包和你的钱包之间，不站着任何人。
代价是，你自己成了运营者。这份指南讲的就是这实际要花多少代价：这套技术栈里到底是哪部分在吃资源（不是 BTCPay 本身），它真正需要什么样的套餐，怎么用大约一小时的操作加一天的等待把它部署起来，以及 — 这部分才真正决定这一切值不值得 — 它跑起来之后，密钥到底放在哪里。比特币与闪电网络是默认项；Monero 是一个可选集成，而且恰好是三者里密钥处理得最干净的一个。底下这台机器，可以只用一个邮箱地址租下来，用你即将开始收的这些币来付款。
自建处理商，到底改变了什么
常见的卖点通常是“零手续费”，但这其实是最没意思的一部分。真正变化的有四件事，其中只有一件跟钱有关：
- 没有人在钱经手时候持有你的资金。托管式处理商会先把客户的付款收进自己的钱包，事后再记到你账上。冻结、审核和扣留，就发生在这段间隙里。BTCPay 什么都不经手：客户付款到一个由你的密钥派生出来的地址，从第一次确认起，这笔钱就是你的。
- 没有人问你是谁。接入一家处理商，是一套以银行收尾的身份核验流程。安装软件不是。这就是全部的区别所在，也是为什么“怎么才能不用 KYC 收加密货币”这个问题，答案永远是“自己运行处理商”。
- 成本不再随你增长。抽成会一直收下去，而且生意越好抽得越多。VPS 和域名的花费，好月份和差月份都一样。
- 运维的活儿落到了你头上。在线率、更新、备份，还有客户说发票一直没结清时，去收那条消息的人就是你。这才是真正的代价，付出的是精力，不是货币。
你得不到的一件事，恰恰是处理商真正擅长的那件事：替你把币换成银行账户里的钱。BTCPay 收到什么币，就原样持有那种币。换汇、开法币发票、做出税务机关认可的记账凭证 — 这些都是另外的问题，而解决它们的大多数办法，都会把你刚刚去掉的那个被识别的交易对手方，原样请回来。动手之前，先想清楚这笔交易你到底想要哪一半。
实际部署的是什么，哪部分才是真正费钱的
这个名字有一定的误导性，但误导得挺有用。“BTCPay Server”不是一个程序；标准部署其实是一小队一起启动的容器，分清楚谁是谁，决定了你是在认真选型，还是在瞎猜：
- Bitcoin Core。一个真正的全节点，从创世区块开始验证。这是吃掉你磁盘空间、占掉头一天大部分时间、几乎耗尽全部内存的那个组件。其余部分相比之下几乎不花钱。
- NBXplorer。Core 和 BTCPay 之间的索引器。你把扩展公钥交给它；它负责追踪派生出来的地址，钱一到账就通知 BTCPay。它也是在意裁剪与否的那个组件，原因会在故障模式那一节说到。
- BTCPay Server 本身。应用程序层：店铺、发票、结账页面、收银台、webhook、Greenfield API。相比之下很轻量 — 内存占用只有几百 MB。
- PostgreSQL。发票、店铺、设置、用户、API 密钥。体积很小，而这恰恰是你做备份真正要保护的东西。
- 带自动证书的 nginx。一个反向代理，外加一个为你的主机名签发并续期证书的伴生程序。这就是为什么 80 和 443 端口必须真正能从公网访问到。
- 可选的闪电节点（Core Lightning 或 LND）和 Monero 守护进程，外加一个钱包 RPC 陪着它 — 各自带着自己的链，也各自有自己的磁盘胃口。
所以选型这个问题，问的从来不是“BTCPay 得有多大”，而是“我要保留多少条链，一共几条”。想清楚这个，套餐自己就选出来了。
老老实实地估算规模，选对套餐
项目文档给出的最低配置是 2 GB 内存加 swap，推荐配置是 4 GB，这两个数字之间的差距，就是“技术上能装完”和“你敢把客户指过去”之间的差距。应用运行时、PostgreSQL，再加一个正在同步的 bitcoind 挤在 2 GB 里，也能跑完 — 只是会很慢，还要靠 swap 文件去干那些它本不该干的活。
磁盘用量由你裁剪的力度决定，部署脚本把这个力度暴露成一个传给安装程序的片段参数。这个系列大致是：opt-save-storage 对应约 100 GB 的区块文件，-s 约 50 GB，-xs 约 25 GB，-xxs 约 5 GB。最后这一档对任何打算长期运行的东西都是个陷阱：留下的历史数据太少，连日常维护都会开始出问题。对一家店铺来说，-s 或 -xs 是合理的区间。
来看套餐表里的具体数字，因为“看情况”不是一个答案：
- 只做比特币、裁剪模式、单店铺 — Scout，2 vCPU / 4 GB / 70 GB NVMe，$9.00/mo。这是老实的下限，也是大多数读者该选的答案。
- 比特币加闪电网络 — Runner，3 vCPU / 6 GB / 100 GB，$14.00/mo。闪电节点的守护进程对磁盘要求很轻，却执意要一直在线；多出来的余量是留给它底下那个节点的。
- 比特币、闪电网络加 Monero — Alpha，6 vCPU / 12 GB / 200 GB，$28.00/mo。裁剪过的 Monero 链本身就要占约 85 GB，所以两条链加两个索引器，8 GB 就会开始吃紧。Hunter（4 vCPU / 8 GB / 140 GB，$19.00/mo）只有在比特币保持深度裁剪、而且一直保持下去的前提下才够用。
- 店铺背后再挂一个未裁剪节点 — 这是另一个项目，账单也是另一回事。全节点指南里有那些数字，起步价是 Fenrir。
CPU 只在一个地方要紧。初始区块下载期间的签名验证是可以并行的，所以两到四个 vCPU 能把首次同步从几天压缩到大约一天，之后就一直闲着。带宽是整条链只需要付一次的成本，走的是 1 Gbps 不限流量的端口，月底也不会多出一张超额账单。延迟对一个支付处理商无关紧要，所以选位置该看司法辖区，而不是那几毫秒 — 阿姆斯特丹、巴黎、布加勒斯特和索非亚都是基础价格。
开始之前，你需要准备什么
一份不长的清单，其中有一项跟技术没关系。
- 一个域名，并且 A 记录已经指向这台服务器。证书是针对这个主机名通过 HTTP 签发的，所以 DNS 必须在安装程序运行之前就完成解析，而不是运行期间才解析。像
pay.example.com这样的子域名是常见写法。 - 80 和 443 端口对公网开放。80 端口不是可选项，虽然之后它不会再提供任何有用的服务；证书验证需要用到它。
- 从模板库选择 Debian 13，并且这台机器已经做过那十分钟的加固。先做这一步 — 等技术栈跑起来之后再想优雅地补做，会难得多。
- 一个你已经掌控的钱包，以及它的扩展公钥。Sparrow、Electrum 或者一个硬件钱包都行。安装前就把它准备好，这样你就不会被诱惑着让服务器替你生成一个。
- 一个给证书颁发机构用的邮箱地址。它只会收到到期提醒，仅此而已。
- 现在就对裁剪做出决定。之后再改主意，就得把链从头重新同步一遍，这一天你不会想再经历第二次。
分步操作
- 部署服务器，把域名指过去，先做加固
下单选型那一节指向的那个套餐，选择 Debian 13，位置按司法辖区选，而不是按延迟选。立刻创建 DNS 记录，因为等安装程序去找证书颁发机构证明你拥有这个域名的时候，它必须已经生效：
pay.example.com. 300 IN A 198.51.100.10然后是Debian 加固指南里的那一遍流程：一个带密钥的非 root 用户、关掉密码登录、打开无人值守的安全更新、再加一道默认拒绝的防火墙。下面的内容都假设这一步已经做完，而且只开放 22、80 和 443。
apt update && apt full-upgrade -y apt install -y git curl不要手动安装 Docker。安装脚本会装好并配置它期望的那个版本，手工装的版本，是首次运行失败最常见的原因。
- 克隆部署仓库，选好你的配置片段
整套部署就是一个仓库，里面是 shell 脚本和 compose 片段。用 root 身份把它克隆到一个你记得住的地方：
git clone https://github.com/btcpayserver/btcpayserver-docker cd btcpayserver-docker配置项就是环境变量，安装程序只读取一次然后持久化下来，所以下面这些 export，就是你唯一需要写的那份配置文件：
export BTCPAY_HOST="pay.example.com" export NBITCOIN_NETWORK="mainnet" export BTCPAYGEN_CRYPTO1="btc" export BTCPAYGEN_REVERSEPROXY="nginx" export BTCPAYGEN_LIGHTNING="clightning" export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-save-storage-s" export LETSENCRYPT_EMAIL="you@example.com"BTCPAYGEN_LIGHTNING可以取clightning、lnd,phoenixd，或者干脆留空 — 如果你还没准备好持有热资金，就先留空，以后要加也只是再跑一次同一个脚本。片段名称是这里面随版本变化的部分，粘贴之前，先看一眼项目当前的部署页面。 - 运行安装程序，然后让链去同步
一条命令就能构建 compose 文件、拉取镜像、把所有东西都启动起来：
. ./btcpay-setup.sh -i它几分钟内就能跑完，留下一个能用的网页界面。但它留不下一个能用的店铺，因为 Bitcoin Core 这时候正在下载并验证整条链，在它完成之前，什么都收不了钱。别去猜，直接看进度：
bitcoin-cli.sh -getinfo btcpay-down.sh # stop everything btcpay-up.sh # start everything该相信的数字是
verificationprogress，它在早期会骗人：前 90% 很快，最后 10% 却要花掉大部分时间，因为最近的区块都是满的。在配备两到四个 vCPU 的 NVMe 上，大约要一天。它工作的时候别去动它 — 同步到一半重启，只会让你搭进去缓存。 - 创建管理员账户，随手把门关上
打开
https://pay.example.com注册账户。第一个创建的账户会成为管理员，这就使得从安装程序跑完到你完成注册之间的这段窗口期，成了整个流程里唯一真正危险的时刻。立刻去注册，用你早就开着的那个浏览器标签页。然后到服务器设置里关掉开放注册，这样第二个访问者就没法自己创建账户，再给自己开启双因素认证。两下点击而已，却决定了这究竟是你的支付处理商，还是别人的支付处理商。之后再要加管理员，一律明确邀请。
- 接入一个服务器花不了的钱包
先建一个店铺，再接入一个比特币钱包。BTCPay 会主动提出替你生成一个新钱包；选另一条路 — 连接一个已有的钱包 — 粘贴从你自己的钱包导出的、账户级别的扩展公钥：
zpub6r... # account-level extended PUBLIC key (xpub / ypub / zpub), never a prv # Sparrow: wallet settings. Electrum: Wallet -> Information -> Master Public Key这串字符串按设计就是公开的。它能让 BTCPay 派生出用不完的收款地址，并识别发给它们的付款；但它没法让 BTCPay，或者任何攻破了 BTCPay 的人，挪动哪怕一聪。私钥留在原来的地方，最好是在一个从没接触过这台机器的硬件钱包里。
有两个后果值得记在心里。给店铺用一个全新账户，或者一条专用的派生路径，而不是一个你已经用了很多年的钱包的密钥 — 故障模式那一节解释了为什么历史记录和裁剪合不来。还要记住，谁拿到那个扩展密钥，谁就能看到你收到的每一笔付款：算不上是一把钥匙，但也绝不是什么都没有。把它当成一本摊在桌上没收起来的账本。
- 接入闪电网络，决定把多少资金放在里面
如果你在安装时就设置了
BTCPAYGEN_LIGHTNING，节点这时已经在运行，内部也接好了，店铺设置里只需要把它打开。如果当时留空了，就导出这个变量，再跑一次安装脚本；它是幂等的，不会重新同步链。export BTCPAYGEN_LIGHTNING="clightning" . ./btcpay-setup.sh -i接下来是一个决策，而不是一项配置。通道余额存放在一个服务器能花的钱包里，因为支付通道本来就是这么回事；闪电网络里没有只读这种东西。这台机器一旦被攻破，你损失的就正好是通道余额，不多不少，所以放在里面的合理金额，应该是丢了会让你懊恼、而不是会让你破产的那个数目。按一个你真的会坚持的节奏，把钱扫到冷存储里去。
预计头一个月主要是在解决流动性问题，而不是收款问题。商户节点需要的是入站容量，而这恰恰跟开通道给你的东西相反 — 开一条通道，注资的是你自己这一侧。从服务商那里买入站流动性、做一次潜艇交换把资金推到对面，或者干脆等有了交易量之后让对方主动向你开通道，是三个诚实的选项。Core Lightning 和 LND 都可以，Core Lightning 搭配裁剪节点时更省心，原因在全节点指南里有解释。
- 接入 Monero，使用查看钱包
Monero 用同样的方式接入，作为第二个加密货币槽位，会额外拉起一个 Monero 守护进程和一个钱包 RPC，陪着其余部分一起跑：
export BTCPAYGEN_CRYPTO2="xmr" . ./btcpay-setup.sh -i为第二条链预留预算：裁剪之后约 85 GB，在 NVMe 上首次同步大约一到两天。Monero 节点指南里有这两项的详细说明。
这里的密钥处理方式，是整套安装里最出色的部分。Monero 把看到收款的能力和花掉它们的能力分开了，所以你可以用主地址和私有查看密钥生成一个查看钱包，服务器手里从头到尾也只有这个：
monero-wallet-cli --generate-from-view-key store-view它会要求输入主地址、私有查看密钥和一个密码。把生成的钱包文件复制到部署脚本暴露出来的 Monero 钱包目录里，把店铺指向它，BTCPay 就会为每张发票生成一个子地址，并监视发给它的付款。花费密钥则从未离开过生成它的那台机器。
有一件事需要围绕它设计结账流程：收到的输出会被锁定十个区块，大约二十分钟，所以 BTCPay 看到付款到账的时间，会比它能被花掉早得多。对于数字商品，这只是一个策略选择。但对于当面交付的东西，这就成了一段要排的队。
- 先像客户一样测试，再像运营者一样测试
“页面能打开”算不上测试。开一张金额很小的发票，用一个真实钱包去付款，然后过一遍那些决定付款不完美时会发生什么的设置：
- 确认策略。一张发票要过多少个区块才算结清。对一杯咖啡来说，零确认是合理的；对一台笔记本电脑来说就不对了；这是一个按店铺设置的选项，也是界面里后果最重的一个数字。
- 发票有效期。报价的汇率在失效前，能留给客户多长时间。默认是十五分钟，对于从交易所提现来付款的人来说，这个时间偏短。
- 付款容差。你愿意接受的少付比例，好过让客户拿着一张付了一半的发票再开一张工单。设成一个很小但非零的值，是务实的做法。
- 少付和多付。故意少付一张发票一次，看看你的店铺会怎么处理。用自己的钱学到这一课，总比别的方式好得多。
接下来是运营者那一半：开启一个 webhook，确认你的店铺真的能收到它；如果会有程序自动创建发票，就生成一个 Greenfield API 密钥；上线之前先做一次完整备份 — 这样你人生中第一次真正的恢复操作，才会是一次演练，而不是一场紧急情况。
密钥放在哪里，以及那个真正要命的错误
一台自建处理商出的几乎每一个坏结果，追根溯源都能归结到早期一个随手做下的决定：让服务器持有了某个能花出去的东西。这里值得把三种情况说清楚，因为它们其实很不一样。
- 链上比特币：始终只读。BTCPay 手里只有一个扩展公钥，别的什么都没有。如果这台机器被攻破，攻击者能知道你收过什么钱，还能改掉以后发票指向的地址 — 这是一次真实的攻击，也是任何事故之后都要重新检查店铺钱包的原因 — 但动不了已经收到的那些币。
- 闪电网络：天生就是热的。通道里注入的是服务器能花出去的币，因为通道本来就是这么回事。这是刻意留出的例外，上一节已经给它估算过规模。
- Monero：结构性只读。私有查看密钥能看到每一笔收款，却不能批准任何一笔转出。比特币这边没有对应的机制。
唯一故意打破这套模型的功能是 Payjoin。它让你的服务器为客户的交易贡献一笔输入，这会实质性地削弱链分析赖以依靠的“共同输入”启发式规则，对双方都是实打实的隐私收益 — 但收款方得能签名，所以 BTCPay 内部需要一个热钱包。这是一笔真实的取舍，不是白拿的功能。要用就清醒地用，给它充值的方式要跟给闪电钱包充值一样：只放一个够用的金额，而不是全部身家。
如果你图省事，让安装向导替你生成了店铺钱包：把它显示给你看的那串种子记下来，拿到一个离线钱包里验证一遍，然后计划着迁移到一套只读方案上。一串曾经出现在联网服务器上的种子，就是一串已经开始倒计时的种子。
备份，以及那些真正无可替代的部分
按恢复起来有多难，把这些状态分分类，因为答案差得很远：
- 链本身。这不是一个备份问题。它是公开数据，会自己重新同步，慢一点，但免费。永远不要备份它。
- 数据库。发票、店铺、设置、用户、API 密钥。这才是真正要备份的东西，体积很小，丢了它，你丢掉的是每一笔交易的记账记录 — 不是钱，而是凭证。
- 你的链上钱包。本来就是安全的，因为密钥从来就不在这台机器上。这就是第五步换来的回报。
- 闪电通道状态。这是真正会咬人的一个。一份静态通道备份，能在彻底失败之后，通过强制关闭通道把里面的资金找回来；但它恢复不了通道本身，而且一旦过期就完全没用。它在每次开通道或关通道时都会变化，所以它该待在一份自动化的异地副本里，而不是一个你每季度才想起来一次的文件夹里。
- Monero 的查看钱包。可以用你离线保管的地址和查看密钥重建出来。备份好这两样，把钱包文件本身当成一份缓存看待就行。
这套部署自带了能正确完成这件事的辅助脚本：
btcpay-backup.sh # stops the stack, dumps Postgres, tars the config, restarts
btcpay-restore.sh # puts one of those archives back那个停顿正是关键所在 — 一份运行中数据库的热拷贝，恢复出来的结果往往很难看。凡是离开这台机器的东西都要加密，也别忘了每个套餐自带的每周快照只是一项便利功能，不是备份：快照和它保护的对象活在同一个地方。
快速上手教程会跳过的那些故障模式
大致按耗掉别人多少个夜晚的频率排序：
- 证书一直签发不下来。十次里有九次，是 A 记录在安装程序跑完之后才创建的，或者是 80 端口被过滤掉了。先修好 DNS，找一台不是你自己笔记本的机器确认能解析到这个名字，再重新跑一遍安装脚本。蒙着头对证书颁发机构反复重试，换来的只是速率限制和一周的等待，所以两次尝试之间，总要改点什么。
- 导入一个带历史的扩展密钥，却显示余额为零。这是裁剪挖的坑。索引器靠监视新区块来发现新收款，但要重建一个已有钱包的历史，就得读取裁剪节点早就删掉的那些区块。给店铺用一个全新账户，这个问题根本不存在；如果非要导入历史，你需要一个未裁剪的节点，外加一次重新扫描。
- “客户已经付款了，发票却还显示未结清。”通常是发送方钱包扣的手续费导致少付、发票在付款还没确认时就过期了，或者确认策略比你记忆中设置的更严格。这三种情况都是设置问题，也正因为如此，你才应该先拿自己的钱测试一遍。
- 节点在不声不响地掉队。一个卡住的 bitcoind 依然会分发地址、错过付款，却不会抱怨一声。定时把你的区块高度和任何公开数据源做比对，一有差距就报警；这不该是从客户那里才学到的教训。
- 在错误的时机来一次更新。
btcpay-update.sh表现得很规矩，但它会重启所有东西。要有意识地手动运行它，绝不自动触发，也绝不在促销期间运行。 - 地址攒出了名声。结账页面挂在一个上了黑名单的 IPv4 上，就是一些企业网络和邮件过滤器会悄悄拒绝的那种结账页面。这里的每个套餐配的都是一个没有历史记录的专属地址，把域名印到任何东西上之前，先查一下它，值得。
司法辖区、域名，以及自建藏不住的东西
这套软件去掉的是一个交易对手方。它去不掉剩下的那些暴露面，老老实实承认这一点，比再列一份功能清单更有用。
域名是最薄弱的一环。它注册在某个地方，公开可解析，也是任何人第一眼就会看的东西。一个用你自己名字、在你自己国家的注册商那里注册主机名、然后自建起来的处理商，只是把钱从第三方手里挪开了，身份暴露的程度却分毫未动。如果这件事关系到你卖的东西，注册商就该获得和主机商同等的重视。
司法辖区是一个真实变量。机器放在哪里，决定了谁的法院命令能够触及它、中间要走多少道流程。这是摩擦和距离，不是豁免权 — 离岸托管这个词条把这点讲得很透，在为了一面旗帜牺牲网络质量之前，值得先读一读。
账户是最后一条线索。用一个邮箱地址租服务器，再用Monero 付款，就没有任何一张银行卡账单能把结账页面和一家银行绑在一起 — 建一套整个意义就是不需要银行的系统，却在这件事上失手，未免有点奇怪。这里的每个套餐默认无需 KYC，每个地点都配有专属干净 IPv4 和自定义反向 DNS。
而边界是明说的，不是靠猜的。节点、处理商和店铺都是再普通不过的基础设施，在这里一样受欢迎；可接受使用政策简短、公开，而且有底线。你收款是否需要牌照，取决于你卖什么、你人在哪里，跟用什么软件无关 — 这个问题该问有资质的专业人士，而不是一份主机指南。
常见问题
运行 BTCPay Server，我需要哪个 VPS 套餐？
Scout（2 vCPU / 4 GB / 70 GB NVMe，$9.00/mo）跑一个裁剪比特币节点，是一家能正常运作的店铺老实的下限，也是大多数读者该买的那个。加上闪电网络，Runner（3 vCPU / 6 GB / 100 GB，$14.00/mo）会更宽裕；再把 Monero 加进来当第二条链，Alpha（6 vCPU / 12 GB / 200 GB，$28.00/mo）就是那个能让你不用再操心这件事的规格。项目文档给出的最低值是 2 GB，这是真的，但也真的不好受。
不运行完整的比特币节点，能用 BTCPay Server 吗？
可以，但你是在选择保留哪一种信任。BTCPay 可以指向一个你已经在运行的外部节点 — 这是比较理智的做法，也是值得先看一遍全节点指南的理由 — 或者指向别人的节点，那样就重新引入了一个能看到你店铺生成的每一个地址的第三方。之所以要内置一个节点，是因为那是唯一没有人在看着的配置。裁剪节点依然是全节点：裁剪之后，关于资源的反对意见大部分都不成立了。
BTCPay Server 支持 Monero 吗？
支持，作为一个在部署时开启的可选集成。它会拉起一个 Monero 守护进程和一个钱包 RPC，你用一个从主地址和私有查看密钥生成的查看钱包去连接它 — 服务器能看到付款，却花不了，这比比特币那一侧能提供的任何方案都更好。代价是要多同步、多存一条链，外加收到的输出有十个区块的锁定期，大约二十分钟之后资金才能被花掉。
自己运行支付处理商，合法吗？
运行这个软件，只是普通的软件操作。大多数地方真正受监管的行为，是替别人持有或转移资金，而一个非托管处理商替你自己的生意收款，恰恰不属于这种行为，因为它从来没有替任何人持有过任何东西。你卖什么、你人在哪里，仍然决定着你要承担的义务，税务也不例外，自建改变不了这些。这是一份主机指南，不是法律意见：如果你打算替第三方处理收款，就该假设自己进入了另一个类别，去问有资质的人。
服务器挂了，我的钱会丢吗？
链上的钱不会丢，前提是你照第五步做了 — 那些币躺在一个密钥从没上过服务器的钱包里，重新装一遍、喂给它同一个扩展公钥，就又能看到它们。会丢的是记录：发票、店铺设置、API 密钥，除非你留了数据库备份。闪电网络是例外，因为通道里的资金就在服务器上；彻底出问题之后要找回它们，需要一份最新的静态通道备份，而且它是强制关闭你的通道，而不是把通道恢复原样。
用 BTCPay Server 一定要有域名吗？
实际操作中，是的。这套部署会为一个主机名签发证书，浏览器和钱包都指望结账页面用 HTTPS，而客户被要求把钱付给的，正是地址栏里显示的那个东西。用你已经拥有的域名开一个子域名就够了。如果公开域名本身就是问题所在，BTCPay 也可以改成通过 onion 服务访问 — 这是一种合法的配置，只是也会改变有多少客户能打得开这个页面。
自建每个月实际要花多少钱？
软件本身免费，采用 AGPL 许可，所以要花钱的是 VPS、域名和你的时间。Scout 每月 $9.00，域名一年几美元，跟任何抽成式处理商比起来，这笔账在交易量很小的时候就已经不再接近了 — 而且它不会像抽成那样，随着你做大而跟着涨。真正老实的成本是第三项：你现在就是那个会注意到节点不再同步的人。
