CI/CD Self-Hosted vs. Pipelines en la Nube — La Cuenta que Casi Nadie Hace
CI/CD Self-Hosted vs. Pipelines en la Nube — La Cuenta que Casi Nadie Hace
TL;DR: Un VPS en Hetzner a €40/mes es ~75x más barato por minuto que los runners hospedados de GitHub Actions. Pero el mantenimiento de Jenkins cuesta $15-30K/año en tiempo de ingeniería (20-40 horas/mes). La respuesta real está en algún punto intermedio. GitHub Actions recortó precios hasta 39% en enero de 2026, luego intentó cobrar $0.002/min por runners self-hosted — y revirtió la decisión en menos de 24 horas tras el rechazo masivo de la comunidad. Los costos ocultos de AWS CodeBuild (CloudWatch, NAT Gateway, S3) pueden multiplicar 15x tu costo aparente de build. La brecha de seguridad de CircleCI en 2023 forzó a todos sus clientes a rotar secretos. Los runners de macOS en GitHub Actions le costaron a un desarrollador $2,273 en 17 días. La respuesta correcta depende de tu volumen de builds, tamaño de equipo, y cuánto valoras el tiempo de tus ingenieros vs. tu factura de la nube.
Todo equipo de desarrollo ejecuta CI/CD. Pocos han calculado realmente cuánto cuesta.
Las páginas de precios lucen simples: GitHub Actions cobra $0.008/minuto para Linux. AWS CodeBuild cobra $0.005/minuto. Google Cloud Build ofrece 2,500 minutos gratis. Parece calderilla.
Entonces alguien hace las cuentas. Un equipo de 15 desarrolladores haciendo push 3 veces al día con builds de 8 minutos quema 54,000 minutos por mes. A tarifas de GitHub Actions, eso son $324/mes — o $3,888/año — solo para builds en Linux. Agrega macOS para mobile, Windows para testing cross-platform, y estás viendo una factura anual de cinco cifras por algo que corre en una computadora.
Mientras tanto, un servidor dedicado en Hetzner con 64 GB de RAM y almacenamiento NVMe cuesta €40/mes. Son €480/año por builds ilimitados sin cobro por minuto.
Entonces, ¿por qué no todos hacen self-hosting? Porque la cuenta no es tan simple. Hagámosla bien.
El Panorama: ¿Qué Estamos Comparando?
Antes de entrar en números, definamos los tres enfoques:
CI/CD completamente administrado en la nube — Pagas por minuto, por asiento, o por crédito. El proveedor maneja la infraestructura, el escalamiento y el mantenimiento. Ejemplos: GitHub Actions, GitLab SaaS, CircleCI, AWS CodeBuild, Google Cloud Build, Azure DevOps Pipelines, Bitbucket Pipelines.
Self-hosted en VPS/servidores dedicados — Tú administras la infraestructura de build. El software de CI/CD es gratuito; pagas por los servidores. Ejemplos: Jenkins, GitLab CI (self-hosted), Drone CI, Woodpecker CI, Forgejo Actions.
Híbrido — Orquestación en la nube con cómputo self-hosted. Obtienes el motor de workflows de un proveedor administrado pero ejecutas los builds en tus propias máquinas. Ejemplos: Buildkite, runners self-hosted de GitHub Actions, GitLab SaaS con runners self-managed, Actions Runner Controller (ARC) en Kubernetes.
Cada uno tiene costos ocultos que la página de precios no te mostrará.
CI/CD en la Nube: Lo que Realmente Pagas
La Tabla Comparativa de Precios
Esto es lo que cobra cada plataforma importante a febrero de 2026:
| Plataforma | Linux (por min) | macOS (por min) | Windows (por min) | Free Tier |
|---|---|---|---|---|
| GitHub Actions (ene 2026) | $0.006 | $0.062 | $0.010 | 2,000 min/mes |
| AWS CodeBuild (general1.small) | $0.005 | N/A | N/A | 100 min/mes |
| AWS CodeBuild (general1.medium) | $0.010 | N/A | $0.018 | — |
| Google Cloud Build (e2-medium) | $0.003 | N/A | N/A | 2,500 min/mes |
| Azure DevOps (hosted) | $40/trabajo paralelo/mes | — | $40/trabajo paralelo/mes | 1 trabajo paralelo gratis (1,800 min) |
| GitLab SaaS (Premium) | $0.010/min excedente | N/A | N/A | 400 min (Free), 10K min (Premium) |
| CircleCI (medium Linux) | $0.006 | Similar a macOS | $0.096 | 6,000 créditos/mes |
| Bitbucket Pipelines | $0.008 | N/A | N/A | 50 min/mes |
Fuentes: precios de GitHub Actions, precios de AWS CodeBuild, precios de Google Cloud Build, precios de GitLab, precios de CircleCI.
GitHub Actions tuvo una reducción importante de precios el 1 de enero de 2026 — hasta 39% de descuento en general. Los runners de Windows arm64 tuvieron los recortes más agresivos. Antes de esto, Linux 2-core costaba $0.008/min.
Google Cloud Build es la opción más barata por minuto a $0.003/min con el free tier más generoso (2,500 minutos/mes). Pero también tuvo una reestructuración de precios en noviembre de 2025, cambiando de 120 minutos gratis por día a 2,500 por mes — más flexible, pero en realidad una reducción del equivalente anterior de ~3,600 minutos/mes.
Azure DevOps usa un modelo completamente diferente: pagas por trabajo paralelo ($40/mes para hospedado, $15/mes para self-hosted) en vez de por minuto. Para equipos ejecutando muchos builds cortos secuencialmente, esto puede ser más barato. Para equipos que necesitan mucho paralelismo, se encarece rápido.
La Trampa de macOS
Si construyes apps para iOS o macOS, prepárate. GitHub Actions cobra $0.062/minuto por macOS — más de 10x la tarifa de Linux. Las restricciones de licenciamiento de Apple y el hardware especializado hacen esto inevitable en todas las plataformas.
Un desarrollador documentó sus costos de runners macOS:
- 28,723 minutos en el período de facturación
- Menos 300 minutos gratis = 28,423 minutos facturables
- 28,423 × $0.08 (tarifa pre-reducción) = $2,273.84 por 17 días
- Proyectado mensual: ~$4,167
Su solución: comprar Mac Minis para self-hosting. Ahorro: $4,000+/mes. El hardware se pagó solo en menos de dos meses.
La Trampa del Sistema de Créditos (CircleCI)
CircleCI usa un modelo basado en créditos que suena flexible hasta que haces las cuentas. Los créditos se venden en paquetes de 25,000 por $15 ($0.0006 por crédito). Un executor medium de Linux consume 10 créditos/minuto, entonces:
- 10,000 minutos de build/mes = 100,000 créditos = $60/mes
- Agrega Docker Layer Caching a 200 créditos por job: 500 jobs × 200 = 100,000 créditos extra = $60/mes más
- Builds en Windows consumen 160-500 créditos/minuto — hasta $18/hora
El sistema de créditos oscurece el costo real por minuto detrás de una capa de abstracción. Y algunas clases de recursos se están retirando en febrero de 2026, forzando migración a tiers potencialmente más caros.
Los Costos Ocultos que Disparan la Factura
La tarifa por minuto es solo el comienzo. Esto es lo que las páginas de precios no enfatizan.
AWS CodeBuild: El Multiplicador de 15x
Un build de 2 minutos en la instancia general1.medium de CodeBuild parece costar $0.02. Pero según la propia guía de optimización de AWS, el costo real incluye:
| Componente | Costo |
|---|---|
| CodeBuild (2 min × $0.01/min) | $0.02 |
| CloudWatch Logs | ~$0.02 |
| Almacenamiento de artefactos en S3 | ~$0.01 |
| NAT Gateway (1 GB de datos) | ~$0.045 |
| Pull de imagen ECR (500 MB) | ~$0.02 |
| CodePipeline (costo diario prorrateado) | ~$0.033 |
| Total real | ~$0.15 |
Eso es 7.5x el costo aparente del build. Para builds con más transferencia de datos o workloads conectados a VPC, el multiplicador puede llegar a 15x.
El mayor asesino silencioso son los cargos de NAT Gateway. Si tus builds corren en una VPC sin los endpoints apropiados, cada byte de tráfico pasa por el NAT Gateway a $0.045/hora más $0.045/GB. Los VPC endpoints cuestan $0.01/hora — una fracción del precio — pero tienes que saber configurarlos.
GitHub Actions: Redondeo de Minutos
GitHub Actions factura en minutos completos, redondeando hacia arriba. ¿Ejecutaste un job por 5 segundos? Facturado por 1 minuto. ¿1 minuto y 1 segundo? Facturado por 2 minutos. Como notó un desarrollador en la discusión de la comunidad de GitHub:
“Run for 5 seconds. Billed for 1 minute. Run for 1 minute 1 second. Billed for 2 minutes.”
Para workflows con muchos jobs cortos (linting, formateo, chequeo de tipos), este redondeo infla el costo real significativamente comparado con la tarifa teórica por minuto.
Google Cloud Build: Precios Regionales
Los precios de Google Cloud Build varían por región. La tarifa de $0.003/min aplica para regiones de EE.UU. En otros lugares:
| Región | Tarifa e2-medium | Prima sobre EE.UU. |
|---|---|---|
| EE.UU. (us-central1) | $0.003/min | — |
| Londres (europe-west2) | $0.00342/min | +14% |
| Sídney (australia-southeast1) | $0.00375/min | +25% |
| Tokio (asia-northeast1) | $0.00384/min | +28% |
Si tu equipo está distribuido o tus requisitos de compliance dictan regiones fuera de EE.UU., ten esto en cuenta.
La Factura de $127K que Nadie Vio Venir
Una startup con 23 desarrolladores y 50,000 usuarios activos despertó con una factura mensual de $127,000 en la nube — con CI/CD como contribuyente significativo. La causa raíz: sin límites de auto-escalamiento, sin alertas de costos, y un pipeline de CI/CD que “simplemente corría” sin que nadie vigilara el medidor.
“CI/CD runs pipelines, Infra scales automatically, Costs show up weeks later in a finance dashboard.”
La lección: los servicios administrados de CI/CD no tienen límites duros de gasto. Las alertas de facturación te notifican después de que el daño está hecho.
CI/CD Self-Hosted: El Efecto Hetzner
En el otro extremo del espectro, hospedar tus builds en VPS o servidores dedicados ofrece una economía radicalmente diferente.
Costos de Servidores
| Proveedor | Servidor | Specs | Costo Mensual |
|---|---|---|---|
| Hetzner AX41-NVMe | Dedicado | Ryzen 5 3600, 64 GB RAM, 2× 512 GB NVMe | ~€40 |
| Hetzner Cloud CX22 | VPS | 2 vCPU, 4 GB RAM, 40 GB SSD | €3.49 |
| Hetzner Cloud CX32 | VPS | 4 vCPU, 8 GB RAM, 80 GB SSD | €6.49 |
| DigitalOcean | Droplet | 2 vCPU, 4 GB RAM, 80 GB SSD | $24 |
| OVH | VPS | 2 vCPU, 4 GB RAM, 80 GB SSD | ~€6 |
Fuentes: Hetzner AX41-NVMe, precios de Hetzner Cloud.
El equipo de Altinity calculó que Hetzner es aproximadamente 75x más barato por minuto que los runners hospedados de GitHub Actions. Incluso considerando el overhead de administrar tu propia infraestructura, la economía de cómputo es abrumadora.
Un desarrollador en Hacker News reportó usar un solo AX41-NVMe (~€40/mes) para todo su CI/CD, con cada runner corriendo como una cuenta de usuario separada para aislamiento.
El Costo del Tiempo de Ingeniería: Jenkins
Pero aquí es donde la cuenta se complica. El CI/CD self-hosted “gratis” no es gratis.
El análisis de Buildkite sobre los costos de Jenkins expone el precio oculto:
- Tiempo de mantenimiento: 5-10 horas por semana = 20-40 horas/mes
- Costo anual de ingeniería: $15,000-$30,000 por ingeniero DevOps mid-level
- Riesgo de escalamiento: Son “casi siempre los ingenieros más senior, y más caros” los que terminan resolviendo problemas de Jenkins
- Infierno de plugins: Mantener plugins, resolver conflictos de versiones y atender vulnerabilidades de seguridad
- Fallas en cascada: Una actualización “simple” de Jenkins puede desatar una reacción en cadena que toma horas o un día entero resolver
Según encuestas de la industria, algunas organizaciones terminan asignando 3-4 ingenieros dedicados enteramente a la gestión de Jenkins. A $100K+ por ingeniero, son $300-400K/año para mantener una herramienta “gratuita”.
Alternativas Modernas a Jenkins
Jenkins no es la única opción para CI/CD self-hosted. Varias alternativas modernas ofrecen mejor experiencia de desarrollo con menos carga de mantenimiento:
GitLab CI (self-hosted): CI/CD completo integrado con tu plataforma Git. La Community Edition es gratuita e incluye runners de CI/CD. Más opinionado que Jenkins, lo que significa menos configuración pero también menos flexibilidad.
Woodpecker CI: Un fork comunitario de Drone CI, completamente open source (Apache 2.0). Nativo de contenedores, configuración basada en YAML, y diseñado para ser ligero. Ideal para equipos que quieren una herramienta de CI/CD moderna sin el overhead de Jenkins.
Forgejo Actions: El sistema de CI/CD integrado en Forgejo (un soft fork de Gitea). Compatible con la sintaxis de workflows de GitHub Actions, lo que significa que los workflows existentes pueden reutilizarse con cambios mínimos. Para equipos que quieren compatibilidad self-hosted con GitHub Actions.
Drone CI: CI/CD container-first con un formato de pipeline YAML simple. Ligero, pero el futuro del proyecto ha sido incierto desde que Harness lo adquirió.
El costo de mantenimiento de estas herramientas modernas es significativamente menor que Jenkins — típicamente 2-5 horas por mes en vez de 20-40. Pero aún requieren gestión de infraestructura, parcheo de seguridad, y alguien que sepa cómo mantenerlas corriendo.
La Revuelta por el Cobro de Runners Self-Hosted en GitHub Actions
En diciembre de 2025, GitHub anunció una decisión que provocó uno de los rechazos más grandes de la comunidad de desarrolladores en la memoria reciente.
Lo que Pasó
El 16 de diciembre de 2025, GitHub reveló un nuevo cobro de $0.002 por minuto como “cargo por plataforma cloud” para el uso de runners self-hosted en repositorios privados, efectivo el 1 de marzo de 2026. El cargo cubriría el “plano de control de Actions” de GitHub — orquestación de jobs, scheduling y automatización de workflows.
Las cuentas eran brutales para usuarios intensivos. A 50,000 minutos/mes, son $100. A 100,000 minutos, $200. Un usuario en la discusión de la comunidad de GitHub calculó su impacto:
“Just ran the numbers, and for us, that’s close to $3,500 a month extra on our GitHub bill.”
Su organización usó 1.6 millones de minutos de Actions en noviembre — en su propio hardware.
La Respuesta de la Comunidad
El rechazo fue inmediato y feroz. Dentro del hilo de discusión de GitHub, los desarrolladores expresaron indignación:
“Those minutes are MY processing time, some of which I already pay for on other services. If it takes MY machine 30 minutes to do a build, you’re going to charge me for that when it places no load on YOUR services?”
“The audacity to charge for self-hosted compute.”
El daño de confianza fue más profundo que el precio en sí:
“It’s good that you’re doing damage control after the backlash, but I think for most of us the trust is already broken. Especially since you considered it to be a good thing to introduce the pricing change without even checking with the community.”
La Reversa
Menos de 24 horas después, el 17 de diciembre de 2025, GitHub dio marcha atrás. Pospusieron el cobro indefinidamente, declarando que iban a “tomar tiempo para re-evaluar nuestro enfoque” y reconocieron que “missed the mark with this change by not including more of you in our planning.”
Los recortes de precios de runners hospedados (hasta 39%) entraron en efecto el 1 de enero de 2026. Pero el episodio reveló algo importante: la estrategia a largo plazo de GitHub incluye monetizar la capa de orquestación, incluso para cómputo self-hosted. El cobro fue pospuesto, no cancelado. Los equipos que construyen sobre runners self-hosted de GitHub Actions deberían planificar para que este costo eventualmente llegue.
Varias empresas se movieron rápido para capitalizar la incertidumbre. Blacksmith y Northflank publicaron análisis posicionándose como alternativas.
Seguridad: Los Trade-offs de los que Nadie Habla
El costo no es la única variable. Dónde se construye tu código tiene implicaciones de seguridad reales.
Riesgos de Runners Compartidos
Las plataformas de CI/CD en la nube típicamente ejecutan tus builds en infraestructura compartida. Los runners hospedados de GitHub Actions son VMs efímeras, pero el hardware subyacente es compartido. Esto crea superficie de ataque:
- Ataques de canal lateral: El hardware compartido puede teóricamente filtrar datos entre tenants a través de timing de caché de CPU, ejecución especulativa, o patrones de presión de memoria.
- Envenenamiento de supply chain: Las Actions públicas del marketplace se ejecutan en el contexto de seguridad de tu workflow. Una action comprometida puede exfiltrar secretos, modificar artefactos de build, o inyectar código malicioso.
El Ataque de Supply Chain de tj-actions (Marzo 2025)
En marzo de 2025, la ampliamente usada GitHub Action tj-actions/changed-files fue comprometida (CVE-2025-30066). El ataque modificó la action para volcar secretos de CI/CD — incluyendo claves de AWS, tokens de GitHub y tokens de npm — a los logs del workflow.
El impacto fue masivo: 23,000+ repositorios usaban esta action. Cualquier repositorio que ejecutó la versión comprometida tuvo sus secretos potencialmente expuestos en logs de build públicos.
Este no fue un riesgo teórico. Pasó, afectó credenciales de producción reales, y demostró que el marketplace de GitHub Actions es un vector de ataque de supply chain.
La Brecha de Seguridad de CircleCI (Enero 2023)
En enero de 2023, CircleCI divulgó un incidente de seguridad mayor. Malware en el laptop de un empleado robó una cookie de sesión, dando a los atacantes acceso a los sistemas internos de CircleCI del 16 al 22 de diciembre de 2022. El resultado:
- Todos los clientes tuvieron que rotar todos los secretos almacenados en CircleCI
- Variables de entorno de producción, claves de API y credenciales de deployment fueron potencialmente comprometidas
- Tokens de OAuth de terceros tuvieron que ser revocados y reemitidos
La reseña de un cliente capturó el impacto:
“We were a bit startled because of the security issue they faced and we had to renew all of the secrets which was painful.”
Este es el riesgo inherente del CI/CD centralizado: cuando el proveedor es comprometido, todos los clientes se ven afectados simultáneamente.
Seguridad Self-Hosted: Riesgos Diferentes
El CI/CD self-hosted elimina los riesgos de infraestructura compartida pero introduce otros:
- Tú eres responsable del parcheo: Cada CVE en tu software de CI/CD, sus dependencias y el OS subyacente es tu problema
- Aislamiento de red: Tus runners de CI necesitan acceso a tus repositorios de código, registros de artefactos y targets de deployment. Reglas de red mal configuradas pueden exponer sistemas internos
- Gestión de secretos: Necesitas implementar tu propia inyección de secretos (HashiCorp Vault, AWS Secrets Manager, etc.) en vez de depender del almacén de secretos integrado de la plataforma
El trade-off es claro: el CI/CD en la nube intercambia control por conveniencia, y cuando la capa de conveniencia falla, no tienes recurso excepto rotar todo.
El Punto Medio Híbrido
Para muchos equipos, la respuesta no es nube pura ni self-hosted puro — es una combinación.
Runners Self-Hosted en GitHub Actions
GitHub Actions soporta runners self-hosted que se conectan a la capa de orquestación de GitHub. Obtienes la sintaxis de workflow, las integraciones del marketplace, y la experiencia nativa de GitHub mientras ejecutas builds en tu propio hardware.
Para entornos de Kubernetes, Actions Runner Controller (ARC) escala automáticamente pods de runners basado en la demanda de workflows. También existen varias herramientas específicamente para Hetzner Cloud:
- TestFlows GitHub Hetzner Runners: Runners self-hosted con auto-escalamiento en Hetzner Cloud
- hcloud-github-runner: Runners on-demand que levantan VMs de Hetzner por ejecución de workflow
El costo actual: $0/mes por la orquestación (el cobro pospuesto de $0.002/min no ha entrado en efecto). Solo pagas por tu infraestructura de cómputo.
Buildkite: El Modelo Híbrido Por Asiento
Buildkite fue pionero del modelo híbrido: orquestación basada en la nube con un agente open source que ejecutas en tu propia infraestructura. El modelo de precios es por asiento, no por minuto:
- Plan gratuito: funciones limitadas
- Pro: $15/usuario/mes
- Enterprise: $35/usuario/mes
Para un equipo de 10, son $150/mes sin importar cuántos builds ejecutes. Compara eso con GitHub Actions, donde el mismo equipo ejecutando 50,000 minutos/mes pagaría $300+ solo en cómputo.
El agente open source de Buildkite mantiene tu código y secretos en tu propia infraestructura — el componente cloud solo maneja la orquestación, scheduling y el dashboard. Esto aborda tanto las preocupaciones de costo como de seguridad de las plataformas completamente administradas.
GitLab SaaS con Runners Self-Managed
La oferta SaaS de GitLab permite conectar runners self-managed mientras usas la plataforma hospedada de GitLab. Esto permite a los equipos en los tiers Premium ($29/usuario/mes) o Ultimate ($99/usuario/mes) ejecutar builds en su propia infraestructura sin consumir sus minutos de cómputo incluidos.
Los minutos incluidos son generosos — 10,000 para Premium, 50,000 para Ultimate — y los minutos adicionales cuestan $0.01/min (comprados en bloques de 1,000 minutos a $10). Para equipos que ocasionalmente exceden su asignación, los runners self-managed manejan el overflow sin cargos excedentes.
Vendor Lock-in: El Infierno del YAML y el Mito de la Portabilidad
Toda plataforma de CI/CD usa YAML para configuración de pipelines. Ninguna usa el mismo YAML.
El Problema de Portabilidad
Moverse entre plataformas significa reescribir cada pipeline:
| Característica | GitHub Actions | GitLab CI | CircleCI | Azure DevOps |
|---|---|---|---|---|
| Archivo de config | .github/workflows/*.yml | .gitlab-ci.yml | .circleci/config.yml | azure-pipelines.yml |
| Sintaxis de jobs | jobs.<id>.steps | stages + jobs | jobs.<id>.steps | stages + jobs |
| Secretos | ${{ secrets.X }} | $X (CI variables) | Variables de entorno | $(X) |
| Caching | actions/cache@v4 | cache: keyword | restore_cache/save_cache | Cache@2 task |
| Matrix builds | strategy.matrix | parallel:matrix | matrix: bajo parameters | strategy.matrix |
| Workflows reutilizables | uses: ./.github/workflows/x.yml | include: | Orbs | Templates |
Un equipo con 50 archivos de workflow enfrenta semanas de trabajo de migración para moverse entre plataformas. Esto crea lock-in efectivo incluso cuando no hay barrera técnica para irse.
Las Alternativas Emergentes
Varias herramientas están intentando resolver el problema de portabilidad:
Dagger: Fundado por Solomon Hykes (creador de Docker) y respaldado por una Serie A de $20 millones, Dagger te permite definir pipelines de CI/CD en tu lenguaje de programación (Go, Python, TypeScript) en vez de YAML. Los pipelines corren como contenedores, así que funcionan idénticamente en cualquier plataforma de CI. En 2025, Dagger lanzó Dagger Cloud (gratis para individuos), obtuvo certificación SOC2 e introdujo Dagger Shell para facilitar la adopción.
Depot: Un servicio especializado que ofrece builds de Docker hasta 40x más rápidos comparado con proveedores de CI genéricos, con 16 CPUs, 32 GB RAM y 50 GB de caché NVMe persistente por defecto. No es un reemplazo completo de CI/CD, pero es un sustituto drop-in para docker build que puede recortar dramáticamente los costos de build de contenedores. En 2025, expandieron a cachear builds de Bazel, Go, Gradle y Turborepo.
Earthly (⚠️ ya no se mantiene activamente desde 2025): Combinaba conceptos de Makefile y Dockerfile para builds basados en contenedores. Aunque innovador, su estado de mantenimiento lo hace inadecuado para nueva adopción.
El enfoque más viable comparte una filosofía: desacoplar la definición del pipeline de la plataforma de CI. Tu lógica de build vive en código, y la plataforma de CI se reduce a una capa delgada de trigger.
Para equipos preocupados por el lock-in, Dagger es la dirección más prometedora. Un pipeline de Dagger puede correr en GitHub Actions hoy y moverse a Buildkite mañana sin reescribir la lógica de build — solo cambia la configuración del trigger.
Framework de Decisión: Cuándo Usar Qué
Elige CI/CD completamente administrado si…
- ✅ Tu equipo es pequeño (< 10 desarrolladores) y el volumen de builds está bajo 10,000 minutos/mes
- ✅ No tienes capacidad dedicada de DevOps/platform engineering
- ✅ Necesitas builds de macOS/Windows y no quieres mantener hardware especializado
- ✅ Tus builds son infrecuentes o con picos — pagar por minuto tiene sentido cuando la utilización es baja
- ✅ Valoras cero mantenimiento sobre la optimización de costos
Elige CI/CD self-hosted si…
- ✅ Tu volumen de builds excede 50,000 minutos/mes consistentemente
- ✅ Tienes ingenieros DevOps dedicados que pueden mantener infraestructura
- ✅ Necesitas entornos de build aislados o restringidos por compliance
- ✅ Tus builds requieren hardware especializado (GPUs, ARM, máquinas de alta memoria)
- ✅ Te sientes cómodo con herramientas modernas (Woodpecker CI, Forgejo Actions, GitLab CI) que reducen el overhead de mantenimiento de la era Jenkins
Elige híbrido si…
- ✅ Quieres sintaxis de workflows de GitHub/GitLab pero necesitas controlar costos a escala
- ✅ Necesitas aislamiento de seguridad — tu código y secretos nunca salen de tu infraestructura
- ✅ Tienes workloads mixtos — algunos builds necesitan runners administrados de macOS, otros corren bien en VPS Linux baratos
- ✅ Tu equipo está creciendo y quieres un modelo que escale linealmente (por asiento) en vez de exponencialmente (por minuto)
- ✅ Quieres protegerte contra cambios de precios de la plataforma (como el cobro de runners self-hosted de GitHub)
Evita estos errores…
- ❌ Elegir Jenkins porque es “gratis” — el costo de tiempo de ingeniería supera cualquier factura de CI/CD administrado para equipos menores de 50 desarrolladores
- ❌ Ignorar costos ocultos en AWS CodeBuild — presupuesta para CloudWatch, NAT Gateway, S3 y ECR, no solo minutos de build
- ❌ Usar runners hospedados de macOS para builds iOS de alto volumen — haz self-host con Mac Minis o usa un proveedor especializado
- ❌ Elegir una plataforma por la generosidad del free tier — vas a superar el free tier, y la tarifa pagada importa más
- ❌ Asumir portabilidad de YAML — el YAML de cada plataforma es diferente, y los costos de migración son reales
Escenarios de Costo: Números Reales para Equipos Reales
Escenario 1: Startup (5 desarrolladores, builds ligeros)
Perfil: 5 devs, 3 pushes/día cada uno, builds de 4 minutos promedio, 20 días laborales/mes = 1,200 minutos/mes.
| Opción | Costo Mensual |
|---|---|
| GitHub Actions (Linux) | ~$0 (dentro de 2,000 minutos gratis) |
| Google Cloud Build | ~$0 (dentro de 2,500 minutos gratis) |
| GitLab Free | ~$0 (dentro de 2,000 minutos totales para 5 usuarios) |
| Hetzner VPS (CX22) + Woodpecker CI | €3.49 (~$3.80) |
Veredicto: Usa el free tier de cualquier proveedor cloud. Self-hosting no tiene sentido a esta escala.
Escenario 2: Equipo mediano (15 desarrolladores, builds moderados)
Perfil: 15 devs, 3 pushes/día, builds de 8 minutos, 20 días laborales = 7,200 minutos/mes. Más 2,000 minutos/mes de builds macOS para mobile.
| Opción | Costo Mensual |
|---|---|
| GitHub Actions (Linux + macOS) | $31.20 (Linux) + $124 (macOS) = $155.20 |
| Google Cloud Build (solo Linux) + GitHub macOS | $14.10 + $124 = $138.10 |
| Hetzner AX41 (Linux) + GitHub macOS | €40 + $124 = ~$167 |
| Hetzner AX41 (Linux) + Mac Mini (macOS self-hosted) | €40 + |
| Buildkite (15 usuarios) + Hetzner AX41 | $225 + €40 = ~$268 |
Veredicto: La nube es competitiva para builds Linux a este volumen. Los builds macOS impulsan el costo total. Self-hosting Mac Minis ahorra dinero si estás dispuesto a administrarlos.
Escenario 3: Equipo a escala (50 desarrolladores, builds pesados)
Perfil: 50 devs, 4 pushes/día, builds de 10 minutos, 22 días laborales = 44,000 minutos/mes Linux + 10,000 minutos macOS + 5,000 minutos Windows.
| Opción | Costo Mensual |
|---|---|
| GitHub Actions (todas las plataformas) | $264 + $620 + $50 = $934 |
| AWS CodeBuild (con costos ocultos ~3x) | |
| Hetzner dedicado × 3 + Mac Minis × 2 | €120 + |
| Buildkite (50 usuarios) + self-hosted | $750 + |
Veredicto: A esta escala, self-hosted ahorra miles por año. El modelo híbrido de Buildkite mantiene la experiencia de desarrollador premium mientras recorta costos de cómputo. El CI/CD puramente cloud se convierte en la opción más cara.
Checklist de Pre-Migración
Antes de cambiar tu setup de CI/CD, responde estas preguntas:
1. ¿Cuál es tu volumen real de builds?
Revisa el dashboard de uso de tu plataforma actual. Calcula minutos totales por mes desglosados por OS (Linux/macOS/Windows). Multiplica por la tarifa por minuto de tu plataforma objetivo, incluyendo costos excedentes.
2. ¿Cuáles son tus costos ocultos?
Para AWS: audita los cargos de CloudWatch Logs, almacenamiento de artefactos en S3, NAT Gateway y pulls de imágenes de ECR. Para GitHub Actions: verifica el impacto del redondeo de minutos en jobs cortos. Para CircleCI: calcula el consumo de créditos de Docker Layer Caching.
3. ¿Quién mantiene tu CI/CD hoy?
Si la respuesta es “nadie, simplemente funciona,” es un servicio administrado ganándose su dinero. Si es “nuestro ingeniero más senior pasa 10+ horas/mes en ello,” ese es un costo que deberías cuantificar.
4. ¿Cuáles son tus requisitos de seguridad?
Si manejas PII, datos financieros, u operas bajo frameworks de compliance (SOC 2, HIPAA, PCI DSS), evalúa si los runners compartidos en la nube cumplen tus requisitos de auditoría. Self-hosted o híbrido puede ser mandatorio.
5. ¿Qué tan portables son tus pipelines?
Cuenta tus archivos de workflow. Estima el esfuerzo de reescribirlos para una plataforma diferente. Considera Dagger o Earthly si la portabilidad es una prioridad.
6. ¿Cuál es tu trayectoria de crecimiento?
Los precios por minuto escalan linealmente con el headcount y la frecuencia de push. Si vas a duplicar el tamaño del equipo en 12 meses, modela el costo a esa escala, no la de hoy.
7. ¿Puedes configurar alertas de costo antes de migrar?
En AWS, usa AWS Budgets. En GitHub, monitorea tu dashboard de facturación. En Google Cloud, configura alertas de presupuesto. Haz esto antes de que corra el primer build, no después de la primera factura sorpresa.
Conclusiones Clave
-
Los precios del CI/CD en la nube son engañosamente simples. La tarifa por minuto es solo la punta del iceberg. NAT Gateways, CloudWatch Logs, Docker Layer Caching, redondeo de minutos y multiplicadores de precio regionales pueden multiplicar 3-15x tu costo aparente.
-
El CI/CD self-hosted es engañosamente barato. Un servidor Hetzner de €40/mes es 75x más barato por minuto que GitHub Actions. Pero el mantenimiento de Jenkins cuesta $15-30K/año en tiempo de ingeniería. Herramientas modernas como Woodpecker CI y Forgejo Actions reducen esto drásticamente.
-
El modelo híbrido es el secreto mejor guardado. Los precios por asiento de Buildkite ($15/usuario/mes) con agentes self-hosted, o GitHub Actions con runners self-hosted, te dan orquestación de workflows administrada con la economía de cómputo self-hosted.
-
Los builds de macOS son el asesino del presupuesto. A $0.062/minuto en GitHub Actions, los builds de iOS/macOS pueden costar $4,000+/mes a escala moderada. Self-hosting con Mac Minis es casi siempre más barato para workloads consistentes.
-
El cobro de runners self-hosted de GitHub está pospuesto, no cancelado. El episodio de diciembre 2025 mostró que GitHub tiene la intención de monetizar la orquestación. Planifica para que este costo eventualmente llegue.
-
La seguridad no es solo un checkbox. El ataque de supply chain de tj-actions (23,000+ repos afectados) y la brecha de CircleCI en 2023 (todos los clientes forzados a rotar secretos) demuestran que el CI/CD en la nube es una superficie de ataque significativa. Self-hosted elimina el riesgo de infraestructura compartida pero agrega responsabilidad de parcheo.
-
El vendor lock-in es real pero solucionable. El YAML de cada plataforma es diferente, pero herramientas como Dagger desacoplan la lógica de build de la plataforma de CI, haciendo factibles las migraciones futuras. Earthly fue pionero en este espacio pero ya no se mantiene — Dagger, respaldado por el creador de Docker, es el líder actual.
El setup correcto de CI/CD no se trata de encontrar la opción más barata — se trata de entender el costo total de propiedad, incluyendo los costos que no aparecen en ninguna página de precios.