BTCPay Server autoalojado en un VPS: acepta Bitcoin y Lightning sin procesador

Qué es realmente BTCPay Server, y qué sustituye

BTCPay Server no es una cartera ni una empresa de pagos. Es la capa de software que se sitúa entre tu sitio web y tu propio nodo de Bitcoin, y hace el trabajo aburrido y necesario que normalmente hace un procesador por ti: genera una dirección nueva o una factura Lightning por cada pedido, cotiza un importe en moneda fiat a un tipo de cambio que bloquea durante toda la vida de la factura, vigila la cadena a la espera del pago, decide cuándo el pago cuenta como liquidado, y avisa a tu tienda. El dinero nunca pasa por la cuenta de nadie de camino hacia ti, porque no hay ninguna cuenta — las direcciones pertenecen a una cartera que tú controlas, y el software solo las está observando.

Esa única diferencia arquitectónica es todo el motivo para usarlo. Un procesador alojado es una empresa con un departamento de cumplimiento normativo, un banco, y un documento de términos de servicio que se reserva el derecho de retener tu liquidación mientras te revisa. Te va a pedir documentos de identidad, porque mueve dinero en tu nombre y su propio regulador le exige saber de quién es el dinero que mueve. Autoalojar elimina al intermediario en lugar de negociar con él: no hay proceso de alta, no hay revisión mensual de volumen, no hay calendario de liquidación, y no hay nada que un tercero pueda congelar, porque en ningún momento un tercero retiene los fondos.

Lo que obtienes a cambio del trabajo es un proceso de pago genuinamente completo. Facturas con caducidad y un tipo de cambio bloqueado. On-chain y Lightning en la misma factura, de modo que a un cliente que paga dos dólares no se le pide pagar una comisión de red de tres dólares. Una página de punto de venta, un botón de donación, una página de financiación colectiva, un botón de pago que puedes pegar en cualquier HTML. Plugins para las plataformas de tienda habituales, y una API REST completa si tu tienda es algo que has programado tú mismo. Reembolsos, pull payments, pagos salientes. Payjoin, si te importa romper la heurística de propiedad común de entradas en el lado receptor.

Vale la pena ser preciso sobre lo que no está incluido, porque la mayor parte de la decepción con los pagos autoalojados viene de esperar un producto donde lo que hay es un protocolo. Nadie convierte tu Bitcoin a euros y lo transfiere a un banco; si necesitas eso, sigues necesitando un exchange, y el exchange te seguirá preguntando quién eres. Nadie asume los contracargos, aunque tampoco hay ninguno que asumir. Nadie responde al teléfono a las dos de la madrugada cuando el nodo deja de seguir la cadena — eso ahora es trabajo tuyo, y es la parte de esta guía que la gente se salta.

La máquina: lo que de verdad necesita, y dónde se acaba el plan barato

La aplicación es pequeña. El stack que hay debajo no lo es. Un despliegue por defecto ejecuta Bitcoin Core, un indexador de direcciones llamado NBXplorer, una base de datos PostgreSQL, la aplicación web de BTCPay, un proxy inverso que gestiona los certificados, y — si lo activas — un nodo Lightning, cada uno en su propio contenedor. La aplicación web sería feliz en una raspberry pi. Bitcoin Core no.

La memoria es lo primero que la gente compra de menos. Dos gigabytes técnicamente arrancarán el stack y pasarán la sincronización inicial haciendo swap, lo cual en un NVMe compartido es una buena forma de convertir un día en tres. Cuatro gigabytes es un mínimo razonable solo para on-chain. Ocho es el mínimo realista en cuanto Lightning entra en escena, porque ahora estás ejecutando un segundo demonio que mantiene su propia base de datos y su propia vista del grafo, y porque bitcoind rinde muchísimo mejor durante la descarga inicial cuando puedes darle un dbcache grande en lugar del valor conservador por defecto. Las notas sobre reducción de memoria de Bitcoin Core son la referencia sobre qué parámetros intercambian RAM por tiempo.

