Alternativas “free” a Heroku para sysadmins: cómo elegir, migrar sin sobresaltos y operar con garantías

X (Twitter) Facebook Pinterest LinkedIn Email WhatsApp

El fin del plan gratuito de Heroku (Dynos, Postgres y Data for Redis) obligó a muchas organizaciones a mover apps y datos contra reloj. Dos años después, el escenario está claro: hay vida (gratuita o always-free) más allá de Heroku, pero no hay un reemplazo 1:1. Para un sitio de administración de sistemas, este artículo no es una lista, sino un plan operativo: qué modelo técnico elegir, cómo migrar con mínima indisponibilidad, y cómo operar con observabilidad, seguridad y costes bajo control.

Resumen ejecutivo

Modelos: PaaS/Contenedores, Serverless, Jamstack, BDs gestionadas y PaaS autoalojado.

Claves de migración: inventario → Procfile/Dockerfile → add-ons → datos → CI/CD → red y seguridad → observabilidad → runbooks.

Riesgos: sleep policies, SMTP bloqueado, límites de egress, vendor lock-in, backups inexistentes en tiers gratuitos.

1) Modelos de destino: pros/cons para quien opera

A) PaaS / Contenedores gestionados

Render, Koyeb, Northflank, Qoddi, Alwaysdata, Back4App, Netlify/Vercel (con funciones).
Ventajas: git deploy, buildpacks o Docker, autoscaling sencillo, Postgres/Redis como add-ons.
Inconvenientes: sleep en planes gratis, SMTP restringido, límites de CPU/RAM, egress no garantizado.

Cuándo: apps web/REST, workers y crons donde el coste/operación pesan más que la latencia extrema.

B) Serverless

Cloud Run, AWS Lambda, Azure Container Apps, Cloudflare Workers/Pages Functions.
Ventajas: scale-to-zero, pago por uso, edge global (Workers).
Inconvenientes: cold start, cuotas y límites por minuto, stateless por diseño, tracing más complejo.

Cuándo: APIs stateless, tareas event-driven, microservicios.

C) Jamstack & estático

Netlify, Vercel, Cloudflare Pages, GitHub Pages, Surge.
Ventajas: CDN global, preview deploys, coste ínfimo.
Inconvenientes: backend aparte (funciones o APIs externas), límites de build minutes.

D) Bases de datos gestionadas (reemplazo de Heroku Postgres/Redis)

CockroachDB Serverless, Neon (Postgres), Supabase (Postgres), PlanetScale (MySQL), TiDB Cloud, Turso (SQLite edge), Upstash (Redis/Kafka), Redis Enterprise (starter), MongoDB Atlas M0.
Ventajas: PITR, branching, autosuspend, edge.
Inconvenientes: almacenamiento mínimo, SLAs limitados, regiones acotadas en free.

E) PaaS autoalojado (self-hosted)

Dokku, CapRover, Coolify, Tsuru, Piku.
Ventajas: control total, git push deploy, sin sleep, sin lock-in.
Inconvenientes: no es gratis operarlo (VPS/IaaS), hay que gestionar patching, backups, TLS, monitoring.

2) Árbol de decisión rápido (operaciones en mente)

¿La app es stateless y puede tolerar cold start? → Serverless (Cloud Run/Lambda/Workers).
¿Necesita WebSocket o procesos siempre activos? → PaaS/Contenedores (Render/Koyeb/Northflank) o self-hosted (Dokku/CapRover).
¿Tráfico “picos y valles” + coste mínimo? → Serverless o PaaS con scale-to-zero.
¿Residencia de datos/GDPR + PITR real? → Neon/Supabase/PlanetScale/CockroachDB según stack.
¿Equipo desea portabilidad y evitar lock-in**? → Docker + self-hosted PaaS.

3) Plan de migración (30-60-90 días)

0) Inventario (semana 1)

Repos, Procfile, buildpacks, variables de entorno, add-ons (Postgres/Redis/SMTP), domains, SSL, schedulers.
Dependencias externas (pagos, webhooks, S3, OAuth).
SLOs: latencia, uptime, ventana de downtime aceptable.

1) Runtime (semanas 2-3)

Procfile → Dockerfile si sales de buildpacks. FROM node:20-alpine WORKDIR /app COPY package*.json . RUN npm ci --only=production COPY . . EXPOSE 3000 CMD ["node","server.js"]
Profiles de worker y cron → services/jobs/schedulers del proveedor.
Secrets: pasar de Config Vars a Secret Manager (o env cifrado del PaaS).

2) Datos (semanas 3-5)

Postgres: preferible replicación lógica o pg_dump/pg_restore + ventana de read-only. pg_dump -Fc "$HEROKU_DATABASE_URL" -f dump.pg pg_restore --no-owner --no-privileges -d "$NEW_DB_URL" dump.pg
Redis: export/import si el proveedor lo soporta; o rehidratación a partir de DB de verdad (evitar tratar Redis como almacenamiento primario).
Validar encodings, extensions y collations.

3) Red y dominios (semanas 4-6)

TLS/ACME gestionado por el proveedor o cert-manager (self-hosted).
IP de egress fija (si tu upstream lo exige) → NAT Gateway o proveedor que la garantice.
WAF/CDN: Cloudflare/fastly frente a bots, DDoS, rate limits.
SMTP: la mayoría de free tiers lo bloquean; usa SendGrid/Postmark/Mailgun free plan.

4) Observabilidad (semanas 5-7)

