Self-hospedar un BTCPay Server en un VPS

Nodo de Bitcoin podado en NVMe, puertos 80/443/8333/9735, Prime desde $9.60/mes en plan anual. Sin KYC, pago solo en cripto. Cobra a tu propia cartera hoy.

Ser dueño del raíl en lugar de alquilarlo

La comparación de comisiones es el argumento más débil para self-hospedar BTCPay — el poderoso es la custodia. Un procesador externo puede congelar tu checkout, retener un reserve rodante o exigir la documentación de tus compradores; tu propio nodo emite las facturas, las liquidaciones caen directamente en tu cartera y ninguna contraparte se interpone entre tú y la cadena. El raíl de pagos deja de ser una suscripción para convertirse en propiedad.

Mecánicamente, BTCPay Server es un procesador libre y autocustodial: las facturas derivan de direcciones que tu nodo vigila, y el nodo valida cada liquidación contra la cadena en lugar de fiarse de la palabra de una API (la documentación del proyecto describe la arquitectura — documentación de BTCPay Server). Las apps de punto de venta, las páginas de crowdfunding y la Greenfield API cuelgan todas del mismo saldo autoverificado, así que la pregunta de la confianza migra de la solvencia de una empresa a la disciplina de tus copias de seguridad.

La elección del hosting pertenece al mismo diseño: si la gracia de BTCPay es expulsar al intermediario de los pagos, una máquina que exige pasaporte lo reinstala en la capa de infraestructura. El registro aquí es con token o email más una contraseña de 12 caracteres, la factura es solo en cripto entre diecinueve monedas, y no se entregan documentos de KYC — la guía del checkout con datos mínimos explica qué significa eso y qué no, y la guía de compra te acompaña en el pedido mismo.

Hay además una simetría de aprovisionamiento que vale la pena notar: las monedas que acepta tu hosting son las monedas con las que tus clientes pueden pagarte. Un solo libro contable — BTC, XMR, USDT en sus redes y el resto de las diecinueve — liquida tanto la factura de la infraestructura como los ingresos de la tienda, lo que reduce la superficie de conciliación de dos pilas de pago a una y tacha del organigrama al último procesador de tarjetas.

El error clásico: self-hospedar el procesador dejando la custodia a medias — semillas en el mismo volumen que la aplicación, ninguna restauración probada, ninguna copia offline. BTCPay prescinde del tercero; no te exime de tu deber con las claves. Trata el despliegue como un proyecto de custodia que casualmente luce una interfaz web, y las preguntas de dimensionamiento de las próximas secciones se vuelven aritmética llana en vez de debates existenciales.

El suelo del dimensionamiento lo pone el nodo, no el checkout

La sorpresa en todos los hilos sobre dimensionar BTCPay: el checkout web cuesta casi nada operar, y el nodo de Bitcoin que hay detrás fija el suelo entero. La validación de bloques —no la renderización de facturas— devora CPU durante la sincronización y memoria durante el trabajo de índices; así que dimensionas para un nodo que de paso sirve un checkout, nunca al revés, y la modestia de tu volumen de pedidos es irrelevante para esta aritmética.

El suelo práctico aquí es Prime — 4 vCPU, 8 GB DDR5, 160 GB NVMe a $12 de lista, $9.60 en el término anual — que arrastra un nodo podado más el checkout web con margen para una tienda pequeña. Contrata Prime a $9.60/mes en plan anual ($12 de lista) como base y sube de escalón cuando llegue el volumen de Lightning; Titan a $24 de lista ($19.20 en plan anual, 8 vCPU y 32 GB ECC) es el nivel cómodo cuando el enrutamiento se vuelve una ocupación de verdad. Ambos niveles están publicados en el catálogo de planes.

Por qué los números se inclinan así: durante la descarga inicial de bloques el nodo valida cada bloque hasta volver al génesis — verificación ligada al procesador que presiona sobre los carriles de escritura NVMe — y tras sincronizar se queda dormido con una CPU de un dígito bajo mientras las facturas fluyen. La ruta del checkout en sí es un puñado de peticiones por pedido. El NVMe local en todos los planes es lo que comprime esa primera descarga de días a horas, por eso la clase de almacenamiento importa más que el tamaño aquí.