El disco es lo segundo, y es lo que decide tu plan. La cadena sin podar supera los setecientos gigabytes y añade unos sesenta más al año, así que un nodo archivo ya no cabe en ningún nivel de VPS que vendemos y pertenece a una máquina dedicada, donde un par en espejo todavía te deja un terabyte libre. La poda cambia eso por completo — el nodo mantiene una ventana móvil de bloques recientes y descarta el resto, y para un endpoint de pagos eso no es ninguna concesión, porque un comerciante nunca necesita servirle bloques históricos a nadie. Añade la base de datos del indexador, PostgreSQL, las imágenes y volúmenes de Docker, el propio almacén del nodo Lightning, y los logs, y un despliegue podado cabe cómodamente en una máquina de la clase de los cien gigabytes con margen para crecer.

La CPU importa sobre todo durante una semana de tu vida. La validación de firmas durante la descarga inicial de bloques es lo más pesado que este servidor va a hacer jamás; después, verificar un bloque cada diez minutos y responder a un puñado de solicitudes de factura está cerca de estar inactivo. Compra núcleos para la sincronización, no para el régimen estable — o compra el plan más pequeño y acepta que la sincronización tarda más, lo cual es una compensación perfectamente razonable si no tienes prisa.

La poda ahorra disco, no tiempo — y la sincronización es el cuello de botella

El malentendido más común, con diferencia, sobre llevar un nodo es que la poda lo hace rápido. No es así. Un nodo podado descarga todos los bloques desde el bloque génesis en adelante y valida todas y cada una de las firmas de todos ellos, exactamente igual que un nodo archivo; la única diferencia es que, una vez que un bloque se valida y ya no hace falta, se borra en lugar de conservarse. Ahorras disco. No ahorras nada de ancho de banda ni nada de tiempo. Quien espere que un nodo podado esté listo en una hora se va a pasar esa hora convencido de que algo está roto.

Cuánto tarda de verdad depende casi por completo de cuánta caché le diste y de la velocidad del disco. En NVMe con varios gigabytes de dbcache y cuatro núcleos sin compartir, un día es una expectativa razonable. En un plan pequeño con la caché por defecto y un vecino ocupado, dos o tres días es lo normal, y el proceso se pasa la mayor parte de ese tiempo escribiendo el conjunto UTXO en disco una y otra vez porque no puede mantenerlo en memoria. Este es el único momento en el que un plan temporalmente más grande vale dinero de verdad: sube de tamaño para la sincronización, baja de nuevo después. La facturación mensual sin contrato es precisamente lo que hace barata esa maniobra.

Después, una vez sincronizada la cadena, hay una segunda espera con la que casi nadie cuenta. Cuando conectas una cartera que ya tiene historial — una clave pública extendida de una cartera hardware que llevas usando un año — el indexador tiene que escanear la cadena en busca de direcciones derivadas de ella. En un nodo podado, ese escaneo está limitado por lo que todavía queda en disco, por lo que el orden de la instalación importa: apunta la cartera al nodo antes de que se descarten los bloques antiguos si necesitas que aparezcan las transacciones históricas, o acepta que la tienda empiece desde hoy y trátalo como el comienzo limpio que normalmente es.

La regla práctica de planificación es que la máquina tiene que estar en servicio y sincronizando bastante antes de que la tienda la necesite. Aprovisiónala, arranca la descarga, y dedica el día de por medio a las partes que no dependen de la cadena: DNS, certificados, el plugin de la tienda, la cartera, la rutina de copias de seguridad. Si dejas el nodo para el final, vas a descubrir que te has comprometido a una fecha de lanzamiento que depende de un proceso que nadie puede acelerar.

Las claves: la decisión de arquitectura que tomas una sola vez

