Self-host BTCPay Server di VPS

Pitch-nya biasanya “tanpa fee”, dan itu justru bagian yang paling tidak menarik. Ada empat hal yang berubah, dan cuma satu di antaranya soal uang:

• Tidak ada yang menahan dana Anda selama transit. Processor yang hosted menerima pembayaran pelanggan ke wallet miliknya sendiri lalu baru mengkreditkannya ke Anda belakangan. Celah itulah tempat hold, review, dan freeze terjadi. BTCPay tidak pernah menerima apa pun: pelanggan membayar ke alamat yang diturunkan dari key milik Anda, dan coin-nya jadi milik Anda sejak konfirmasi pertama.
• Tidak ada yang bertanya siapa Anda. Onboarding ke sebuah processor adalah proses identitas yang berujung ke sebuah bank. Menginstal software bukan begitu. Itulah keseluruhan bedanya, dan itulah kenapa jawaban untuk “bagaimana cara menerima kripto tanpa KYC” selalu “jalankan sendiri processor-nya”.
• Biayanya berhenti ikut membesar seiring Anda. Persentase dipungut selamanya dan membesar seiring kesuksesan Anda. VPS dan domain berbiaya sama di bulan yang bagus maupun yang buruk.
• Anda mewarisi pekerjaan operasionalnya. Uptime, update, backup, dan menjadi orang yang menerima pesan ketika pelanggan bilang invoice-nya tidak pernah settle. Inilah harga sesungguhnya, dan dibayar dengan perhatian, bukan dengan uang.

Yang tidak Anda dapatkan adalah satu hal yang memang benar-benar dikuasai oleh processor: mengubah coin jadi uang rekening bank atas nama Anda. BTCPay cuma memegang apa yang dibayarkan kepadanya, dalam coin yang sama saat dibayarkan. Konversi, invoicing dalam fiat, ekspor akuntansi yang diakui otoritas pajak — semuanya masalah terpisah, dan kebanyakan cara menyelesaikannya justru menghadirkan kembali persis pihak lawan transaksi yang teridentifikasi yang baru saja Anda hilangkan. Tentukan dulu separuh mana dari trade itu yang sebenarnya Anda inginkan sebelum Anda membangun apa pun.

Namanya menyesatkan dengan cara yang berguna. “BTCPay Server” bukan satu program; deployment standarnya adalah sekumpulan kecil container yang naik bersamaan, dan mengetahui mana yang mana adalah beda antara melakukan sizing ini dengan benar dan cuma menerka-nerka:

• Bitcoin Core. Full node sungguhan, memvalidasi sejak genesis. Inilah komponen yang memakan disk Anda, sebagian besar hari pertama, dan hampir seluruh memory-nya. Semua yang lain relatif gratis.
• NBXplorer. Indexer di antara Core dan BTCPay. Anda memberinya extended public key; ia melacak alamat-alamat turunannya dan memberi tahu BTCPay saat uang mendarat. Ini juga komponen yang peduli soal pruning, dengan alasan yang dibahas lagi di bagian mode kegagalan.
• BTCPay Server itu sendiri. Aplikasinya: toko, invoice, halaman checkout, point of sale, webhook, Greenfield API. Relatif kecil — cuma beberapa ratus megabyte memory.
• PostgreSQL. Invoice, toko, pengaturan, pengguna, API key. Kecil, dan inilah sebenarnya yang backup Anda lindungi.
• nginx dengan sertifikat otomatis. Sebuah reverse proxy plus pendamping yang menerbitkan dan memperbarui sertifikat untuk hostname Anda. Inilah kenapa port 80 dan 443 harus benar-benar bisa dijangkau dari internet.
• Opsional, sebuah node Lightning (Core Lightning atau LND) dan sebuah daemon Monero lengkap dengan wallet RPC di sampingnya — masing-masing membawa chain-nya sendiri dan kebutuhan disk-nya sendiri.

Jadi pertanyaan sizing-nya bukan pernah “seberapa besar BTCPay harus dibuat”. Melainkan “berapa banyak chain yang saya simpan, dan berapa banyak chain-nya”. Jawab itu dan paketnya akan memilih dirinya sendiri.

