중간에 끼는 결제 대행사마다 자기 약관, 자기 KYC, 그리고 잔액을 동결하는 자기 버튼이 따라옵니다. BTCPay Server는 그 중간을 없앱니다. 청구서는 내 서버에서 만들어지고, 고객은 내 지갑에서 파생된 주소로 결제하며, 결제는 내 비트코인 노드가 확인합니다. 나 말고는 아무도 이걸 끌 수 없습니다.
이미 bitcoin을 받고 있거나 받고 싶은 상점, 프리랜서, 서비스 중에서 그 일을 회사에 맡기고 싶지 않은 분들을 위한 것입니다.
어떤 요금제
BTCPay는 약 7개의 컨테이너로 돌아갑니다. BTCPay 앱, 체인을 감시하는 NBXplorer, Bitcoin Core, Postgres, 그리고 Let's Encrypt를 자동 처리하는 앞단의 nginx입니다. 저희 테스트 서버에서는 시작 시 약 0.7 GB RAM을 썼고, 동기화 중에는 Bitcoin Core가 더 씁니다. 4 GB면 넉넉합니다. 진짜 제약은 메모리가 아니라 디스크입니다.
| 구성 | 요금제 |
|---|---|
| 온체인 BTC, 블록 ~5 GB를 보관하는 pruned 노드 | Small-IP: 4 vCPU, 4 GB, 35 GB (월 $16) |
| 같은 구성에 로그와 업데이트용 여유를 더해서 | Medium-IP: 6 vCPU, 6 GB, 45 GB (월 $20) |
| Lightning, 더 큰 블록 여유분, 또는 두 번째 코인 | Pro-32: 8 vCPU, 32 GB, 400 GB (월 $40), 문의 |
전용 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 요금제는 문의하시면 준비해 드립니다.
제 생각: 하루에 한 번 bitcoin을 받는 작은 상점이라면 Small-IP 위의 BTCPay가 가장 깔끔한 구성입니다. 카드 결제나 법정화폐 출금이 필요하다면 이 도구는 맞지 않습니다.
관련 글
- VPS에서 내 비트코인 노드 운영하기: 지갑 검증만 원한다면 노드 단독으로
- VPS에서 내 Monero 노드 운영하기
- Crypto VPS: 서버 비용을 암호화폐로 결제
- 전용 IP 웹사이트용 VPS: 고객을 BTCPay로 보내는 상점 쪽
- ufw 방화벽 설정 방법
댓글
아직 댓글이 없습니다. 첫 번째가 되세요.