Cómo instalar n8n en 10 minutos usando Railway (mi setup real)

Quería n8n funcionando ya, no pelearme con Docker

Uso n8n para automatizaciones rápidas: scrapers, flujos con IA, integraciones entre APIs. En local va perfecto. Un docker compose up y listo.

El problema viene cuando quieres algo accesible desde fuera. Webhooks. Integraciones con terceros. Compartir un flujo. Ahí necesitas HTTPS, dominio público y algo mínimamente estable.

Podía montarlo en un VPS. O en mi propio servidor. Pero quería algo rápido. Sin perder una tarde en configurar nginx, SSL y backups.

Mi solución: Railway.

Por qué Railway y no otra cosa

Railway me gusta por tres razones:

• Deploy desde template en un clic.
• Variables de entorno claras.
• Base de datos gestionada en el mismo proyecto.

No es lo más barato si escalas mucho. Pero para proyectos personales, pruebas serias o side projects, me encaja.

Además, tienen un template oficial de n8n: https://railway.com/deploy/n8n

Eso elimina el 80% del trabajo.

El proceso real paso a paso

Voy al grano. Así lo hago yo.

1. Crear proyecto desde el template

Entro en el enlace del template y pulso Deploy on Railway.

Me logueo con GitHub. Railway crea un nuevo proyecto automáticamente con:

• Servicio de n8n
• Base de datos PostgreSQL
• Variables básicas preconfiguradas

En menos de un minuto está levantado.

Sin Docker. Sin tocar un servidor.

2. Configurar variables críticas

Aquí es donde muchos la lían.

Railway suele autogenerar algunas variables, pero yo reviso estas sí o sí:

N8N_HOST
WEBHOOK_URL
N8N_ENCRYPTION_KEY

N8N_HOST

Debe ser el dominio que Railway te asigna o tu dominio custom.

Ejemplo:

my-n8n-production.up.railway.app

Sin https://, solo el host.

WEBHOOK_URL

Clave para que los webhooks funcionen correctamente.

https://my-n8n-production.up.railway.app/

Con protocolo. Y normalmente con slash final.

Si esto está mal, los triggers no funcionan desde fuera.

N8N_ENCRYPTION_KEY

Muy importante.

Genero una clave larga:

openssl rand -base64 32

La guardo como variable de entorno. Esto cifra credenciales internas. Si cambias esta clave después, pierdes acceso a credenciales guardadas.

No la cambies a la ligera.

---

Después de ajustar variables, redeploy automático. Railway lo hace solo.

Añadir dominio custom

El subdominio de Railway está bien para empezar. Pero yo prefiero algo mío.

En Railway:

1. Settings del servicio.
2. Networking.
3. Add custom domain.

Apuntas el DNS (CNAME normalmente) desde tu proveedor.

En cuanto el dominio está activo, actualizo:

N8N_HOST=automatizaciones.midominio.com
WEBHOOK_URL=https://automatizaciones.midominio.com/

Redeploy y listo.

HTTPS lo gestiona Railway automáticamente.

Errores típicos que ya me he comido

Webhooks que no se disparan

Casi siempre es esto:

• WEBHOOK_URL mal configurado
• N8N_HOST sin coincidir con el dominio real
• Mezcla de http y https

Revisa variables. Redeploy. Se arregla.

Pérdida de credenciales

Cambiar N8N_ENCRYPTION_KEY después de haber guardado credenciales.

No lo hagas.

Si necesitas migrar, haz backup antes.

¿Y en vez de Railway?

Podrías usar:

Opción	Ventaja	Desventaja
VPS propio	Más control	Más tiempo de setup
Docker en tu server	Flexible	Mantenimiento
n8n Cloud	Cero gestión	Más caro

Yo uso Railway cuando quiero equilibrio entre:

• Rapidez
• Control
• Coste razonable

No es la solución definitiva para un SaaS grande. Pero para automatizaciones personales, clientes pequeños o prototipos serios, funciona muy bien.

Resultado real en mi caso

En menos de 10 minutos tenía:

• n8n accesible por HTTPS
• Autenticación básica activa
• Base de datos persistente
• Webhooks funcionando

Sin tocar nginx. Sin pelearme con certificados. Sin montar infraestructura desde cero.

Eso es lo que buscaba.

Si mañana necesito algo más robusto, lo migro. Pero para iterar rápido, Railway me da velocidad. Y para mí, ahora mismo, eso pesa más que la perfección arquitectónica.