← blog

Cómo deployar una app Node.js en tu propio VPS estilo Railway (con CI/CD)

Railway, Render y Heroku resolvieron algo enorme: git push → app online. El problema es el precio a escala y el lock-in. La buena noticia: hoy podés tener la misma experiencia en tu propio VPS de $5–10/mes.

Qué necesita un “Railway casero”

Para que el flujo push → deploy funcione de verdad hacen falta cinco piezas:

  1. Detección del stack — si el repo no trae Dockerfile, algo tiene que armar la imagen igual. Nixpacks (el mismo que usaba Railway) detecta Node, Python, Go, Rust o PHP y genera el plan de build.
  2. Builds encolados — dos builds simultáneos funden un VPS chico. Una cola con concurrencia 1 (BullMQ/Redis) mantiene el server vivo.
  3. Routing + SSL automático — cada app necesita su subdominio con HTTPS. Caddy con TLS on-demand emite certificados en la primera visita, sin certbot ni cron.
  4. Logs en vivo — sin build logs y runtime logs accesibles, cada deploy fallido es una sesión de SSH. Server-Sent Events sobre docker logs --follow resuelve.
  5. CI/CD — un webhook de GitHub (o polling del SHA del branch) que dispara el rebuild en cada push.

El flujo con CloudWapp

CloudWapp empaqueta esas cinco piezas (NestJS + BullMQ + Docker + Caddy) en un instalador de un comando. Deployar queda así:

# Opción 1: sin repo, directo desde tu máquina
cd mi-api
cloudwapp apps up --name mi-api -f

# Opción 2: desde un repo, con CI/CD en cada push
cloudwapp apps create --name mi-api \
  --repo https://github.com/usuario/mi-api --branch main --deploy

La salida del build llega en vivo a tu terminal y al final:

✓ Container running
✓ https://mi-api.apps.tudominio.com

Variables de entorno (apps env --set), volúmenes persistentes (--volume /app/data), restart, y notificaciones push cuando el deploy termina — lo mismo que un PaaS comercial, sobre tu hardware.

¿Cuándo conviene self-hostear?

¿Querés probarlo? Creá tu cuenta o leé la guía de deploys.