Un hábito de dimensionamiento que trasciende BTCPay: mide por separado la línea base dormida y el pico sincronizado. El nodo pasa la mayor parte de su vida en reposo y se abalanza durante la sincronización, la reconstrucción de índices y el reíndice tras un fallo; la tienda pasa la mayor parte de su vida en reposo y se abalanza durante las campañas. Comprar para el embestida y no para la siesta es toda la disciplina — y las dos embestidas rara vez comparten hora, que es justamente lo que hace negociable la convivencia en una sola máquina.

El error: dimensionar por volumen de facturas — veinte pedidos al día suena minúsculo — y comprar una porción simbólica, para luego preguntarse por qué la sincronización de la cadena devora una semana y el checkout expira a mitad de sync. El nodo es el inquilino que nunca duerme; dimensiona para él y el checkout viaja gratis. Las próximas secciones recorren las decisiones de disco, puertos y Lightning en exactamente ese orden.

El pruning: la única decisión de disco que debes tomar el día uno

No necesitas terabytes para operar un nodo que verifica por completo — el pruning mantiene íntegra la validación y descarta datos de bloques antiguos que nunca volverás a servir. La pregunta del disco no es cuánto ha crecido la cadena, sino cuántos datos recientes exigen tus propósitos, y la respuesta se fija una vez, en megabytes, antes de que arranque la primera sincronización.

La mecánica: el techo -prune=N de Bitcoin Core limita el almacenamiento de bloques a N megabytes mientras el conjunto UTXO y los índices permanecen intactos — el documento de pruning del repositorio de Core define el comportamiento y su suelo (doc de pruning de Bitcoin Core — doc/pruning.md). El despliegue Docker de BTCPay expone el ajuste a través de su entorno en lugar de un config editado a mano, y la ruta soportada es el repositorio btcpayserver-docker (btcpayserver-docker), cuyo btcpay-setup.sh regenera la pila tras cada cambio.

Una primera descarga podada sobre NVMe local se mide en horas, no en días — los 160 GB de NVMe en Prime alojan un nodo podado con holgura, y los 80 GB en Core también lo alojan mientras el objetivo siga siendo moderado. En metal, los 4×2 TB de Monolith son territorio de archivo: bloques completos retenidos para los oficios que de verdad los quieren, tras un puerto de 25 Gbps con un scrubber L3/L7 de guardia.

Elige el objetivo con la carga de trabajo, no con la ansiedad: un checkout que solo necesita saldos actuales e historia reciente vive muy por debajo de un archivo completo, mientras que un explorador de bloques o un hobby de analítica legítimamente quiere todo. El error bajo la mayoría de los arrepentimientos con el pruning es dimensionar para una ambición que el proyecto nunca declaró — decide qué consultas vas a ejecutar de verdad, y la cifra en megabytes cae de la respuesta como un recibo.

El tropiezo clásico: empezar sin podar para conservar opciones con un volumen pequeño, llenar el NVMe a mitad de sincronización y reiniciar la descarga entera tras la limpieza. Decide el objetivo primero — la mayoría de los despliegues solo para checkout nunca vuelve a servir bloques antiguos — y deja que el presupuesto de disco siga al veredicto. La paciencia a través de esta única sincronización compra verificabilidad para cada factura que venga después.

Puertos y TLS: tres aperturas, un dominio

La superficie de red de una máquina BTCPay es más pequeña de lo que esperan los novatos: 80 y 443 sirven el checkout, 8333 recibe peers entrantes del nodo, y 9735 se suma solo cuando llega Lightning. Todo lo demás — el RPC de la cartera sobre todo — se queda en loopback, y el despliegue es más tranquilo y más seguro por esa contención que cualquier pila de aperturas dictada por un panel.

Apunta un dominio a la máquina antes de la primera ejecución: el arreglo Docker solicita y renueva el certificado automáticamente contra ese hostname, y aquí importa el registro A — los límites de tarifa de Let's Encrypt toleran un despliegue pero no reintentos cada hora contra un DNS mal configurado (límites documentados — límites de tarifa de Let's Encrypt). Deja el registro bien una vez y el TLS deja de ser un evento durante la vida de la máquina, renovándose solo mientras duermes.

El puerto 8333 entrante es como tu nodo aporta peers a la red y se entera antes de los bloques nuevos; dejarlo cerrado funciona, pero te convierte en oyente en vez de participante. Audita la superficie de escucha con ss -tlnp tras la instalación — la página man de la herramienta de sockets anota cada columna (manual de ss(8)) — y confirma que nada más allá de los tres puertos mira a internet público.

