Heroku cumplió un ciclo, Render y Railway se volvieron caros para quien tiene más de tres servicios activos, y en 2026 GitHub Actions cambió su modelo de precios para runners autoalojados. En ese contexto, un experimento que circula en la comunidad técnica plantea algo más radical que “migrar de plataforma”: usar GitHub Actions como el cerebro que controla tu propia infraestructura en un VPS de $20 al mes.
La idea suena más compleja de lo que es. El resultado práctico: un pipeline de CI/CD completo con deployment previews por Pull Request, TLS automático, monitoreo integrado y gestión de secretos — todo por el costo de un VPS barato y sin depender de un proveedor de PaaS comercial.
¿Qué hace exactamente GitHub Actions en este rol?
En un PaaS tradicional (Heroku, Render, Railway) la plataforma actúa como “plano de control”: recibe tu código, construye la imagen, la despliega y gestiona el enrutamiento. Aquí, ese rol lo toma GitHub Actions.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀El flujo es simple: haces push a tu repositorio → Actions ejecuta lint, tests, build de imagen Docker y push al registry (GHCR o Docker Hub) → vía SSH action, el servidor recibe la señal, hace docker-compose pull y levanta la nueva versión. Caddy detecta los cambios de configuración y recarga el enrutamiento sin downtime.
El stack que sostiene esto tiene tres piezas:
- Docker Compose: aísla cada app en su contenedor
- Caddy: reverse proxy que gestiona enrutamiento y certificados TLS vía Let’s Encrypt de forma automática
- GitHub Actions: orquesta todo el ciclo de vida del deployment
Es deliberadamente simple. No hay Kubernetes, no hay dashboards propietarios, no hay CLI especial que aprender. El pipeline vive como archivos YAML dentro de tu propio repositorio, versionado y auditable.
¿Qué funcionalidades concretas te da este setup?
Deployment Previews por Pull Request: cada PR dispara un entorno efímero bajo un subdominio propio (por ejemplo, pr-42.tudominio.com). Útil para mostrar cambios a clientes o co-founders antes de mergear. El entorno se destruye solo cuando el PR se cierra o se fusiona.
TLS automático sin configuración manual: Caddy gestiona los certificados Let’s Encrypt por ti. No más certbot manual ni scripts de renovación programados. Cada nuevo subdominio obtiene su certificado en segundos.
Monitoreo integrado self-hosted: el stack incluye Prometheus, Grafana y Uptime Kuma corriendo en el mismo VPS. Sin pagar por herramientas de observabilidad externas. (Para quienes buscan monitoreo más ligero, Kula es una alternativa sin dependencias.)
Gestión de secretos: las credenciales de base de datos y API keys se almacenan en GitHub Secrets y se inyectan en el workflow en tiempo de ejecución. Nunca viajan en texto plano al servidor.
¿Cuánto se ahorra realmente?
El número que importa: para 10 apps activas, el costo en este approach ronda los $20-50/mes por el VPS más GitHub Actions gratuito (2.000 minutos/mes en el plan free). En Heroku o Render, el mismo escenario cuesta entre $70 y $250/mes.
El ahorro puede superar el 90% para setups de bajo a mediano tráfico. El costo operativo adicional es el tiempo de mantenimiento del servidor — que con este approach se minimiza gracias a la automatización — y la curva de aprendizaje inicial.
Un dato relevante de contexto: GitHub también cambió su relación con usuarios anónimos en 2025, y en 2026 introdujo cobros para runners autoalojados. Eso modifica parcialmente el cálculo — aunque el plan free sigue siendo generoso para proyectos con tráfico moderado.
Cuándo tiene sentido (y cuándo no)
Este approach brilla en tres escenarios concretos:
- MVP o side projects con varios servicios: frontend, API y base de datos en el mismo VPS, cada uno con subdominio y TLS automático
- Agencias de desarrollo: alojar proyectos de varios clientes con aislamiento total por contenedor, sin pagar por cada instancia
- Equipos distribuidos: cada PR genera un preview en vivo en segundos, acelerando los ciclos de revisión
Pero hay límites reales que conviene no ignorar:
- Sin auto-scaling nativo: si tu app necesita escalar horizontalmente bajo carga variable, este setup requiere trabajo adicional. Para eso, Kubernetes con Actions Runner Controller es más adecuado.
- Single point of failure: un único VPS significa que si el servidor cae, caen todas tus apps. Requiere al menos backups automatizados.
- Curva de entrada: sin experiencia con Docker, SSH y administración básica de Linux, la configuración inicial toma tiempo. No es zero-config como Railway.
Por qué importa
La tendencia de fondo es clara: las plataformas que antes simplificaban el deployment a costa de vendor lock-in y precios escalonados están perdiendo atractivo. Rails 8 movió en la misma dirección: simplificar la infraestructura para que un equipo pequeño pueda operar sin capas de dependencia comercial.
GitHub Actions como PaaS propio no es una solución para todos. Requiere criterio técnico y disposición a mantener tu propio servidor. Pero para el founder técnico en etapa temprana — o el indie developer con varios proyectos activos — el tradeoff es difícil de ignorar: control total, cero vendor lock-in, y costos operativos predecibles en un entorno donde los PaaS comerciales siguen ajustando precios hacia arriba.