Proyeknya mendokumentasikan 2 GB RAM dengan swap sebagai minimum dan 4 GB sebagai rekomendasi, dan jarak antara kedua angka itu adalah jarak antara instalasi yang secara teknis selesai dan instalasi yang berani Anda arahkan ke pelanggan. Application runtime, PostgreSQL, dan bitcoind yang sedang sync, berbagi 2 GB, akan tetap selesai — pelan-pelan, dengan swap file mengerjakan sesuatu yang seharusnya tidak perlu ia kerjakan.

Disk ditentukan oleh seberapa keras Anda melakukan pruning, dan deployment-nya mengekspos itu sebagai sebuah fragment yang Anda berikan ke installer. Keluarganya berjalan kira-kira opt-save-storage di sekitar 100 GB block file, -s di sekitar 50 GB, -xs di sekitar 25 GB dan -xxs di sekitar 5 GB. Yang terakhir itu jebakan untuk apa pun yang mau bertahan lama: riwayatnya disimpan terlalu sedikit sehingga maintenance biasa saja mulai gagal. Untuk sebuah toko, -s atau -xs adalah rentang yang masuk akal.

Angka konkret dari grid kami, karena “tergantung” bukan jawaban:

• Hanya Bitcoin, pruned, satu toko — Scout, 2 vCPU / 4 GB / 70 GB NVMe, $9.00/mo. Batas bawah yang jujur, dan jawaban yang tepat untuk kebanyakan pembaca.
• Bitcoin dan Lightning — Runner, 3 vCPU / 6 GB / 100 GB, $14.00/mo. Daemon Lightning ringan soal disk tapi keras kepala soal harus tetap online; headroom-nya untuk node di baliknya.
• Bitcoin, Lightning dan Monero — Alpha, 6 vCPU / 12 GB / 200 GB, $28.00/mo. Chain Monero yang pruned sendirian saja sekitar 85 GB, jadi dua chain dan dua indexer adalah titik di mana 8 GB mulai terasa tipis. Hunter (4 vCPU / 8 GB / 140 GB, $19.00/mo) cuma cukup kalau Bitcoin-nya tetap di-pruned keras dan dijaga tetap begitu.
• Node unpruned di belakang toko — proyek yang berbeda dengan tagihan yang berbeda. Panduan full-node punya angka-angkanya, dan itu mulai dari Fenrir.

CPU cuma penting tepat satu kali. Verifikasi signature selama initial block download bisa diparalelkan, jadi 2 sampai 4 vCPU mengubah sync pertama dari hitungan hari menjadi kira-kira satu hari saja, lalu kembali idle setelahnya. Bandwidth adalah biaya satu kali untuk seluruh chain, lewat port 1 Gbps dengan traffic unlimited dan tanpa tagihan kelebihan pemakaian di akhir bulan. Latency tidak relevan untuk payment processor, jadi pilih lokasi berdasarkan yurisdiksi, bukan berdasarkan milidetik — Amsterdam, Paris, Bucharest dan Sofia semuanya ada di harga dasar.

Daftar singkat, dan satu itemnya bukan soal teknis.

• Sebuah domain, dengan A record yang sudah mengarah ke server. Sertifikatnya diterbitkan lewat HTTP terhadap hostname itu, jadi DNS-nya harus sudah bisa di-resolve sebelum installer-nya berjalan, bukan pada saat itu juga. Subdomain seperti pay.example.com adalah bentuk yang normal.
• Port 80 dan 443 terbuka ke dunia luar. Port 80 bukan opsional meskipun tidak ada yang benar-benar melayani di situ setelahnya; certificate challenge-nya membutuhkannya.
• Debian 13 dari template library, di mesin yang sudah menjalani hardening sepuluh menit. Lakukan itu lebih dulu — jauh lebih sulit dilakukan dengan rapi begitu sebuah stack sudah berjalan.
• Wallet yang sudah Anda kuasai, beserta extended public key-nya. Sparrow, Electrum, atau hardware wallet. Siapkan itu di tangan sebelum Anda instal, supaya Anda tidak pernah tergoda membiarkan server membuatkannya untuk Anda.
• Alamat email untuk certificate authority-nya. Alamat ini cuma menerima peringatan masa berlaku dan tidak ada lagi.
• Keputusan soal pruning, dibuat sekarang. Berubah pikiran belakangan berarti resync chain dari nol, dan itu satu hari yang tidak akan Anda nikmati untuk dihabiskan dua kali.

