GitHub Actions como PaaS propio: guia para founders

¿Qué es usar GitHub Actions como plano de control de un PaaS?

Si alguna vez sentiste que plataformas como Heroku, Render o Railway te cobraban demasiado por alojar tus proyectos, este experimento llega en el momento justo. La propuesta es directa: convertir un servidor Debian —puede ser un VPS de Hetzner o DigitalOcean desde $5 USD al mes— en tu propio PaaS (Platform as a Service) usando GitHub Actions como el cerebro que orquesta todo. El resultado es una infraestructura propia, sin dependencias de terceros y con las mismas funcionalidades que pagas caro en plataformas comerciales.

La arquitectura detrás del experimento

El stack técnico es deliberadamente simple y battle-tested. En el servidor Debian corren Docker Compose para aislar cada aplicación en su propio contenedor, y Caddy como reverse proxy que gestiona el enrutamiento y los certificados TLS automáticos vía Let’s Encrypt. No hay que tocar manualmente ningún certificado SSL: Caddy lo renueva solo.

El flujo de trabajo es el siguiente:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Un developer hace push o abre un Pull Request en el repositorio.
GitHub Actions ejecuta el workflow definido en .github/workflows/deploy.yml: lint, tests, build de la imagen Docker y push al registry (GHCR o Docker Hub).
Via SSH action o un runner auto-hospedado, el servidor recibe la señal, hace docker-compose pull y levanta la nueva versión con docker-compose up -d.
Caddy detecta los cambios de configuración y recarga el enrutamiento sin downtime.

El resultado es un pipeline de CI/CD completo donde GitHub Actions actúa como el plano de control: reemplaza el dashboard de cualquier PaaS comercial con simples archivos YAML versionados en tu propio repositorio.

Funcionalidades clave que 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). Ideal para mostrar cambios a clientes o co-founders antes de mergear a producción. El entorno se destruye automáticamente cuando el PR se cierra o se fusiona.

TLS automático sin configuración manual

Caddy gestiona los certificados de Let’s Encrypt por ti. No más certbot manual ni scripts de renovación programados. Cada nuevo subdominio o app que agregas obtiene su certificado de forma automática en cuestión de segundos.

Monitoreo integrado self-hosted

El stack incluye Prometheus y Grafana para métricas del servidor y de cada aplicación, más Uptime Kuma para alertas de disponibilidad. Todo corriendo en el mismo VPS, sin pagar por herramientas de observabilidad externas.

Gestión de secretos y variables de entorno

Las credenciales de base de datos, API keys y variables sensibles 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 cuesta realmente versus un PaaS comercial?

Aquí está el dato que más importa a un founder en etapa temprana. Consideremos un escenario con 10 apps activas:

Self-hosted en VPS (este enfoque): $20–50/mes por el servidor + GitHub Actions gratuito (2.000 minutos/mes en plan free). Total: ~$20–50/mes para todas las apps.
Heroku: ~$7–25 por dyno/app. Con 10 apps, entre $70 y $250/mes.
Render o Railway: Modelos similares con billing por servicio activo, típicamente $50–150/mes para 10 servicios con tráfico real.

El ahorro puede superar el 90% para setups de bajo a mediano tráfico (menos de 10.000 requests diarios por app). El costo operativo adicional es el tiempo de mantenimiento del servidor, que con este approach se minimiza gracias a la automatización vía Actions.

Casos de uso prácticos para founders tech

Este setup brilla en contextos muy concretos del ecosistema startup:

MVP de SaaS con múltiples microservicios: Un frontend en Next.js, una API en FastAPI y una base de datos PostgreSQL corriendo en el mismo VPS, cada uno con su subdominio y TLS automático.
Agencias de desarrollo: Alojar proyectos de varios clientes en un mismo servidor con aislamiento total por contenedor, sin pagar por cada instancia.
Side projects e indie hacking: Mantener 5 a 20 proyectos en paralelo sin que el costo de infraestructura destruya la viabilidad del experimento.
Equipo distribuido: Los PRs de cualquier miembro del equipo generan un preview en vivo en segundos, acelerando los ciclos de revisión y feedback.

Limitaciones que debes considerar

Este experimento no es la solución para todo. Hay trade-offs reales:

Sin auto-scaling nativo: Si tu app necesita escalar horizontalmente bajo carga variable, este setup requiere trabajo adicional. Para eso, tecnologías como Kubernetes con Actions Runner Controller son más adecuadas.
Mantenimiento del servidor: Actualizaciones de seguridad, backups y alta disponibilidad son tu responsabilidad. No hay un equipo de soporte detrás.
Curva de aprendizaje inicial: Si no tienes experiencia con Docker, SSH y administración de Linux, la configuración inicial tomará tiempo. No es zero-config como Railway.
Single point of failure: Un único VPS sin réplica significa que si el servidor cae, caen todas tus apps. Considera al menos un sistema de backups automatizados.

¿Para quién es ideal este approach?

Este setup es perfecto si eres un founder técnico o indie developer que:

Ya tiene experiencia con Docker y la terminal de Linux.
Quiere ownership total de su infraestructura sin depender de decisiones de pricing de terceros.
Está en etapa pre-revenue o early stage donde cada dólar de costos operativos importa.
Valora tener su pipeline de CI/CD como código versionado en GitHub, auditable y reproducible.

Proyectos como MultiPaaS en GitHub demuestran que la comunidad lleva años construyendo este tipo de soluciones sobre Kubernetes y herramientas open source. Este experimento con GitHub Actions es la versión más accesible y con menor fricción operativa de esa filosofía.

Conclusión

Usar GitHub Actions como plano de control de tu propio PaaS es una de las apuestas más inteligentes que puede hacer un founder técnico en 2026. No solo reduces costos de infraestructura en hasta un 90% comparado con PaaS comerciales, sino que ganas control total, eliminas el vendor lock-in y conviertes tu pipeline de despliegue en un activo versionado y documentado dentro de tu propio repositorio. El costo de entrada es bajo —un VPS de $20/mes y conocimientos básicos de Docker— y los beneficios escalan con cada proyecto que sumas. Si ya tienes experiencia técnica, la pregunta no es si deberías probarlo, sino cuándo empezarás.

Descubre cómo otros founders implementan estas soluciones de infraestructura y comparte tu stack con nuestra comunidad.

Ver soluciones de founders