Logs estructurados (JSON) + correlation-id.
Centraliza con ELK / Loki+Promtail / OpenSearch o añade add-ons gestionados.
Tracing: OpenTelemetry → Tempo/Jaeger/X-Ray/Cloud Trace.
Métricas: Prometheus + Grafana, alertas en PagerDuty/Opsgenie.

5) CI/CD (semanas 6-8)

Pipelines con GitHub Actions/GitLab CI: lint/tests/build image/deploy.
Previews (review apps) si el proveedor lo soporta.
Canary/Blue-Green cuando sea viable.

6) Seguridad y cumplimiento (semanas 7-9)

SSO/SCIM, RBAC, rotación de tokens y keys.
Backups diarios verificados (restore-test mensual).
Data residency y DPA/GDPR del proveedor.

7) Runbooks y rollback (semana 9)

Procedimientos escritos: escalado, incident, DB restore, secret rollover.
Plan de rollback a Heroku o a una versión anterior.

4) Cookbook por destino (comandos y gotchas)

Render / Koyeb / Northflank (PaaS contenedores)

Build por Docker o buildpacks.
Define web, worker, cron como servicios separados.
Adjunta Postgres/Redis gestionados o externos (Neon/Upstash).
Gotchas: sleep en free, egress limitado, SMTP bloqueado.

Cloud Run (GCP) / Lambda (AWS) / Workers (Cloudflare)

Contenedor mínimo / función.
Cloud Run: buen “punto medio”: HTTP, concurrency, min instances para mitigar cold start.
Workers: latencia ínfima, KV/Queues/D1; limites de CPU/duración.
Gotchas: cold start, state externo, RDS Proxy o Neon para Postgres.

Dokku / CapRover / Coolify (self-hosted)

VPS (2–4 vCPU, 4–8 GB RAM) + swap + disco NVMe.
Instalar plataforma, activar ACME/Let’s Encrypt, backups y monitoring.
Git push (Dokku/Piku) o one-click apps (CapRover/Coolify).
Gotchas: patching del host, firewalling, fail2ban, PITR manual en BDs.

5) Sustituciones frecuentes de add-ons

Heroku Postgres → Neon / Supabase / CockroachDB Serverless (PG), PlanetScale (MySQL), TiDB Cloud.
Heroku Redis → Upstash / Redis Enterprise (starter).
Heroku Scheduler → Cron del PaaS o Cloud Scheduler (GCP)/EventBridge (AWS)/Workers Cron (CF).
Heroku Logplex → Loki/ELK/OpenSearch gestionado o propio.
Heroku Mail → SendGrid/Postmark/Mailgun (planes free/hobby).

6) Operación diaria (lo que más duele si te olvidas)

Sleep/autosuspend: programa pings si es legal, o sube a tier sin sleep.
Backups verificados: no asumas nada en free. Restaura en sandbox mensualmente.
Rotación de secrets: calendario trimestral, audit logs.
Coste: panel mensual con usage, alerta por egress, minutos de build, invocaciones.
Seguridad: bloqueo SSH, sólo OIDC/SSO, límites de IP, WAF/CDN, rate limiting.
RRHH: on/off-boarding de acceso a PaaS, repos y secrets.

7) Checklist de migración (imprimible)

Inventario apps/add-ons/domains/SLAs.
Dockerfile(s) y health checks.
BD destino elegida + plan dump/replicación + PITR.
Secrets en gestor dedicado.
TLS y DNS cutover con TTLs bajos.
Logs, métricas, tracing y alertas en marcha.
CI/CD con preview y rollback.
Backups automáticos + restore-test.
Runbooks de incidente/restore/rotación.
Validación de sleep/SMTP/limits del plan elegido.

8) FAQs de sysadmin

¿Cómo minimizar el downtime de Postgres?
Replica lógicamente (si es posible), o dump/restore + ventana read-only. Para apps críticas, prepara dual-write transitorio y corta por feature flag.

¿Puedo tener IP saliente fija en free?
Rara vez. Usa NAT Gateway (nube propia), egress dedicado del PaaS (si existe) o Cloudflare Tunnel según casos.

¿Cómo sustituyo los review apps de Heroku?
Con preview deployments (Vercel/Netlify/Render/Koyeb) o environments efímeros en tu CI (spin-up de contenedor y DB branch en Neon/PlanetScale).

¿Qué pasa con cron y workers?
Decláralos como servicios separados (PaaS) o usa Cloud Scheduler/EventBridge/Workers Cron en serverless. Evita crons dentro del contenedor web.

¿Cómo controlo el coste en serverless?
Cuotas de invocación, timeouts, concurrency mínimo, caching, y alerta de egress. Revisa facturación cada semana el primer mes.

Proveedores útiles (referencia rápida)

PaaS/containers: render.com, koyeb.com, northflank.com, qoddi.com, alwaysdata.com
Serverless & edge: cloud.run, lambda, azure container apps, workers.cloudflare.com, pages.cloudflare.com
DBs: cockroachlabs.cloud, supabase.com, neon.tech, planetscale.com, tidbcloud.com, turso.tech
Redis/Kafka: upstash.com, redis.com/try-free
Static/Jamstack: vercel.com, netlify.com, pages.github.com, surge.sh
Self-hosted PaaS: dokku.com, caprover.com, coolify.io, tsuru.io, piku.github.io

Conclusión. Sustituir Heroku en free/hobby es posible si se entiende que el modelo operativo cambia: más sleep, más límites y más responsabilidad en observabilidad y seguridad. Para producción, plantéate tiers de pago mínimos (sin sleep) o self-hosted con buenas prácticas (Docker, backups, monitoring). La “buena migración” no es la que copia comandos, sino la que deja a Operaciones con visibilidad, runbooks y costes previsibles.