Autoaloja BTCPay Server en un VPS

El discurso suele ser “sin comisiones”, que es la parte menos interesante del asunto. Cambian cuatro cosas, y solo una de ellas tiene que ver con el dinero:

• Nadie retiene tus fondos en tránsito. Un procesador alojado recibe el pago del cliente en su propia wallet y te lo abona después. Ese hueco es donde ocurren las retenciones, las revisiones y los bloqueos. BTCPay nunca recibe nada: el cliente paga a una dirección derivada de tu clave, y las monedas son tuyas desde la primera confirmación.
• Nadie te pregunta quién eres. Darse de alta en un procesador es un proceso de identidad con un banco al final. Instalar software no lo es. Esa es toda la diferencia, y es la razón por la que la respuesta a “cómo cobro en cripto sin KYC” siempre es “ejecuta tú mismo el procesador”.
• El coste deja de escalar contigo. Un porcentaje se cobra para siempre y crece con el éxito. Un VPS y un dominio cuestan lo mismo en un buen mes que en uno malo.
• Heredas el trabajo operativo. Disponibilidad, actualizaciones, copias de seguridad, y ser la persona a la que le llega el mensaje cuando un cliente dice que su factura nunca se liquidó. Este es el precio real, y se paga en atención, no en moneda.

Lo que no obtienes es lo único que los procesadores hacen genuinamente bien: convertir monedas en dinero de cuenta bancaria en tu nombre. BTCPay retiene lo que le pagaron, en la moneda en que le pagaron. La conversión, la facturación en moneda fiat, las exportaciones contables que un fisco reconoce — todo eso son problemas aparte, y la mayoría de las formas de resolverlos reintroducen exactamente la contraparte identificada que acabas de eliminar. Decide qué mitad de ese trato querías en realidad antes de construir nada.

El nombre confunde de forma útil. “BTCPay Server” no es un solo programa; el despliegue estándar es una pequeña flota de contenedores que arrancan juntos, y saber cuál es cuál marca la diferencia entre dimensionar esto correctamente y adivinarlo:

• Bitcoin Core. Un nodo completo de verdad, que valida desde el génesis. Este es el componente que te cuesta disco, casi todo el primer día, y casi toda la memoria. Todo lo demás es comparativamente gratis.
• NBXplorer. El indexador entre Core y BTCPay. Le das claves públicas extendidas; él vigila las direcciones derivadas y avisa a BTCPay cuando llega dinero. También es la pieza a la que le importa el podado, por razones a las que vuelve la sección de fallos.
• BTCPay Server en sí. La aplicación: tiendas, facturas, la página de pago, el punto de venta, los webhooks, la Greenfield API. Modesta en comparación — unos pocos cientos de megabytes de memoria.
• PostgreSQL. Facturas, tiendas, configuración, usuarios, claves de API. Pequeña, y lo único para lo que sirven de verdad tus copias de seguridad.
• nginx con certificados automáticos. Un proxy inverso más un compañero que emite y renueva un certificado para tu nombre de host. Por eso los puertos 80 y 443 tienen que ser realmente alcanzables desde internet.
• Opcionalmente, un nodo Lightning (Core Lightning o LND) y un daemon de Monero con un wallet RPC al lado — cada uno con su propia cadena y su propio apetito de disco.

Así que la pregunta del dimensionamiento nunca es “qué tan grande tiene que ser BTCPay”. Es “cuánta cadena estoy guardando, y cuántas cadenas”. Responde eso y el plan se elige solo.

El proyecto documenta 2 GB de RAM con swap como mínimo y 4 GB como recomendación, y la diferencia entre esos dos números es la diferencia entre una instalación que técnicamente termina y una a la que estás dispuesto a mandarle clientes. Un runtime de aplicación, PostgreSQL y un bitcoind sincronizándose compartiendo 2 GB terminan — despacio, con el archivo de swap haciendo un trabajo que no debería tener que hacer.

El disco depende de cuánto podas, y el despliegue expone eso como un fragmento que le pasas al instalador. La familia va, más o menos, de opt-save-storage con unos 100 GB de archivos de bloques, -s con unos 50 GB, -xs con unos 25 GB y -xxs con unos 5 GB. Esta última es una trampa para cualquier cosa que deba sobrevivir: guarda tan poco historial que el mantenimiento normal empieza a fallar. Para una tienda, -s o -xs es la banda sensata.

Cifras concretas de la tabla, porque “depende” no es una respuesta:

• Solo Bitcoin, podado, una tienda — Scout, 2 vCPU / 4 GB / 70 GB NVMe, $9.00/mo. El suelo honesto, y la respuesta correcta para la mayoría de los lectores.
• Bitcoin y Lightning — Runner, 3 vCPU / 6 GB / 100 GB, $14.00/mo. Un daemon Lightning pesa poco en disco e insiste en seguir conectado; el margen es para el nodo que tiene debajo.
• Bitcoin, Lightning y Monero — Alpha, 6 vCPU / 12 GB / 200 GB, $28.00/mo. Una cadena de Monero podada ronda los 85 GB ella sola, así que dos cadenas y dos indexadores es donde 8 GB se queda corto. Hunter (4 vCPU / 8 GB / 140 GB, $19.00/mo) encaja solo si Bitcoin se mantiene podado a fondo y sigue así.
• Un nodo sin podar detrás de la tienda — un proyecto distinto con una factura distinta. La guía del nodo completo tiene esas cifras, y empiezan en Fenrir.

La CPU importa exactamente una vez. La verificación de firmas durante la descarga inicial de bloques se paraleliza, así que de dos a cuatro vCPU convierten la primera sincronización de días en aproximadamente un día, y luego la CPU vuelve a quedarse inactiva. El ancho de banda es un coste único de toda la cadena, por un puerto de 1 Gbps con tráfico ilimitado y sin factura por exceso al final del mes. La latencia es irrelevante para un procesador de pagos, así que elige la ubicación por la jurisdicción y no por los milisegundos — Ámsterdam, París, Bucarest y Sofía están todas al precio base.

Una lista corta, y uno de los puntos no es técnico.

• Un dominio, con un registro A que ya apunte al servidor. El certificado se emite por HTTP contra ese nombre de host, así que el DNS tiene que resolver antes de que se ejecute el instalador, no durante. Un subdominio como pay.example.com es la forma habitual.
• Los puertos 80 y 443 abiertos al mundo. El puerto 80 no es opcional aunque después no sirva nada útil en él; el desafío del certificado lo necesita.
• Debian 13 de la biblioteca de plantillas, en una máquina a la que ya se le haya hecho la pasada de diez minutos de endurecimiento. Hazlo primero — es mucho más difícil hacerlo con educación una vez que la pila ya está en marcha.
• Una wallet que ya controles, y su clave pública extendida. Sparrow, Electrum o una hardware wallet. Tenla a mano antes de instalar, para no caer nunca en la tentación de dejar que el servidor te genere una.
• Una dirección de correo electrónico para la autoridad certificadora. Recibe avisos de caducidad y nada más.
• Una decisión sobre el podado, tomada ahora. Cambiar de opinión más adelante significa resincronizar la cadena desde cero, y ese es un día que no vas a disfrutar pasar dos veces.

Casi todo desenlace malo con un procesador autoalojado se remonta a una sola decisión tomada pronto y a la ligera: dejar que el servidor tenga en su poder algo que pueda gastar. Merece la pena ser explícito sobre los tres casos, porque son genuinamente distintos.

• Bitcoin on-chain: de solo lectura, siempre. BTCPay tiene una clave pública extendida y nada más. Si la máquina se ve comprometida, el atacante averigua qué te pagaron y puede cambiar hacia dónde apuntan las facturas futuras — un ataque real, y la razón para revisar la wallet de tu tienda después de cualquier incidente — pero no puede tocar una moneda ya recibida.
• Lightning: caliente por definición. Los canales se financian con monedas que el servidor puede gastar, porque eso es lo que es un canal. Esta es la excepción deliberada, y la sección de arriba la dimensiona.
• Monero: de solo vista, estructuralmente. La clave privada de vista revela cada pago entrante y no autoriza ninguno de ellos. No hay equivalente en el lado de Bitcoin.

La única función que rompe este modelo a propósito es Payjoin. Deja que tu servidor aporte un input a la transacción del cliente, lo cual degrada de forma significativa la heurística de entrada común en la que se apoya el análisis de cadena, y es una ganancia real de privacidad para ambas partes — pero quien recibe tiene que poder firmar, así que necesita una wallet caliente dentro de BTCPay. Eso es una contrapartida real y no una función gratuita. Actívala sabiendo lo que haces, y fondéala igual que fondeas la wallet de Lightning: con una cantidad, no con todo.

Y si dejas que el asistente de configuración genere la wallet de la tienda porque era el camino más rápido: apunta la semilla que te mostró, verifícala en una wallet offline, y luego planea la migración a una configuración de solo lectura. Una semilla que ha estado alguna vez en un servidor expuesto a internet es una semilla con una cuenta atrás en marcha.

Ordena el estado según lo que costaría recrearlo, porque las respuestas son muy distintas:

• La cadena. No es un problema de copias de seguridad. Es información pública y resincroniza, despacio y gratis. Nunca la respaldes.
• La base de datos. Facturas, tiendas, configuración, usuarios, claves de API. Esta es la copia de seguridad de verdad, es pequeña, y perderla te cuesta el registro contable de cada venta — no el dinero, pero sí el papeleo.
• Tu wallet on-chain. Ya está a salvo, porque la clave nunca estuvo aquí. Ese es el premio por el paso cinco.
• El estado de los canales de Lightning. El que muerde. Una copia de seguridad estática del canal te permite recuperar los fondos de tus canales después de una pérdida total forzando su cierre; no restaura los canales, y no vale nada si está desactualizada. Cambia cada vez que un canal se abre o se cierra, así que pertenece a una copia automática fuera de sitio, no a una carpeta que recuerdas cada trimestre.
• La cartera de Monero de solo vista. Reconstruible a partir de la dirección y la clave de vista que sigues guardando offline. Respalda esas dos cosas y trata los archivos de la cartera como una caché.

El despliegue trae herramientas que hacen esto correctamente:

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

Esa pausa es la clave — una copia en caliente de una base de datos en marcha puede restaurar en algo interesante. Cifra todo lo que salga de la máquina, y recuerda que la instantánea semanal incluida en todos los planes es una comodidad y no una copia de seguridad: una instantánea vive junto a lo que protege.

En el orden aproximado de cuántas veces le arruinan una noche a alguien:

• El certificado nunca se emite. Nueve de cada diez veces el registro A se creó después de que se ejecutara el instalador, o el puerto 80 está filtrado. Arregla el DNS, confirma que el nombre resuelve desde algún sitio que no sea tu propio portátil, y luego vuelve a ejecutar el script de configuración. Reintentarlo a ciegas contra la autoridad certificadora te gana un límite de frecuencia y una semana de espera, así que cambia algo entre un intento y otro.
• Una clave extendida importada con historial no muestra saldo. Esta es la trampa del podado. El indexador encuentra pagos nuevos vigilando los bloques nuevos, pero reconstruir el pasado de una wallet ya existente significa leer bloques que un nodo podado ya ha borrado. Usa una cuenta nueva para la tienda y el problema no existe; si tienes que importar historial, necesitas un nodo sin podar y un rescan.
• “El cliente pagó y la factura sigue abierta.” Normalmente es un pago corto por la comisión de la wallet que envía, una factura que caducó mientras el pago estaba sin confirmar, o una política de confirmaciones más estricta de lo que recuerdas haber elegido. Las tres cosas son ajustes, y las tres son la razón por la que pruebas primero con tu propio dinero.
• El nodo se queda atrás en silencio. Un bitcoind estancado sigue repartiendo direcciones y se pierde pagos sin quejarse. Compara tu altura de bloque contra cualquier fuente pública con un temporizador y avisa ante la diferencia; esto no es algo que debas aprender de un cliente.
• Una actualización en el momento equivocado. btcpay-update.sh se porta bien, pero reinicia todo. Ejecútalo deliberadamente, nunca en automático, y nunca durante una venta.
• La dirección se gana una reputación. Una página de pago en una IPv4 en lista negra es una página de pago que algunas redes corporativas y filtros de correo rechazan en silencio. Todos los planes de aquí incluyen una dirección dedicada sin historial, y vale la pena comprobarla antes de imprimir el dominio en nada.

El software elimina a una contraparte. No elimina el resto de la superficie, y ser honesto sobre eso es más útil que otra lista de funciones.

El dominio es el punto débil. Está registrado en algún sitio, resuelve públicamente, y es lo primero que mira cualquiera. Un procesador autoalojado en un nombre de host registrado a tu propio nombre en un registrador de tu propio país ha sacado el dinero de las manos de un tercero y ha dejado la identidad exactamente donde estaba. Si eso te importa por lo que vendes, el registrador merece al menos tanta reflexión como el proveedor de hosting.

La jurisdicción es una variable real. Dónde está la máquina decide qué orden judicial la alcanza y cuánto proceso se interpone en el camino. Eso es fricción y distancia, no inmunidad — algo que la entrada de hosting offshore explica largo y tendido, y vale la pena leerla antes de elegir una bandera en vez de una red.

La cuenta es el último eslabón. Alquilar el servidor con una dirección de correo electrónico y pagar en Monero significa que ningún extracto de tarjeta vincula la página de pago con un banco — algo extraño de pasar por alto al construir un sistema cuyo único sentido es no necesitar uno. Todos los planes de aquí son no-KYC por defecto, y cada ubicación incluye una IPv4 limpia y dedicada con DNS inverso personalizado.

Y el límite se declara en vez de darse a entender. Nodos, procesadores y tiendas son infraestructura ordinaria y bienvenida aquí; la política de uso aceptable es corta, pública, y tiene un suelo debajo. Si tú necesitas una licencia para cobrar pagos es una pregunta sobre qué vendes y dónde estás, no sobre el software — y es una pregunta para alguien cualificado, no para una guía de hosting.