Self-hosting n8n en un VPS de 5 dólares: guía para PyMEs

n8n Cloud arranca en 20 dólares por mes para el plan más chico. Zapier, Make y los demás competidores están en rangos similares. Para una PyME con cinco o diez workflows activos, eso ya se hace notar. Lo que mucha gente no sabe es que n8n es open-source con licencia comercial permisiva y se puede correr en un VPS chico por menos de 5 dólares mensuales, con más workflows, más control y tus datos on-prem.

Este post explica cómo lo hacemos nosotros, cuándo conviene y cuándo definitivamente no.

Cuándo conviene self-hosting y cuándo no

La respuesta corta: conviene cuando tenés alguien del equipo con conocimientos básicos de Linux o un implementador externo que mantenga la infraestructura. No conviene cuando el sistema es crítico y nadie en la empresa sabe leer logs ni hacer restart de un contenedor.

Las ventajas del self-hosting son concretas: costo una fracción del Cloud, workflows ilimitados, datos bajo tu control, posibilidad de correr nodos custom sin pedir permiso, y a veces latencia más baja si el VPS está cerca del resto de tu infraestructura.

Las desventajas también son concretas: sos responsable de los backups, las actualizaciones, los certificados HTTPS, los incidentes de infra, y de que el sistema esté arriba cuando lo necesites. Si el workflow de tu cierre mensual corre la noche del 30 y el VPS está caído, nadie te avisa.

Nuestro criterio: si el cliente tiene un referente técnico propio o trabaja con nosotros en régimen de mantenimiento, self-hosting. Si no, n8n Cloud es más barato en tiempo total.

VPS recomendado (y por qué no AWS)

Para un n8n chico hay tres VPS providers que usamos habitualmente: Hetzner, Contabo y DigitalOcean. Los tres tienen planes con 2 GB de RAM y 1 vCPU que alcanzan para correr n8n con decenas de workflows concurrentes.

Hetzner es la opción de mejor precio/rendimiento en 2026. Un CX22 con 2 vCPU y 4 GB de RAM sale cerca de 5 euros mensuales, más tráfico generoso incluido. Los datacenters están en Alemania y Finlandia. Para un cliente europeo es ideal; para uno latinoamericano la latencia es aceptable pero no perfecta.

Contabo es más barato aún (sus VPS chicos arrancan en 5 USD con 4 GB de RAM), pero la red es más inestable y el soporte menos profesional. Lo usamos en proyectos donde el cliente quiere maximizar ratio costo/capacidad y no le molesta una caída cada tanto.

DigitalOcean es más caro (un droplet básico de 2 GB arranca en 12 USD) pero tiene datacenters en US y una UI que los clientes técnicos-junior entienden. Lo usamos cuando el cliente quiere poder mirar la consola él mismo.

Por qué no AWS / Azure / GCP: son plataformas pensadas para workloads grandes con equipos dedicados. Correr un n8n chico en t3.small de AWS cuesta más que Hetzner y requiere configurar VPC, security groups, IAM, métricas, y otras 20 cosas que no necesitás. Es como usar un torno industrial para afilar un cuchillo.

Setup en Docker Compose

El stack estándar que usamos:

• n8n como contenedor principal.
• Postgres como base de datos (n8n soporta SQLite pero no lo recomendamos para producción).
• Caddy como reverse proxy con HTTPS automático (mucho más simple que Nginx + Certbot).

La idea conceptual, sin pegar archivos de configuración literales (que varían según versión):

1. Un docker-compose.yml con tres servicios: n8n, postgres, caddy. Volúmenes persistentes para los datos de n8n y la base.
2. Variables de entorno con credenciales de Postgres, URL pública, y las variables de timezone (importante: n8n tiene que saber tu timezone para los schedules, por defecto usa UTC).
3. Caddy configurado con tu dominio apuntando al puerto interno de n8n. Caddy maneja los certificados Let's Encrypt solo, no tenés que configurar nada.
4. Puertos: solo 80 y 443 expuestos al exterior. Postgres y el puerto interno de n8n no se exponen.

El setup completo lo hacemos en unos 20 minutos cuando ya tenemos el VPS. Lo difícil nunca es Docker; es todo lo que viene después.

Dominio y HTTPS