La pregunta que determina lo malo que puede llegar a ser tu peor día es simple: ¿puede el servidor gastar el dinero? Para los pagos on-chain, la respuesta debería ser no, y BTCPay está diseñado para dejarte decir que no. Importas una clave pública extendida — un xpub, o sus equivalentes modernos — derivada de una cartera hardware o un firmante sin conexión. El servidor deriva de esa clave una dirección de recepción nueva por cada factura, vigila la cadena por si llegan pagos a esas direcciones, y los reporta. No puede construir un gasto válido, porque nunca ha visto una clave privada. Un compromiso total de la máquina te cuesta entonces la máquina y los datos de pedidos de tus clientes, lo cual es malo, pero no te cuesta la recaudación.

La alternativa — dejar que BTCPay genere y mantenga una cartera caliente por comodidad — está disponible, en ocasiones es la decisión correcta para volúmenes muy pequeños, y debería ser una decisión deliberada y no algo que pasó porque era el botón por defecto. Si la tomas, trata el saldo de ese servidor como tratarías el efectivo en la caja de una tienda: retíralo según un calendario, conserva solo lo que necesita el comercio de un día, y entiende que la semilla existe en un disco dentro de un centro de datos.

Lightning es la excepción que no se puede evitar. Un nodo Lightning tiene que firmar transacciones en tiempo real para actualizar el estado del canal, así que sus claves son necesariamente calientes, y no existe ningún modo de solo lectura que aun así te deje recibir. Eso no es un defecto de BTCPay; es lo que exige el protocolo. La respuesta correcta es dimensionar el saldo de Lightning para la tarea — suficiente capacidad entrante para recibir un día o una semana de pedidos, no tu tesorería — y mover los cobros acumulados a almacenamiento en frío con regularidad, la misma disciplina que cualquier tienda aplica a su caja.

Hay una cosa más que pertenece a esta decisión, porque es la parte que la gente deja para después del incidente: anota dónde está la semilla, en una forma que tu sucesor pueda usar, y guárdala en un sitio que no sea el servidor ni el mismo edificio que el servidor. El cifrado de disco completo en el VPS protege el disco en reposo frente a una copia fuera de línea; no hace nada por una máquina en marcha, y desde luego no ayuda nada si la única copia de tu semilla estaba en ella.

Lightning es un problema de liquidez disfrazado de software

Instalar un nodo Lightning es fácil. Recibir en él tu primer pago no lo es, y el motivo pilla a casi todo el mundo. Un canal Lightning es un saldo de dos lados: cuando abres un canal y lo financias, toda la capacidad está de tu lado, lo cual significa que puedes pagar a otras personas y nadie puede pagarte a ti. Recibir requiere capacidad entrante — fondos situados al otro lado de un canal, listos para moverse hacia ti. Un nodo recién instalado con tres canales salientes bien financiados todavía puede no aceptar ni un solo satoshi de un cliente, y el proceso de pago simplemente no va a ofrecer Lightning como opción.

Hay tres formas honestas de arreglar eso. Puedes comprar capacidad entrante a un proveedor de liquidez, que es lo más rápido y cuesta una comisión proporcional al importe y a la duración. Puedes hacer un submarine swap — pagar por Lightning y recibir on-chain, lo cual desplaza tu propio saldo al otro lado de tus canales y convierte capacidad saliente en entrante al coste de la comisión del swap. O puedes pedirle a un peer bien conectado que abra un canal hacia ti, lo cual es gratis si tienes la relación y lento si no la tienes. Elijas lo que elijas, presupuéstalo antes del lanzamiento, y dimensiónalo según el flujo de pedidos que esperas en lugar de escoger un número redondo.

Los canales también necesitan un mantenimiento que on-chain no exige. La capacidad entrante se consume a medida que los clientes te pagan: cada pago recibido mueve saldo de su lado del canal al tuyo, así que una tienda que solo recibe va a ir agotando poco a poco su capacidad de recibir y va a necesitar reequilibrar o hacer un swap de salida. Los canales se cierran, a veces unilateralmente cuando un peer desaparece, y un cierre forzado deja tus fondos detrás de un bloqueo temporal durante un tiempo y cuesta una comisión on-chain. Los nodos necesitan estar en línea para aceptar pagos y para vigilar a contrapartes que hagan trampa. Nada de esto es difícil, pero todo es continuo, y es la razón por la que muchas tiendas usan Lightning para pedidos pequeños y liquidan discretamente on-chain todo lo que supera un umbral.