Repasa la auditoría tras cada cambio de pila, no solo una vez: una actualización, un plugin o una sesión de depuración que dejara un listener ligado a 0.0.0.0 sobrevivirá a su autor. Una comparación semanal entre la superficie de escucha y la línea base esperada de tres puertos convierte la deriva de configuración de un descubrimiento en una alerta — el mismo hábito que mantiene honesto un firewall mantiene honesta la máquina de una cartera.

El error clásico: exponer el puerto RPC del nodo para que las integraciones resulten más cómodas — la interfaz RPC manda sobre la cartera, y pertenece al loopback detrás de la aplicación, nunca a una interfaz pública. Tres puertos, un dominio, todo lo demás denegado: el checkout es público, el nodo es un peer, la cartera es inalcanzable. Con la superficie resuelta, la pregunta de Lightning se vuelve una mejora y no una exposición.

Lightning: cuando los núcleos extra pagan el alquiler

Lightning no exige un disco mayor sino una promesa de uptime. Los canales requieren la IPv4 estable que trae todo plan, 9735 desbloqueado y un nodo que nunca desaparece durante horas, porque un nodo de enrutamiento que se echa una siesta suelta los pagos que se comprometió a reenviar. Por eso la mejora que importa es fiabilidad y núcleos, nunca volumen de almacenamiento.

Las dos implementaciones principales corren bajo el despliegue Docker de BTCPay — LND (su repositorio documenta la gestión de canales — repositorio de lnd) y Core Lightning (documentación de Core Lightning). La liquidación on-chain confirma en minutos a una hora; Lightning liquida en milisegundos y el carrito del comprador nunca espera. Para un checkout esa es la diferencia entre pagado-pendiente y pagado — un matiz que tu pipeline de pedidos siente en la primera venta de la mañana.

La adición operativa es la recuperación: antes de abrir canales, exporta la copia de seguridad estática de canales — channel.backup en LND — y guárdala en algún sitio que la máquina nunca haya conocido, porque los canales son estado y las máquinas son reemplazables. Las watchtowers aportan una segunda línea de defensa para los períodos de ausencia. En Titan los núcleos adicionales absorben la carga de enrutamiento sin quejarse; en Prime, el enrutamiento ligero de escala personal se porta bien y el reenvío intensivo se resiente.

La liquidez merece la misma deliberación que las copias de seguridad: abre canales hacia peers bien conectados, equilibra la capacidad entrante y saliente, y resiste el impulso de verter fondos en un único canal gigante. Un nodo de enrutamiento es un pequeño market maker; su utilidad se mide en la diversidad de sus conexiones y no en el grosor de una sola tubería, y la disciplina escala con elegancia hasta un checkout que solo quiere liquidación instantánea.

El error: abrir canales el día uno con fondos que no puedes permitirte bloquear, antes de que el flujo de facturas haya demostrado lo que vale. Los canales son compromisos denominados en meses; prueba primero el checkout con facturas on-chain y luego financia el enrutamiento con deliberación. Lightning es la mejora que hace que los núcleos extra de Titan paguen alquiler — y también el componente que convierte un botón de pago en una operación 24/7 con obligaciones reales.

Por qué el encaje sin KYC es estructural, no cosmético

Emparejar un procesador autocustodial con un hosting que se salta las verificaciones de identidad no es una rima de marketing — cierra la misma brecha en ambas capas. Un procesador que no verificara los papeles de nadie mientras vive en un host que verifica los de todos solo reubicaría el punto de estrangulamiento. De punta a punta, este despliegue no pide ninguno de los dos: registro con token o email, diecinueve monedas, ningún documento — y puedes estar en línea en una tarde desde que lo decidas.

El checkout refleja el hosting: los compradores liquidan en BTC, XMR o USDT en sus redes, o en cualquiera de las demás monedas que ofrece la factura, y el pago aterriza en tu cartera — no en una cuenta agrupada de un procesador. XMR es de primera clase aquí, y USDT viaja por TRC-20, ERC-20, BEP-20, SPL, Polygon, Arbitrum y Optimism. Las monedas que acepta tu factura de hosting son, por construcción, las monedas con las que tus clientes pueden pagarte.

