−25%

Windows รายปี ถึง 31 ต.ค. ดูแพ็กเกจ

EQVPS
เริ่มต้นใช้งาน

VPS สำหรับ BTCPay Server: รับคริปโตเองบนเซิร์ฟเวอร์

BTCPay Server พร้อมโหนด Bitcoin แบบ pruned ของตัวเอง เงินเข้ากระเป๋าคุณโดยตรง ไม่มีตัวกลาง การติดตั้งที่ทดสอบแล้ว และการคำนวณดิสก์สำหรับ 35 GB

ตัวกลางรับชำระเงินทุกรายมาพร้อมเงื่อนไขของตัวเอง KYC ของตัวเอง และปุ่มอายัดยอดเงินของตัวเอง BTCPay Server ตัดตัวกลางออกไป ใบแจ้งหนี้ถูกสร้างบนเซิร์ฟเวอร์ของคุณ ลูกค้าโอนไปยังที่อยู่ที่สร้างจากกระเป๋าเงินของคุณ และโหนด Bitcoin ของคุณเองเป็นผู้ยืนยันการชำระ ไม่มีใครปิดมันได้นอกจากคุณ

เหมาะกับร้านค้า ฟรีแลนซ์ และบริการที่รับ bitcoin อยู่แล้ว หรืออยากรับ และไม่อยากยกงานนี้ให้บริษัทใด

เลือกแพ็กเกจไหน

BTCPay รันเป็นคอนเทนเนอร์ราวเจ็ดตัว ได้แก่ แอป BTCPay, NBXplorer (คอยดูเชน), Bitcoin Core, Postgres และ nginx ด้านหน้าพร้อม Let's Encrypt อัตโนมัติ บนเซิร์ฟเวอร์ทดสอบของเรา ช่วงเริ่มต้นใช้ RAM ราว 0.7 GB และ Bitcoin Core จะใช้มากขึ้นระหว่างซิงก์ 4 GB ก็เหลือเฟือ ข้อจำกัดที่แท้จริงคือดิสก์ ไม่ใช่หน่วยความจำ

การตั้งค่าแพ็กเกจ
BTC แบบ on-chain โหนด pruned เก็บบล็อก ~5 GBSmall-IP: 4 vCPU, 4 GB, 35 GB ($16/เดือน)
แบบเดียวกัน แต่มีที่เผื่อสำหรับ log และการอัปเดตMedium-IP: 6 vCPU, 6 GB, 45 GB ($20/เดือน)
Lightning หน้าต่างบล็อกที่ใหญ่ขึ้น หรือเหรียญที่สองPro-32: 8 vCPU, 32 GB, 400 GB ($40/เดือน), ตามคำขอ

คุณต้องใช้แพ็กเกจที่มี IPv4 ของตัวเอง เพราะลูกค้าเข้าถึง BTCPay ผ่าน HTTPS และ Let's Encrypt ต้องเข้าถึงพอร์ต 80 ได้ เลือกเยอรมนีหรือฟินแลนด์ตามที่มีว่างตอนสั่งซื้อ สำหรับหน้าชำระเงิน latency แทบไม่มีผล และเมื่อจุดประสงค์คือรับคริปโต ก็เหมาะที่ตัวเซิร์ฟเวอร์เองจะจ่ายด้วยคริปโตได้โดยไม่ต้องทำ KYC

การติดตั้ง

ชี้ pay.example.com ไปที่เซิร์ฟเวอร์ จากนั้นในฐานะ root บน Ubuntu 24.04 หรือ Debian 12 ที่เพิ่งติดตั้ง:

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 จะ prune บล็อกจนเหลือ 5 GB สคริปต์จะดึง image สร้างบริการ systemd ชื่อ btcpayserver และเริ่มทุกอย่าง ระหว่างทางยังรีสตาร์ท Docker daemon ด้วย นี่เป็นอีกเหตุผลที่ควรให้ BTCPay มีเซิร์ฟเวอร์ของตัวเอง แทนการยัดไว้ข้างคอนเทนเนอร์อื่น