La recompensa por la molestia es real. Las comisiones on-chain son indiferentes al tamaño del pago, lo cual hace que un pedido de cinco dólares sea económicamente absurdo cuando el mempool está saturado y perfectamente razonable cuando no lo está — y tú no controlas cuál de las dos cosas toca el día de tu lanzamiento. Los pagos Lightning se liquidan en menos de un segundo por una fracción de centavo, sin importar la congestión, y para cualquier cosa con el precio de un café, una descarga, una recarga de API o una suscripción mensual, es la diferencia entre un proceso de pago que funciona y uno que pierde la venta en silencio.

La copia de seguridad que te arruina: nunca reviertas un nodo Lightning a un estado anterior

Esta sección es el motivo para leer la guía incluso si ya sabes todo lo demás que contiene. Restaurar un nodo Lightning a partir de una copia antigua de sus datos no es un acto neutro, y en las circunstancias equivocadas te destruye los saldos de los canales. El instinto normal de administración de sistemas — haz una instantánea, restaura la instantánea cuando algo se rompa — es precisamente el instinto que provoca la pérdida.

El mecanismo es la penalización por trampa del protocolo. Cada actualización de canal sustituye a la anterior, y cada lado le entrega al otro los medios para castigarlo si alguna vez publica un estado ya sustituido. Eso es lo que hace seguro un canal entre dos partes sin necesidad de árbitro. También significa que un nodo restaurado a partir de la copia de ayer cree de verdad que un estado antiguo es el actual, y si actúa según esa creencia — cerrando de forma forzada, o simplemente porque se le pide que lo haga — la contraparte tiene derecho a quedarse con todo el saldo del canal, y su software lo va a hacer automáticamente. Tú no pretendías hacer trampa. El protocolo no puede distinguirlo, y no está diseñado para hacerlo.

Así que la regla es absoluta y merece la pena escribirla en la pared: nunca restaures un nodo Lightning a un estado anterior. Ni desde una instantánea del sistema de archivos, ni desde un volcado de base de datos, ni desde una copia del directorio de datos que hiciste la semana pasada, ni desde las instantáneas por horas que vienen con el servidor. Las instantáneas son excelentes para el resto de la máquina y peligrosas exactamente para este directorio, y el peligro es silencioso — el nodo va a arrancar, va a parecer sano, y te va a costar dinero más adelante.

Lo que conservas en su lugar es una copia de seguridad estática del canal: un archivo pequeño, actualizado cada vez que un canal se abre o se cierra, que contiene justo la información suficiente para pedirle a cada contraparte que cierre de forma cooperativa y te devuelva los fondos. LND lo llama channel.backup y documenta su funcionamiento en su guía de recuperación; Core Lightning ofrece un equivalente junto con un plugin que mantiene una copia replicada de forma continua de la base de datos. Restaurar uno de estos archivos no reanuda tus canales — los cierra todos de forma forzada y recupera el saldo, que es el único resultado correcto y seguro después de una pérdida total. Guárdala fuera de la máquina, mantenla al día, y entiende que es una póliza de seguro, no un botón de reanudar.

Para todo lo demás, haz copias de seguridad de forma normal y generosa. El despliegue de BTCPay incluye su propio script de copia de seguridad que detiene el stack, vuelca la base de datos y la configuración de forma consistente, y lo vuelve a arrancar; ejecútalo según un calendario y copia el resultado a otro sitio, idealmente un segundo servidor en una jurisdicción distinta. La base de datos contiene tus facturas, tiendas, usuarios, claves de API y ajustes — no tu dinero, pero sí todo tu historial, que es lo que de verdad vas a echar de menos.