n8n necesita un dominio para que los webhooks entrantes funcionen. Un subdominio dedicado (ej. n8n.tuempresa.com) con un registro A apuntando al IP del VPS es suficiente.

Caddy obtiene el certificado HTTPS automáticamente al arrancar. La única precondición es que el dominio ya esté propagado antes de iniciar el stack; si no, Let's Encrypt va a rechazar el challenge y tenés que debuggear tomos de logs.

Un detalle que mucha gente olvida: los webhooks entrantes tienen que coincidir con la URL pública que configuraste en n8n (N8N_PROTOCOL + N8N_HOST). Si la URL no coincide, los webhooks llegan pero n8n los rechaza.

Backups: la parte que nadie quiere pensar

Tu base de datos de n8n contiene: la definición de todos los workflows, el historial de ejecuciones recientes, las credenciales encriptadas de servicios conectados, y los datos de estado. Perderla es perder semanas de trabajo.

El enfoque mínimo viable:

1. Un pg_dump diario a las 3 AM, guardado localmente en el VPS.
2. El mismo dump copiado a almacenamiento externo (S3, Hetzner Storage Box, Backblaze B2).
3. Retención de 30 días.
4. Una alerta si el backup no se ejecutó en las últimas 48 horas.

El detalle crítico es el punto 2. Tener backups locales es inútil si el VPS se incendia. Nos tocó ver un cliente (de otra consultora, no nuestro) que perdió todo cuando Contabo tuvo un incidente de hardware y no había backups externos.

También hacé una vez por trimestre un test de restore real: levantá el backup en un VPS nuevo y asegurate de que n8n arranca y los workflows están ahí. Los backups que nunca se restauran no existen.

Actualización y mantenimiento

n8n libera versión nueva casi todas las semanas. Actualizar es simple: cambiar el tag de la imagen en Docker Compose y hacer docker compose up -d. Pero no lo hagas automáticamente en producción.

Nuestro proceso:

1. Leer las release notes. A veces hay breaking changes (cambios en nodos, renombres de campos).
2. Probar la versión nueva en un VPS de staging con workflows de prueba.
3. Si todo bien, aplicar a producción fuera de ventana crítica.
4. Mantener el tag anterior por si hay que hacer rollback rápido.

Las actualizaciones de Postgres son menos frecuentes pero más delicadas. No upgradees Postgres major version con el contenedor corriendo; hacé siempre backup antes.

Costos reales

Lo que termina pagando un cliente típico por un n8n self-hosted:

• VPS Hetzner CX22 (4 GB, 2 vCPU): 5 EUR/mes
• Dominio / subdominio: prorrateo de unos pocos centavos
• Backup storage (Hetzner Storage Box o Backblaze B2): 1-2 USD/mes
• Total: 6-8 USD/mes

Comparación con n8n Cloud Starter: 20 USD/mes con límites en ejecuciones y workflows activos.

Comparación con Make (ex Integromat) nivel similar: 29 USD/mes.

El costo real no es el VPS. El costo real es el tiempo que el equipo dedica a mantener la infra. Si ese tiempo es 2 horas al mes y el equipo ya sabe Linux, el ROI es evidente. Si cada update se convierte en una incidencia que requiere que contrates a alguien, el Cloud puede ser más barato en tiempo total.

Cuándo definitivamente conviene n8n Cloud

• Tenés menos de 5 workflows activos y nunca vas a tener más de 10.
• Nadie en tu equipo sabe Linux y no vas a contratar a nadie que lo sepa.
• Los workflows son críticos y no querés ser el single point of failure si algo se cae a las 3 AM.
• Necesitás soporte oficial con SLA (Cloud Pro lo incluye).

Cuándo self-hosting gana

• Tenés 10 o más workflows o volumen alto de ejecuciones.
• Tus datos no pueden salir de tu control (compliance, contratos con clientes).
• Necesitás nodos custom o paquetes de Node.js que Cloud no permite.
• Tenés a alguien (interno o externo) que se hace cargo del mantenimiento.
• Valoras la independencia a largo plazo más que los 15 USD al mes de diferencia.

Para la mayoría de nuestros clientes PyME caemos en el segundo grupo. El VPS se vuelve parte del stack natural y después de las primeras semanas se olvida que está ahí.