ตรวจสอบโหนด:

bitcoin-cli.sh getblockchaininfo

เทียบ blocks กับ headers และดูว่ามี "pruned": true ยี่สิบนาทีหลังเริ่มทดสอบ เราได้ราว 218,000 จากประมาณ 972,000 บล็อก บล็อกช่วงแรกมีขนาดเล็กมาก อย่าเอาไปประมาณเวลา งานจริงจะมาทีหลัง

ล็อกอินครั้งแรก: ทำทันที

เปิด https://pay.example.com ทันทีที่มันตอบสนอง BTCPay จะพาคุณไปหน้าลงทะเบียน และ บัญชีแรกจะกลายเป็นผู้ดูแลเซิร์ฟเวอร์ ถ้าคนอื่นเจอหน้านี้ก่อนคุณ เซิร์ฟเวอร์รับชำระเงินของคุณก็จะเป็นของคนนั้น ลงทะเบียนให้เรียบร้อย แล้วเข้าไปที่ Server Settings → Policies เพื่อตั้งค่าการสมัครใหม่ตามที่ต้องการ

จากนั้นสร้างร้านและเชื่อมกระเป๋าเงินด้วย extended public key (xpub) จากกระเป๋าฮาร์ดแวร์หรือไฟล์ส่งออกของกระเป๋าบนเดสก์ท็อป BTCPay จะสร้างที่อยู่ใหม่ให้ทุกใบแจ้งหนี้และไม่เคยเห็นคีย์ส่วนตัว ใช้กระเป๋าใหม่หรือบัญชีใหม่สำหรับงานนี้ แทนกระเป๋าที่มีประวัติหลายปี เพราะโหนดแบบ pruned ถนัดติดตามสิ่งที่เกิดขึ้นนับจากนี้ไป

จนกว่าโหนดจะตามเครือข่ายทัน BTCPay จะแสดงว่ายังซิงก์อยู่และไม่ติดตามการชำระเงิน วางแผนเปิดใช้หลังซิงก์เสร็จ ไม่ใช่คืนเดียวกับที่ติดตั้ง

สิ่งที่ควรรู้ก่อนเปิดใช้งานจริง

  • การซิงก์ครั้งแรกใช้เวลานาน โหนดแบบ pruned ยังต้องดาวน์โหลดและตรวจสอบเชนทั้งหมด กว่า 700 GB ก่อนจะทิ้งบล็อกเก่าได้ ทราฟฟิกบนแพ็กเกจของเราไม่จำกัดที่ 1 Gbit/s จึงไม่มีค่าใช้จ่ายเพิ่ม แต่บนเซิร์ฟเวอร์ 4 vCPU ให้นับเป็นวัน ใน repository มีสคริปต์ซิงก์เร็ว ซึ่งข้ามงานนี้ด้วยการเชื่อสำเนาชุด UTXO ของคนอื่น และนั่นลบเหตุผลส่วนหนึ่งที่คุณรันโหนดเอง
  • การอัปเดต btcpay-update.sh ดึง BTCPay รุ่นล่าสุดพร้อม dependency รันตอนที่เงียบ ๆ ไม่ใช่กลางช่วงโปรโมชัน
  • สิ่งที่ต้องสำรอง เมื่อใช้กระเป๋าที่เชื่อมด้วย xpub อย่างเดียว เหรียญของคุณไม่ได้อยู่บนเซิร์ฟเวอร์ สิ่งที่อาจหายคือการตั้งค่าร้านและประวัติใบแจ้งหนี้ใน Postgres ให้สำรอง volume นั้น และเก็บ seed ของกระเป๋าไว้ในที่ที่ไม่เกี่ยวกับเซิร์ฟเวอร์นี้เลย
  • Lightning ไว้ทีหลัง เริ่มจาก on-chain ก่อน Lightning หมายถึงหน้าต่างบล็อกที่ใหญ่ขึ้น การจัดการช่องทาง และสภาพคล่องขาเข้า ถือเป็นโปรเจกต์แยก และเป็นแพ็กเกจ Pro ที่เราตั้งให้ ตามคำขอ