Dónde está el servidor es parte del stack de pagos

Es fácil pensar en el hosting como un commodity que hay debajo de la parte interesante. Para un endpoint de pagos no lo es, porque el proceso de pago es el único componente cuya disponibilidad equivale directamente a ingresos, y porque un servidor es un objeto físico en una jurisdicción legal con un proveedor al que se puede contactar por él. Cuando tu infraestructura de pagos es un procesador alojado, la postura de cumplimiento de ese proveedor es tu postura de cumplimiento. Cuando te autoalojas, la postura de tu proveedor de hosting pasa a ocupar ese papel — y si te autoalojaste específicamente para escapar de la discreción de una empresa de pagos, sería descuidado entregar esa misma discreción a la empresa que lleva la máquina.

Hay tres propiedades sobre las que merece la pena ser deliberado. La primera es qué identidad guarda el proveedor de hosting: una cuenta abierta con una dirección de correo y pagada en criptomoneda no tiene nada que entregar y nada que congelar, que es el mismo razonamiento que te llevó a autoalojarte en primer lugar. El alojamiento sin KYC explica lo que eso significa y lo que no significa en la práctica, incluyendo su incómodo corolario — un proveedor que nunca supo quién eras no puede devolverte la cuenta si pierdes el acceso a ella.

La segunda es la jurisdicción. Un endpoint de pago que atiende a clientes en muchos países reside exactamente en uno, y la ley de ese uno determina quién puede obligar al proveedor, sobre qué base, y con qué rapidez. Nuestras cuatro regiones — Islandia, los Países Bajos, Rumanía y Suiza — difieren de forma significativa en ese aspecto y en la latencia hacia distintas bases de clientes, y elegir una jurisdicción analiza esas contrapartidas como es debido. También hay un ángulo operativo más mundano: coloca el nodo cerca de tus clientes si la latencia del proceso de pago importa, y cerca del resto de tu infraestructura si no importa.

La tercera es el propio pago del hosting, que es el cabo suelto que más gente deja sin atar. Llevar un proceso de pago anónimo y sin custodia en un servidor facturado a una tarjeta de crédito a tu propio nombre crea exactamente el vínculo que construiste el resto del stack para evitar. Pagar la máquina en Monero o Bitcoin lo cierra — el mismo razonamiento, aplicado una capa más abajo. También significa que la factura de la infraestructura no puede verse interrumpida por el propio modelo de riesgo del emisor de una tarjeta, que es un modo de fallo que de verdad ha dejado tiendas fuera de servicio.

Por último, los aburridos requisitos de fiabilidad son más estrictos aquí que para un blog. Un nodo Lightning que está fuera de línea no puede recibir, no puede vigilar a una contraparte tramposa, y puede sufrir un cierre forzado por parte de peers que no pueden alcanzarlo. Un nodo Bitcoin que se queda atrás de la cadena les muestra a los clientes facturas que no puede liquidar. El ancho de banda sin medición importa más de lo que parece, porque un nodo que participa de verdad en la red le sirve bloques a sus peers, y un plan con medición te va a presentar una factura que no tiene nada que ver con el tráfico de tu tienda.

El orden de instalación que evita una segunda sincronización

El despliegue que usa todo el mundo es la distribución Docker oficial: un repositorio que clonas en un servidor nuevo, un conjunto de variables de entorno que describen lo que quieres, y un script de instalación que genera un archivo compose y levanta todo el stack. Es genuinamente llave en mano, y el motivo por el que las instalaciones salen mal casi nunca es el script — es hacer las cosas en un orden que te obliga a repetir el paso caro.

Empieza con una máquina limpia y el registro DNS. El instalador solicita un certificado para el nombre de host que le des, y esa solicitud sale hacia una autoridad de certificación que va a conectar de vuelta a tu dirección por el puerto 80. Si el registro todavía no resuelve, o los puertos están cerrados, el stack arranca sin TLS y te toca averiguar cuál de las tres cosas falló. Crea el registro A, confirma que responde desde algún sitio que no sea tu propio portátil, abre el 80 y el 443, y solo entonces ejecuta el instalador.

