Fiecare procesator de plăți din mijloc vine cu propriile condiții, propriul KYC și propriul buton care îți îngheață soldul. BTCPay Server elimină mijlocul. Facturile se creează pe serverul tău, clientul plătește la o adresă derivată din portofelul tău, iar propriul tău nod Bitcoin confirmă plata. Nimeni în afară de tine nu îl poate opri.
E pentru magazine, freelanceri și servicii care deja primesc bitcoin — sau vor să primească — și preferă să nu lase treaba asta în seama unei companii.
Ce plan
BTCPay rulează ca vreo șapte containere: aplicația BTCPay, NBXplorer (care urmărește lanțul), Bitcoin Core, Postgres și un nginx în față cu Let's Encrypt automat. Pe serverul nostru de test au folosit circa 0,7 GB RAM la pornire, iar Bitcoin Core ia mai mult în timpul sincronizării; 4 GB ajung din plin. Adevărata limită e discul, nu memoria.
| Configurație | Plan |
|---|---|
| BTC on-chain, nod tăiat cu ~5 GB de blocuri | Small-IP — 4 vCPU, 4 GB, 35 GB ($16/lună) |
| La fel, cu mai multă rezervă pentru loguri și actualizări | Medium-IP — 6 vCPU, 6 GB, 45 GB ($20/lună) |
| Lightning, o fereastră de blocuri mai mare sau o a doua monedă | Pro-32 — 8 vCPU, 32 GB, 400 GB ($40/lună), la cerere |
Ai nevoie de un plan cu IPv4 propriu: clienții ajung la BTCPay prin HTTPS, iar Let's Encrypt trebuie să ajungă la portul 80. Există două locații din UE (disponibilitatea se vede la comandă); pentru o pagină de plată, latența contează prea puțin. Și cum ideea e tocmai să primești cripto, se potrivește ca și serverul să se plătească în cripto, fără KYC.
Instalare
Îndreaptă pay.example.com spre server, apoi, ca root pe un Ubuntu 24.04 sau Debian 12 proaspăt:
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 e cel care face totul să încapă: Bitcoin Core taie blocurile până la 5 GB. Scriptul descarcă imaginile, creează un serviciu systemd btcpayserver și pornește tot. Pe drum repornește și daemonul Docker — încă un motiv să-i dai lui BTCPay un server al lui, în loc să-l înghesui lângă alte containere.
Verifică nodul:
bitcoin-cli.sh getblockchaininfo
Compară blocks cu headers și uită-te la "pruned": true. După douăzeci de minute de test ajunsesem la circa 218.000 din aproximativ 972.000 de blocuri — primele sunt minuscule, așa că nu extrapola. Munca adevărată vine mai târziu.
Prima autentificare: fă-o acum
Deschide https://pay.example.com imediat ce răspunde. BTCPay te trimite la o pagină de înregistrare, iar primul cont devine administratorul serverului. Dacă altcineva găsește pagina înaintea ta, serverul tău de plăți e al acelei persoane. Înregistrează-te, apoi uită-te în Server Settings → Policies și setează noile înregistrări cum vrei.
Apoi creează un magazin și conectează-ți portofelul prin cheia publică extinsă (xpub) — dintr-un portofel hardware sau din exportul portofelului desktop. BTCPay derivă o adresă nouă pentru fiecare factură și nu vede niciodată o cheie privată. Folosește pentru asta un portofel nou sau un cont nou, nu unul cu ani de istoric: unui nod tăiat îi place cel mai mult să urmărească ce se întâmplă de acum înainte.
Până când nodul prinde din urmă rețeaua, BTCPay arată că încă sincronizează și nu urmărește plăți. Planifică lansarea după sincronizare, nu pentru seara în care instalezi.
Ce trebuie să știi înainte de lansare
- Prima sincronizare e lungă. Un nod tăiat tot descarcă și verifică întregul lanț — peste 700 GB — înainte să poată arunca blocurile vechi. Traficul pe planurile noastre e nelimitat la 1 Gbit/s, deci nu costă nimic în plus, dar pe un server cu 4 vCPU socotește în zile. În repository există un script de sincronizare rapidă; sare peste această muncă având încredere în copia setului UTXO a altcuiva, ceea ce anulează o parte din motivul pentru care ții un nod propriu.
- Actualizări.
btcpay-update.shaduce cea mai nouă versiune BTCPay și dependențele. Rulează-l într-o oră liniștită, nu în mijlocul unei campanii de reduceri. - Ce salvezi. Cu un portofel conectat doar prin xpub, monedele tale nu sunt pe server. Ce ai pierde sunt configurația magazinului și istoricul facturilor din Postgres — fă backup acelui volum și păstrează seed-ul portofelului într-un loc care n-are nicio legătură cu acest server.
- Lightning mai târziu. Începe on-chain. Lightning înseamnă o fereastră de blocuri mai mare, administrarea canalelor și lichiditate de intrare — un proiect separat și un plan Pro, pe care îl configurăm la cerere.
Părerea mea: pentru un magazin mic care primește bitcoin o dată pe zi, BTCPay pe Small-IP e cea mai curată configurație posibilă. Dacă ai nevoie de plăți cu cardul sau de retrageri în monedă fiat, nu e unealta potrivită.
Articole conexe
- Propriul nod Bitcoin pe un VPS — doar nodul, dacă vrei să-ți verifici portofelul
- Propriul nod Monero pe un VPS
- Crypto VPS — plata serverelor în cripto
- VPS pentru un site cu IP propriu — magazinul care trimite clienții la BTCPay
- Cum configurezi un firewall ufw
Comentarii
Încă nu există comentarii. Fii primul.