ความเห็นของฉัน: สำหรับร้านเล็กที่รับ bitcoin วันละครั้ง BTCPay บน Small-IP คือการตั้งค่าที่เรียบร้อยที่สุด ถ้าคุณต้องการรับบัตรหรือถอนเป็นเงินเฟียต นี่ไม่ใช่เครื่องมือนั้น

ที่เกี่ยวข้อง

พร้อม deploy แล้วหรือยัง? จ่ายด้วยคริปโต ไม่ต้อง KYC — ใช้งานได้ในราวหนึ่งนาที

Deploy เลย →

FAQ

BTCPay Server ใช้ดิสก์เท่าไร?

เมื่อใช้โปรไฟล์ opt-save-storage-xxs โหนด Bitcoin จะเก็บบล็อกไว้เพียงราว 5 GB บวกกับ chainstate (ชุด UTXO ราวสิบกว่า GB และยังโตขึ้น) image ของ Docker ราว 2.5 GB และระบบปฏิบัติการ รวมแล้วพอดีกับ 35 GB ของ Small-IP ส่วนโปรไฟล์ถัดไป opt-save-storage-xs เก็บบล็อก 25 GB ด้วยตัวเองและต้องใช้แพ็กเกจ Pro ซึ่งมีให้ตามคำขอ

การซิงก์ครั้งแรกใช้เวลานานแค่ไหน?

เป็นวัน ไม่ใช่เป็นชั่วโมง แม้แต่โหนดแบบ pruned ก็ต้องดาวน์โหลดและตรวจสอบ blockchain ของ Bitcoin ทั้งหมด ซึ่งเป็นทราฟฟิกกว่า 700 GB แล้วจึงทิ้งบล็อกเก่า ทราฟฟิกบนแพ็กเกจของเราไม่จำกัด การดาวน์โหลดจึงไม่มีค่าใช้จ่ายเพิ่ม แต่ BTCPay จะไม่เห็นการชำระเงินจนกว่าโหนดจะตามเครือข่ายทัน

BTCPay เก็บเหรียญของฉันไว้หรือเปล่า?

ไม่ ถ้าคุณเชื่อมกระเป๋าเงินด้วย extended public key (xpub) เซิร์ฟเวอร์จะสร้างที่อยู่และติดตามการชำระเงินได้ แต่ไม่มีคีย์ส่วนตัวและใช้จ่ายอะไรไม่ได้ ถ้าเซิร์ฟเวอร์หาย สิ่งที่หายคือการตั้งค่าร้าน ไม่ใช่เงิน

ต้องใช้ IP ของตัวเองไหม?

ต้อง ร้านของคุณและเบราว์เซอร์ของลูกค้าต้องเข้าถึง BTCPay ทางพอร์ต 443 และ Let's Encrypt ต้องใช้พอร์ต 80 เพื่อออกใบรับรอง แพ็กเกจ NAT รับจากภายนอกได้เพียงพอร์ต SSH ของคุณ

รับ Lightning หรือ Monero ได้ด้วยไหม?

มีให้เลือกทั้งสองอย่าง แต่ไม่มีอันไหนพอดีกับแพ็กเกจเล็ก โหนด Lightning ต้องการหน้าต่างบล็อกที่ใหญ่กว่าและการดูแลมากกว่าการชำระแบบ on-chain ส่วนโหนด Monero ต้องใช้ดิสก์มากกว่าโหนด Bitcoin แบบ pruned มาก เริ่มจาก bitcoin แบบ on-chain บน Small-IP ก่อน ส่วนสองอย่างนั้น ถามเราเรื่องแพ็กเกจ Pro ได้

ความคิดเห็น

ยังไม่มีความคิดเห็น เป็นคนแรกสิ

แสดงความคิดเห็น

ความคิดเห็นจะถูกตรวจสอบก่อนแสดง