Decide los fragmentos antes de la primera ejecución, no después. El entorno le dice al generador qué cadenas habilitar, qué implementación de Lightning usar, si podar y con qué agresividad, si exponer un servicio onion junto al host de clearnet, y qué proxy inverso configurar. Varios de esos son baratos de cambiar más tarde; los que tocan el nodo — habilitar una cadena, activar o desactivar la poda, cambiar de implementación de Lightning — implican volver a descargar o volver a indexar algo, y volver a descargar algo es lo que cuesta un día. Lee la lista de fragmentos una vez, elige con criterio, y luego ejecútala.

Mientras la cadena descarga, haz el resto. Crea tu tienda y configura su moneda, la caducidad de sus facturas y cuántas confirmaciones quieres antes de que una factura cuente como liquidada — una decisión que merece la pena tomar a propósito, porque aceptar con cero confirmaciones es rápido y de vez en cuando erróneo, y seis confirmaciones es seguro y tarda una hora. Importa la cartera de solo lectura. Instala el plugin de la tienda y apúntalo al servidor con una clave de API con permisos limitados en lugar de con la cuenta de administrador. Configura la fuente de tipo de cambio. Envíate a ti mismo una factura de prueba por un importe insignificante y págala, on-chain y por Lightning, desde una cartera que no esté en la misma máquina — el número de despliegues que nunca se han probado ni una sola vez con dinero real es más alto de lo que a cualquiera le gustaría.

Después, anota el procedimiento de actualización, porque existe y es un solo comando. La distribución incluye su propio actualizador, que descarga las imágenes nuevas y reinicia el stack en el orden correcto, y un endpoint de pagos que ejecuta una versión de hace un año está cargando con todos los errores corregidos desde entonces. Ponlo en un calendario, lee las notas de la versión antes de ejecutarlo, y haz la copia de seguridad primero.

Bastionar una máquina que guarda dinero

El consejo genérico se aplica por completo y está desarrollado en la checklist de bastionado: claves en lugar de contraseñas, sin inicio de sesión root por SSH, un cortafuegos que deniega por defecto, actualizaciones de seguridad desatendidas, y un log que de verdad lees. Lo que sigue es la parte específica de esta máquina, y el tema de fondo es que la superficie de ataque de un endpoint de pagos no tiene la misma forma que la de un servidor web.

Mantén la interfaz administrativa fuera de internet público si puedes. El panel de BTCPay es el plano de control de tu dinero — puede crear pull payments, cambiar carteras y emitir claves de API — y no necesita ser alcanzable por todo el mundo solo porque las páginas de factura sí lo sean. Colocar la ruta de administración detrás de una VPN o un servicio onion, o detrás de una lista blanca, elimina toda una categoría de riesgo al coste de un paso extra en tu propio flujo de trabajo. Un túnel WireGuard hasta el servidor es la versión menos intrusiva de esto.

Trata las claves de API como la credencial principal y no como una ocurrencia tardía, porque en la práctica son cómo le habla la tienda al proceso de pago, y también cómo lo haría un atacante. Emite una clave por integración, acótala a la tienda y a los permisos que de verdad necesita, guárdala en la configuración secreta de la tienda y no en un repositorio, y rótala cuando alguien se vaya. Una clave sin restricciones en un host web comprometido es funcionalmente lo mismo que entregar el panel.

Vigila los dos estados de fallo que son exclusivos de este stack, porque ninguno de los dos parece una caída. Un nodo que ha dejado de seguir la cadena va a seguir sirviendo el sitio y va a seguir mostrándoles a los clientes facturas que nunca podrán liquidarse. Un nodo Lightning que ha perdido la conectividad con sus peers va a seguir aceptando pedidos on-chain mientras rechaza en silencio todos los pagos por Lightning. Monitoriza la altura de bloque contra una referencia pública, monitoriza el número de canales y el saldo entrante, y activa alertas en ambos — esta es la monitorización que nadie configura hasta la primera vez que le cuesta un día de pedidos.