La postura de privacidad es factual, no mística: sin registros de tráfico de carga útil ni de invitados, facturación y acciones del panel retenidas, metadatos de conexión conservados como máximo 24 h, scrubbing DDoS incluido. El abuso se juzga bajo la ley de la ubicación de la instalación, y por eso la jurisdicción es una decisión de verdad — Reikiavik y Zúrich llevan primas de +20% y +35% por sus regímenes legales, la tabla de ubicaciones imprime la ley de cada una de las doce sedes y la guía offshore las compara.

Ajusta la jurisdicción a la audiencia del checkout, en el sentido diplomático: si tu base de clientes se concentra en una región, una instalación cuyo régimen legal puedes leer de verdad le gana a una elección al azar guiada solo por el precio. Las ciudades de prima justifican su sobrecargo solo cuando sus protecciones específicas importan a tu operación; para la mayoría de los checkouts la respuesta honesta es que cualquiera de las doce sirve, y debe decidir la hoja de especificaciones en vez del folclore.

El error: tratar el registro sin fricción como un escudo. El hosting sin KYC elimina a un corredor de datos; no vuelve el tráfico inatribuible, y el abuso se resuelve igual bajo la ley de la instalación que en cualquier otro sitio. Usa la postura para lo que es — menos papeleo entre tú y tu infraestructura — y deja que la seguridad operativa habite tus propios hábitos: claves, copias de seguridad, actualizaciones y un modelo de amenazas que puedas mantener de verdad.

Convivir con la tienda en la misma máquina: aritmética honesta

La misma máquina puede cargar con la tienda, y para la mayoría de los pequeños comercios debería — pero la honestidad del dimensionamiento debe incluir los peores minutos del nodo, no su tarde promedio. Las sincronizaciones de cadena, las reconstrucciones de índices y los reescaneos de Lightning son los tramos en que el nodo se abalanza sobre la memoria, y esos tramos son justo cuando una tienda que comparte máquina es más visible para los clientes que la sostienen.

La aritmética en Prime: nodo, checkout y tienda comparten 8 GB, y el pico de la tienda es tu pico de tráfico, que coincide o no con el del nodo. Observa con docker stats durante una sincronización forzada en staging — las banderas de recursos de la documentación de Docker muestran cómo poner techo a cada servicio (restricciones de recursos de Docker) — y dale al nodo un techo de memoria para que la tienda siga respondiendo mientras la cadena hace su levantamiento de peso ocasional.

Cuando los picos chocan en la práctica, la mejora es un solo escalón de plan: Titan a $24 de lista — $19.20 en el término anual — duplica los núcleos a 8, cuadruplica la memoria a 32 GB ECC y disuelve por completo la pregunta de la colisión. Pasa a Titan a $19.20 en plan anual antes de la temporada alta de la tienda, nunca durante; el delta es una línea de factura contra una tarde entera de caída y su estela de reputación.

El truco del staging vuelve empírica la decisión en lugar de ansiosa: reproduce un día de tráfico real contra la pila conviviente mientras el nodo está a mitad de sincronización, en una máquina de pruebas, antes de la temporada que importa. Si la tasa de errores de la tienda aguanta, la convivencia está bien y el dinero se queda en tu bolsillo; si tiembla, has medido exactamente cuánto margen pedirá la campaña, y el escalón de plan deja de ser una suposición.

El tropiezo clásico: dimensionar por la CPU promedio de la tienda y toparse con el nodo en la primera campaña — las dos cargas hacen pico juntas los días de rebaja, con tráfico y liquidación llegando en la misma hora. Catálogo pequeño, tráfico estable: una sola máquina es lo correcto. Acantilados impulsados por campañas: separa los niveles y deja que el DNS decida quién atiende. En cualquier caso, vigila la memoria y no la CPU, porque la memoria es donde el nodo gana la disputa.

Facturas en Monero y la realidad de los plugins

Los clientes pueden pagar en XMR a través de BTCPay — mediante plugins de la comunidad en lugar del flujo del núcleo, y esa distinción conlleva un filo operativo: la madurez de los plugins va por detrás del núcleo, y un checkout en producción es el peor lugar concebible para hacer beta-testing. Si las facturas en Monero crecen hasta ser la mayoría de tu volumen, la integración se ha ganado un ensayo en staging antes de encarar jamás a un extraño que paga.