Hampir semua akibat buruk dengan processor self-hosted bisa dilacak balik ke satu keputusan yang dibuat lebih awal dan asal-asalan: membiarkan server memegang sesuatu yang bisa di-spend. Ini layak dijelaskan secara eksplisit untuk tiga kasusnya, karena ketiganya benar-benar berbeda.

• Bitcoin on-chain: watch-only, selalu. BTCPay cuma memegang extended public key dan tidak ada lagi. Kalau box-nya dibobol, penyerang jadi tahu berapa yang Anda terima dan bisa mengubah ke mana invoice berikutnya mengarah — serangan yang nyata, dan alasan untuk mengecek ulang wallet toko Anda setelah ada insiden apa pun — tapi tidak bisa menyentuh coin yang sudah diterima.
• Lightning: hot menurut definisinya. Channel didanai dengan coin yang bisa di-spend oleh server, karena memang begitulah cara kerja sebuah channel. Ini pengecualian yang disengaja, dan bagian di atas sudah membahas sizing-nya.
• Monero: view-only, secara struktural. Private view key-nya membuka setiap pembayaran masuk tapi tidak mengotorisasi satu pun darinya. Tidak ada yang setara di sisi Bitcoin.

Satu fitur yang sengaja mendobrak model ini adalah Payjoin. Fitur ini membiarkan server Anda menyumbangkan sebuah input ke transaksi pelanggan, yang secara signifikan melemahkan heuristik common-input yang jadi andalan analisis chain, dan merupakan keuntungan privasi sungguhan untuk kedua pihak — tapi penerimanya harus bisa menandatangani, jadi butuh hot wallet di dalam BTCPay. Itu trade sungguhan, bukan fitur gratis. Ambil dengan sadar, dan danai seperti Anda mendanai Lightning wallet: dengan satu jumlah tertentu, bukan dengan semuanya.

Dan kalau Anda membiarkan setup wizard membuatkan wallet toko karena itu jalan tercepat: catat seed yang ditampilkannya, verifikasi di sebuah offline wallet, lalu rencanakan migrasi ke setup watch-only. Seed yang pernah berada di server yang menghadap internet adalah seed dengan hitungan mundur yang sudah berjalan.

Urutkan state-nya berdasarkan seberapa sulit untuk membuatnya ulang, karena jawabannya sangat berbeda-beda:

• Chain-nya. Bukan masalah backup. Ini data publik dan bisa resync, pelan-pelan dan gratis. Jangan pernah backup ini.
• Database-nya. Invoice, toko, pengaturan, pengguna, API key. Inilah backup yang sesungguhnya, ukurannya kecil, dan kalau hilang Anda kehilangan catatan akuntansi dari setiap penjualan — bukan uangnya, tapi berkasnya.
• Wallet on-chain Anda. Sudah aman, karena key-nya memang tidak pernah ada di sini. Itulah hasil dari langkah lima.
• State channel Lightning. Inilah yang bisa menggigit. Static channel backup memungkinkan Anda memulihkan dana di channel Anda setelah kehilangan total dengan cara memaksanya ditutup; ini tidak memulihkan channel-nya, dan tidak berguna kalau sudah basi. Ini berubah setiap kali sebuah channel dibuka atau ditutup, jadi tempatnya di salinan off-site otomatis, bukan di folder yang Anda ingat-ingat tiap tiga bulan.
• Wallet view-only Monero-nya. Bisa dibangun ulang dari alamat dan view key yang masih Anda pegang secara offline. Backup itu keduanya dan perlakukan file wallet-nya sebagai cache.

Deployment-nya sudah menyertakan helper yang melakukan ini dengan benar:

btcpay-backup.sh    # stops the stack, dumps Postgres, tars the config, restarts
btcpay-restore.sh   # puts one of those archives back

Jeda itu justru intinya — salinan hot dari database yang sedang berjalan bisa restore jadi sesuatu yang menarik. Enkripsi apa pun yang keluar dari mesin ini, dan ingat bahwa snapshot mingguan yang disertakan di setiap paket itu cuma kenyamanan, bukan backup: sebuah snapshot berada di tempat yang sama dengan yang sedang ia lindungi.

Kurang lebih diurutkan dari yang paling sering menghabiskan waktu semalaman seseorang:

• Sertifikatnya tidak pernah terbit. Sembilan dari sepuluh kali, A record-nya dibuat setelah installer-nya jalan, atau port 80-nya difilter. Perbaiki DNS-nya, pastikan namanya bisa di-resolve dari tempat yang bukan laptop Anda sendiri, lalu jalankan ulang setup script-nya. Mencoba berulang kali secara membabi buta ke certificate authority-nya akan kena rate limit dan menunggu seminggu, jadi ubah sesuatu di antara tiap percobaan.
• Extended key yang diimpor dengan riwayat menunjukkan saldo nol. Ini jebakan pruning. Indexer-nya menemukan pembayaran baru dengan mengawasi block baru, tapi merekonstruksi riwayat sebuah wallet yang sudah ada berarti membaca block yang sudah dihapus oleh node pruned. Pakai account baru untuk toko dan masalah ini tidak akan ada; kalau Anda memang harus mengimpor riwayat, Anda butuh node unpruned dan sebuah rescan.
• “Pelanggan sudah bayar dan invoice-nya masih terbuka.” Biasanya karena kurang bayar akibat fee dari wallet pengirim, invoice yang keburu kedaluwarsa saat pembayarannya masih belum terkonfirmasi, atau kebijakan konfirmasi yang lebih ketat daripada yang Anda ingat Anda pilih. Ketiganya adalah pengaturan, dan ketiganya alasan kenapa Anda menguji dulu dengan uang Anda sendiri.
• Node-nya diam-diam tertinggal. bitcoind yang macet tetap membagikan alamat dan kehilangan pembayaran tanpa mengeluh. Bandingkan block height Anda dengan sumber publik mana pun secara berkala dan beri alert kalau ada gap; ini bukan sesuatu yang sebaiknya Anda pelajari dari pelanggan.
• Update di saat yang salah. btcpay-update.sh berperilaku baik, tapi ia me-restart semuanya. Jalankan dengan sengaja, jangan pernah otomatis, dan jangan pernah pas lagi ramai penjualan.
• Alamatnya mendapat reputasi. Halaman checkout di IPv4 yang di-blocklist adalah halaman checkout yang diam-diam ditolak oleh sebagian jaringan korporat dan filter mail. Setiap paket di sini menyertakan alamat dedicated tanpa riwayat, dan itu layak dicek sebelum Anda mencetak domainnya di mana pun.

Software-nya menghilangkan satu pihak lawan transaksi. Ia tidak menghilangkan sisa permukaannya, dan bersikap jujur soal itu jauh lebih berguna daripada daftar fitur lainnya.

Domain adalah titik lemahnya. Ia terdaftar di suatu tempat, ia bisa di-resolve secara publik, dan itulah hal pertama yang dilihat siapa pun. Sebuah processor yang self-hosted di hostname yang didaftarkan atas nama Anda sendiri di registrar di negara Anda sendiri sudah memindahkan uangnya keluar dari tangan pihak ketiga tapi meninggalkan identitasnya persis di tempat semula. Kalau itu penting untuk apa yang Anda jual, registrar-nya layak mendapat perhatian setidaknya sebesar host-nya.

Yurisdiksi adalah variabel yang nyata. Di mana mesinnya berada menentukan perintah pengadilan siapa yang bisa menjangkaunya dan berapa banyak proses yang menghalangi. Itu soal friksi dan jarak, bukan kekebalan — poin yang dijabarkan panjang lebar oleh entri offshore hosting, dan layak dibaca sebelum memilih bendera dibanding jaringan.

Akun adalah mata rantai terakhirnya. Menyewa server dengan alamat email dan membayar dengan Monero berarti tidak ada laporan kartu yang mengaitkan halaman checkout ke sebuah bank — hal aneh untuk terlewatkan padahal seluruh maksud sistem ini adalah supaya tidak butuh itu. Setiap paket di sini no-KYC secara default, dan setiap lokasi menyertakan IPv4 bersih dedicated dengan reverse DNS custom.

Dan batasnya dinyatakan, bukan diisyaratkan. Node, processor, dan toko adalah infrastruktur biasa dan disambut baik di sini; acceptable-use policy-nya singkat, publik, dan punya batas dasar. Apakah Anda butuh lisensi untuk menerima pembayaran adalah pertanyaan soal apa yang Anda jual dan di mana Anda berada, bukan soal software-nya — dan itu pertanyaan untuk orang yang kompeten, bukan untuk panduan hosting.