Mantén la máquina aburrida en cualquier otro sentido. Un endpoint de pagos es un mal sitio para llevar también tu servidor de correo, tu sandbox de desarrollo y un servidor de juego para tus amigos, no porque el software entre en conflicto, sino porque cada servicio adicional es otra vía de entrada y otra cosa cuya actualización puede tirar abajo el proceso de pago. Si quieres el resto, un segundo servidor pequeño cuesta menos que las comisiones de transacción que estás evitando.

Monero y las monedas que BTCPay no habla por sí solo

Bitcoin y Lightning son de primera clase en BTCPay, y un puñado de cadenas cercanas a Bitcoin están soportadas directamente. Todo lo demás llega a través del sistema de plugins introducido con la segunda versión mayor, y vale la pena entender la diferencia de madurez antes de prometer un método de pago en tu página de pago.

Monero es la moneda por la que más pregunta la gente, y sí funciona — a través de un plugin respaldado por tu propio monerod y un demonio RPC de cartera, ejecutándose junto al stack de Bitcoin. El diseño es el mismo que el de Bitcoin en lo que importa: tú llevas el nodo, tú tienes las claves, el software vigila los pagos. Lo que cambia es el coste operativo. Es una segunda cadena de bloques que descargar y mantener sincronizada, es un segundo demonio que monitorizar y actualizar, y el plugin lo mantiene la comunidad y no el equipo principal, lo que significa que su ritmo de versiones es el suyo propio. Si Monero es un extra deseable, sopésalo con honestidad; si la privacidad en el punto de venta es todo el motivo por el que llegaron tus clientes, vale la pena la molestia, y la comparación entre las dos cadenas explica qué oculta realmente cada una.

La regla general para cualquier cadena adicional es preguntarte qué te cuesta cuando se rompe. Cada cadena que habilitas es un nodo que puede quedarse atrás, una cartera que necesita copia de seguridad, una fuente de tipo de cambio que puede quedarse desactualizada, y una conversación de soporte con un cliente cuyo pago se ha quedado atascado. Dos métodos de pago bien llevados superan a seis descuidados, y un proceso de pago que ofrece una moneda cuyo nodo lleva una semana desincronizado es peor que uno que nunca la ofreció.

También hay un término medio legítimo que la gente olvida: no tienes que llevar tú mismo cada cadena para aceptarla. Nada te impide listar una dirección estática para una cadena que liquidas manualmente con poco volumen, o llevar la segunda cadena en una máquina separada para que su perfil de recursos y sus caídas queden aislados del proceso de pago que de verdad importa. Autoalojarse no es un compromiso de todo o nada, y las configuraciones pragmáticas suelen tener una cadena bien hecha y una alternativa manual para el resto.

Lo que cuesta, frente a lo que cobra un procesador

La aritmética es inusualmente fácil de hacer, porque un proceso de pago autoalojado tiene un coste fijo y ningún porcentaje. Un nodo Bitcoin podado con Lightning cabe en un plan de pocas decenas de dólares al mes; una tienda más ajetreada que quiera margen se sitúa uno o dos niveles por encima de eso. Los pagos on-chain cuestan la comisión de red, que paga el cliente, y los pagos Lightning cuestan una comisión de enrutamiento medida en fracciones de centavo. No hay recorte por transacción, no hay mínimo mensual, no hay retraso en la liquidación y no hay nivel por volumen.

Frente a eso, un procesador de cripto alojado normalmente se queda con alrededor del uno por ciento de cada transacción, y un procesador de tarjetas se queda con aproximadamente entre el dos y medio y el tres por ciento más un importe fijo por transacción. Con mil dólares al mes de facturación, el uno por ciento son diez dólares — genuinamente comparable al servidor, y autoalojarse es un empate que quizá hagas por principios más que por economía. Con veinte mil al mes, el procesador se lleva doscientos dólares y el servidor sigue costando los mismos veinte, y la decisión se toma sola. El punto de cruce para la mayoría de las tiendas se sitúa en algún punto de los primeros miles, y todo lo que hay por encima es margen.