El flujo del núcleo es BTC y Lightning: las facturas derivan de direcciones vigiladas, y las confirmaciones las cuenta tu propio nodo. Los plugins comunitarios injertan Monero ejecutando monerod junto a la pila y vigilando los destinos XMR con la misma lógica autocustodial — las interfaces RPC de la cartera están documentadas en las guías de desarrolladores de Monero (guías de desarrolladores de Monero). La arquitectura rima con la del propio BTCPay: tu daemon, tu cartera, tu verificación, sin ningún salto custodial en medio.

Como alternativa, acepta XMR por completo fuera de BTCPay — una dirección estática, o una pasarela mínima en un segundo subdominio — y mantén los dos flujos ajenos. Ese cambio troca reporting unificado por sencillez: el checkout de BTC y Lightning se queda en el núcleo curtido en mil batallas, y el lado Monero corre su propia pequeña pila con su propio ritmo de actualizaciones. Ambos siguen siendo autocustodiales; solo cambia la superficie operativa, y la guía de pagos en Monero cubre la ruta directa.

Elijas la ruta que elijas, ensaya la recuperación en ella: restaura la cartera Monero desde su semilla en una máquina desechable, confirma que el saldo reaparece, y solo entonces confíes el flujo a los ingresos. Las declaraciones de custodia son baratas de hacer y caras de descubrir falsas — un simulacro de restauración de diez minutos por cartera convierte cada declaración de custodia de la pila en un hecho verificado con fecha adjunta.

El error: lanzar la versión con plugins el día del lanzamiento porque la demostración funcionó. Las actualizaciones de los plugins siguen el calendario de la comunidad y no el tuyo, y una regresión del checkout devora pedidos que nadie reportará. Pilota en staging con montos reales, fija versiones, lee el changelog como un operador — la diversidad de pagos se estrena por etapas, nunca de un interruptazo, y el flujo de respaldo debe seguir funcionando mientras el recién llegado se gana su puesto.

El despliegue de BTCPay, en el orden en que hay que ejecutarlo

Empieza por la identidad y el DNS: elige el hostname, apunta su registro A a la máquina y deja que el TLS se automatice contra él — antes de la primera instalación, nunca después. Luego toma la ruta soportada: clona el repositorio btcpayserver-docker, ajusta el entorno incluyendo BTCPAY_HOST y el objetivo de poda, y ejecuta btcpay-setup.sh, que ensambla y arranca la pila entera de un solo movimiento.

Mientras corre la primera descarga — horas en NVMe local, podada — verifica las aperturas: 80 y 443 respondiendo, 8333 aceptando peers, nada más expuesto según ss -tlnp. El nodo inspecciona cada bloque por sí mismo, que es el punto entero; la sincronización es la única espera larga del proyecto, y todo lo que sigue es rápido en comparación. La espera sigue a la clase de almacenamiento y no al tamaño del plan: un objetivo de poda fijado en la instalación mantiene pequeño el volumen de datos, mientras que un arranque sin podar en un volumen pequeño se llena a mitad de sync y obliga a repetir la descarga entera.

Demuestra el checkout con facturas reales pequeñas antes de cualquier anuncio: primero on-chain, luego Lightning cuando los puertos y los canales estén listos — exportando channel.backup fuera de la máquina antes de financiar el primer canal. Prueba cualquier plugin de Monero en staging con montos reales y versiones fijadas, y mantén el flujo on-chain operativo como respaldo permanente mientras todo lo demás madura a su alrededor.

Cablea la fontanería operativa pronto, cuando las apuestas son de juguete: un webhook hacia tu sistema de pedidos, una comprobación diaria de saldo, alertas de disco y memoria, y un ensayo completo de copia de seguridad y restauración. Las integraciones construidas durante la semana tranquila se comportan durante la semana ruidosa; las integraciones prometidas para más tarde tienen el hábito documentado de convertirse en la caída. Ejecuta el simulacro de restauración una vez contra una copia que no importe, para que el procedimiento sea una cantidad conocida antes de que la primera campaña de verdad lo necesite con urgencia.

Cierra el círculo de la custodia: semillas y copias de las carteras guardadas donde la máquina nunca ha estado y restauradas una vez a propósito, docker stats vigilado durante la sincronización inicial y la primera campaña, y el calendario mensual de parches según la lista base de endurecimiento. Desde ahí, el nodo ronronea — validando cada bloque, emitiendo cada factura, sin doblegarse ante ninguna API ajena a la cadena.