El coste que no aparece en la factura es tu atención. Cuenta una tarde para instalar, un día de espera por la cadena, y algo así como una hora al mes después para actualizaciones, copias de seguridad y un vistazo a la monitorización — más una tarde desagradable al año cuando algo se rompe en mal momento. Si tu tarifa por hora hace que eso salga más caro que las comisiones, la respuesta honesta es pagar las comisiones. Nadie debería autoalojar un stack de pagos por una cuestión de ideología mientras su negocio de verdad espera.

Junto a esa tabla hace falta una salvedad, porque omitirla sería deshonesto. La comparación asume que te conformas con quedarte con lo que recibes. Si cada pago tiene que convertirse en moneda fiat en una cuenta bancaria el mismo día, has vuelto a meter un exchange en el flujo, y el exchange tiene sus propias comisiones, sus propios requisitos de identidad y su propia discreción. Autoalojar el proceso de pago elimina al procesador. No elimina al banco, y las tiendas que más partido le sacan a esto son las que conservan al menos parte de su recaudación en la moneda en la que se les pagó.

Cuándo no deberías autoalojar esto

Hay situaciones en las que la respuesta correcta es no hacer nada de esto, y una guía que nunca lo diga está vendiendo algo. Si tu volumen mensual es lo bastante pequeño como para que el porcentaje de un procesador sea menor que el coste del servidor, la aritmética no sale — empieza alojado, y migra cuando los números se crucen. Si nadie en tu equipo se siente cómodo delante de una terminal, no conviertas el proceso de pago en el sitio donde se adquiere esa habilidad; un endpoint de pagos que no puedes depurar es peor que una comisión que te molesta pagar.

Si de verdad necesitas liquidación en fiat el mismo día en una cuenta bancaria, autoalojarte resuelve la mitad equivocada de tu problema. El procesador que estás intentando eliminar es también lo que hace la conversión y la transferencia bancaria, y reemplazarlo significa añadir un exchange que te va a pedir exactamente los documentos de identidad que estabas evitando. Aun así puede valer la pena por las garantías de custodia, pero sé consciente de que el KYC se ha movido, no que ha desaparecido.

Y si tu carga de trabajo es irregular de una forma que hace que el tiempo de inactividad sea catastrófico — un lanzamiento, un drop, una campaña de recaudación con una fecha límite — piénsatelo bien antes de hacer tu primer despliegue autoalojado justo contra esa fecha límite. Ejecútalo en paralelo con otra cosa durante un ciclo, acepta pagos reales a través de él con poco volumen, y deja que se demuestre a sí mismo antes de que cargue con el día que de verdad importa. Moverlo más tarde es un problema resuelto; descubrir sus modos de fallo durante tu hora de más ajetreo no lo es.

Para todos los demás — una tienda con facturación estable, un operador que no tiene problema con una terminal, un negocio que prefiere quedarse con sus propias claves antes que discutir con un departamento de riesgo — esta es una de las pocas piezas de infraestructura autoalojada que se paga sola en efectivo y no solo en principios. El stack es maduro, el despliegue es un script, los modos de fallo son conocidos y están escritos, y el único genuinamente implacable es la regla de reversión de Lightning al principio de esta página. Acierta con esa y el resto es administración de sistemas corriente.

Si quieres empezar, un servidor tarda alrededor de un minuto en aprovisionarse y la cadena va a estar ocupada sincronizando mientras lees el resto de la documentación. Elige un plan con ocho gigabytes de memoria si Lightning entra en tus planes, ponlo en la jurisdicción en la que de verdad querrías tenerlo cuando alguien te haga preguntas incómodas, y págalo con la misma moneda que estás a punto de empezar a aceptar.