GitHub Actions vs GitLab CI vs Drone: qué CI/CD elegir para startup

La elección de CI/CD en 2026 ya no es sobre "qué herramienta tiene más features". Las tres serias — GitHub Actions, GitLab CI, Drone (y su fork Woodpecker) — hacen lo básico bien. La elección real es sobre dónde tu dolor va a aparecer primero: en la factura a fin de mes, en la complejidad del workflow cuando el monorepo crezca, o a la hora de subir un runner que nadie entiende cuando el dev senior se va de vacaciones.

Este post es una comparación honesta para tech leads decidiendo CI/CD en 2026. Sin ranking artificial, sin columna en la que una herramienta sea "campeona" en todo. Tradeoffs explícitos, números en euros, y una recomendación por perfil al final.

TL;DR (200 palabras)

La decisión de CI/CD en 2026 sigue cuatro fuerzas: dónde está hospedado el código, coste de minutos, complejidad de workflow y disposición a operar self-hosted.

GitHub Actions ganó mindshare absoluto para proyectos en GitHub. Es gratis hasta 2000 minutos/mes en repos públicos; después cuesta US$0,008/min en runner Linux — entre US$5 y US$30/mes para startup típica (5 € a 30 €). Marketplace tiene 10 mil acciones listas. El talón es el pricing de minutos cuando el volumen crece.

GitLab CI es más completo: grafo de dependencias entre jobs nativo, parent-child pipelines, monorepo handling mejor, registry de imágenes incluido, scanning de seguridad embebido. Self-hosted (Community Edition) es gratuito pero exige 4 a 8 GB de RAM y operación activa. SaaS Premium es US$29/usuario/mes — caro para equipo grande.

Drone/Woodpecker auto-hospedado es la opción para reducir coste a cero variable. Un servidor de 5 € a 15 €/mes corre CI para cinco a diez proyectos. Cuesta en ops: tú operas los runners.

Para startup ES pequeña en GitHub, empieza en el plan gratuito de Actions. Cuando pase de US$30/mes, considera Woodpecker self-hosted. Para empresa que valora CI + issue tracker + registry en un producto solo, GitLab self-hosted.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

¿Por qué esa decisión importa más de lo que parece?

CI/CD es la infraestructura más usada de cualquier equipo de producto: cada commit toca el sistema, cada PR depende de él, cada deploy pasa por él. Una elección equivocada no te rompe en el primer mes — te rompe en el tercer año, cuando migrar cuesta cuatro semanas de dos personas y pagas eso mientras el roadmap queda parado.

Los tres síntomas que indican que la elección fue equivocada:

1. La factura crece más rápido que el equipo. Si el coste de CI se duplica cada seis meses sin que el volumen de deploys lo justifique, el pricing model no es el tuyo.
2. Los workflows se vuelven copy-paste. Si cada nuevo proyecto empieza con cp -r .github/workflows/, la herramienta no tiene composición decente.
3. Fallos en CI tardan más de una hora en debuguearse. Si reproducir el error local exige correr una imagen Docker que nadie sabe montar, el build no es portable.

Los tres competidores principales resuelven esos síntomas de formas diferentes. Vamos por partes.

GitHub Actions: el estándar de facto — ¿vale el precio?

Si tu código está en GitHub, Actions tiene una ventaja estructural que no se puede ignorar: cero fricción de integración. Creas .github/workflows/ci.yml, haces push, y está corriendo. Sin registro separado, sin token cruzado, sin webhook que configurar.

Lo que Actions hace bien

• Marketplace gigante. Más de diez mil acciones listas para tareas comunes: setup de Node, Python, Go; deploy a AWS, GCP, Azure; firma de imágenes; scanning de seguridad. La mayoría es mantenida por el propio proveedor de la tecnología (HashiCorp publica la suya, AWS publica la suya, etc).
• Matrix builds. Correr la misma suite contra cinco versiones de Node o tres sistemas operativos es una clave en tres líneas.
• Reusable workflows. Desde 2021 puedes extraer workflows compartidos entre repos de la misma organización — soluciona el problema de "copy-paste entre proyectos" para equipos medianos.
• Deployment protection rules. Approvals manuales, ventanas de horario, restricción por branch — todo configurable sin plugin.
• Self-hosted runners. Puedes correr el agente en tu propia infra y usar la UI de Actions solo como orquestador. Resuelve el problema de minutos para equipos con volumen alto.

Lo que Actions cobra caro

El modelo de cobro es por minuto, y los números importan:

Para una startup en GitHub con cinco devs y workflow razonable (build + test + lint en cada PR), el consumo típico es 800 a 2500 minutos/mes en Linux. Eso da US$6 a US$20/mes — o sea, entre 5 € y 18 €. Cabe en la línea de "herramientas de dev" sin dolor.

Cuando duele: workflows pesados (E2E con Playwright, builds Rust, tests que suben Postgres + Redis en cada job) fácilmente pasan de 10 mil minutos/mes. A US$0,008/min eso se vuelve US$80/mes — 70 €. Multiplica por 12 y estás pagando 850 €/año en CI.

Builds macOS son el peor caso: US$0,40/min es diez veces más que Linux. Equipos que mantienen apps iOS gastan tres a cuatro veces más en CI que en infra de producción.

¿Self-hosted runners de Actions resuelven?

Parcialmente. Corres el binario del runner en una máquina tuya, lo registras en el repo o en la organización, y los jobs van ahí en lugar del pool gestionado. Coste de minuto va a cero — pagas solo la máquina.

Pero tres trampas:

1. Mantenimiento del runner. La versión actualiza con frecuencia; runners desactualizados empiezan a fallar silenciosamente. Sin automatización, se vuelve tarea de operación manual.
2. Scaling manual. Si el equipo tiene cinco devs abriendo 20 PRs simultáneos, un runner serializa todo. Necesitas N runners — y provisionar/desprovisionar conforme demanda exige tooling adicional.
3. Seguridad en repos públicos. Self-hosted runners en repo público son una puerta abierta para que cualquier fork malicioso corra código arbitrario en tu máquina. Siempre restrito a repos privados u organización confiable.

La solución madura es Actions Runner Controller (ARC): un operador que sube runners on-demand en un cluster Kubernetes o similar. Resuelve scaling, pero añade una capa entera de infraestructura — no es trivial.

GitLab CI: el competidor "pesado" ¿aún tiene sentido?

GitLab CI es más antiguo que Actions, más completo en features, y menos popular fuera de los equipos que ya están en la plataforma GitLab. La pregunta correcta no es "¿GitLab CI es mejor que Actions?", es "¿vale la pena migrar a GitLab para usar GitLab CI?"

Lo que GitLab CI hace mejor

• Grafo de dependencias (DAG). Nativo, sin tooling externo. Declaras needs: [job_a, job_b] y los jobs corren en paralelo respetando dependencias. Para workflows con 30+ jobs (monorepo grande, varios lenguajes, deploy multi-entorno), eso es la diferencia entre 8 minutos y 25 minutos por pipeline.
• Parent-child pipelines. Pipeline grande puede disparar pipelines hijos con lógica condicional — útil para monorepo donde solo servicios alterados necesitan buildar.
• Registry de imágenes incluido. Cada proyecto viene con un registry de container privado nativo. Sin configurar secretos para Amazon ECR, Docker Hub o similar.
• Pages, security scanning, code quality, dependency scanning — todo embebido en la plataforma. En Actions cada uno es una acción separada del marketplace.
• Merge request integration profundo. Pipelines aparecen dentro del MR con diff de cobertura, comparación de bundle size, comparación de tiempo de build. En Actions los checks aparecen como links — en GitLab son datos estructurados.

Donde GitLab CI cobra caro

Dos dimensiones.

Pricing SaaS:

Para equipo de cinco devs en Premium, son US$145/mes — 130 €. Ese es solo el ticket de entrada; minutos extra cuestan aparte. Para equipo de 20, US$580/mes = 520 € solo en suscripción.

Self-hosted Community Edition es gratuito y elimina ese coste de licencia — pero:

• Mínimo realista: 4 vCPU, 8 GB RAM (16 GB si vas a usar registry + pages + scanning).
• VPS adecuado: 20 € a 45 €/mes.
• Ops: 2 a 4 horas/mes en actualización, backup, monitoreo.
• Actualizaciones mensuales. GitLab tiene cadencia rígida; quedarse tres versiones atrás abre brechas de seguridad documentadas.

En producción real, self-hosted GitLab da menos trabajo que Kubernetes pero más que Actions SaaS. Es un servidor real que tú operas.

Drone CI y Woodpecker: la alternativa minimalista

Drone CI nació en 2014 como el "CI nativo de container": cada step del pipeline es un container, sin magia. En 2020 la empresa detrás (Drone Inc.) fue adquirida por Harness, y el producto ganó una versión Cloud comercial. El fork comunitario Woodpecker continúa 100% open-source, con API compatible con Drone.

Lo que Drone/Woodpecker hacen bien

• YAML simple. Cada step declara una imagen y un comando. Sin DSL, sin actions reutilizables con semántica propia. Lo que ejecutas localmente con docker run es lo que ejecuta en CI.
• Container-native. No hay "executor" Java, no hay agente Python ejecutando steps. Cada step es un container aislado. Reproducir el error localmente es literal: copia el image: y los commands: del YAML y lo corres en el terminal.
• Self-hosted desde el día uno. No hay "Drone Cloud gratis" pulling features hacia la versión paga. El servidor + los runners son el producto entero.
• Plugins vía container. Cada plugin (deploy SSH, Slack, Docker push, AWS) es una imagen publicada. Versionado igual a cualquier otra dependencia.
• Soporta múltiples hosts de código. GitHub, GitLab, Bitbucket, Gitea, Forgejo — todo en el mismo servidor de Drone.

Donde Drone/Woodpecker cobran

• Comunidad menor. Cuando golpeas en un bug oscuro, Stack Overflow tiene cinco respuestas, no cincuenta. Github issues son tu fuente principal.
• Operación no trivial en escala. Un servidor + un runner es fácil. Cinco runners autoescalando detrás de una cola es tooling que tú montas — auto-scaling no es built-in.
• Drone Cloud es pago. Si quieres SaaS, vas a Harness; el tier gratis es limitado. Por eso la recomendación es siempre self-hosted.
• Documentación modesta. Cubre el camino feliz; casos de borde los descubres leyendo código.

Por qué Woodpecker en lugar de Drone en 2026

Drone vanilla aún funciona, pero Harness ha priorizado la versión cloud comercial. Woodpecker es el fork comunitario del Drone original — 100% open-source, sin versión paga jalando features, releases mensuales activas, comunidad comprometida. API y YAML compatibles con Drone, así que la migración es trivial: cambias la URL del servidor.

Para cualquier equipo pequeño auto-hospedando en 2026, Woodpecker es la elección mejor que Drone vanilla. Misma arquitectura, sin el overhead de una empresa controlando el roadmap.

¿Cuál es más barata en 2026?

Coste total mensual real, considerando equipo de cinco devs con volumen medio (300 builds/mes, builds de 8 minutos medios en Linux):

Ganador absoluto en coste: Woodpecker self-hosted para equipo dispuesto a operar una VPS. Cuesta lo mismo que un almuerzo al mes y corre CI para diez proyectos sin sentir.

Si ops no está disponible, Actions plan gratuito es la siguiente opción. Cabe en un equipo pequeño con workflows ligeros; cuando pasa de US$30/mes variable, vale la pena al menos evaluar runners self-hosted.

¿Cuál tiene mejor experiencia de desarrollador?

DX en CI/CD se mide en tres dimensiones: tiempo del "yml en blanco" hasta el "primer build pasando", capacidad de debug cuando sale mal, y capacidad de evolucionar el workflow cuando crece.

No hay ganador absoluto. Para equipo que valora empezar rápido, Actions. Para equipo que tiene workflow complejo desde el día uno (monorepo, varios lenguajes), GitLab CI. Para equipo que quiere entender exactamente lo que está sucediendo, Drone/Woodpecker.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Tabla comparativa: 12 criterios honestos

Ningún competidor tiene columna sin reservas. La herramienta correcta depende del perfil del equipo.

Decisión por perfil de equipo

Cuatro recomendaciones concretas, sin "depende".

Indie hacker o repo público en GitHub

Usa GitHub Actions plan gratuito. Repos públicos tienen minutos ilimitados. No tienes motivo para buscar alternativa. Si dentro de un año el proyecto crece, reevalúas.

Startup early en GitHub, repos privados, 10 mil a 50 mil € MRR

Continúa en Actions plan gratuito. El free tier de 2000 minutos cabe en un equipo de dos a tres devs con workflows razonables. Cuando empiece a pasar de eso, primero reduce desperdicio (paths filter para no correr todo en todo PR, cache de dependencias decente) antes de migrar.

Si pasa consistentemente de US$30/mes variable, considera migrar a runners self-hosted o Woodpecker en paralelo.

Startup con 50 mil a 200 mil € MRR en GitHub, volumen CI alto

Híbrido. Usa Actions para workflows ligeros (lint, tests unitarios) y self-hosted runners (vía ARC) o Woodpecker para workflows pesados (E2E, builds largos, deploys). Pagas por minuto donde compensa y cero donde duele.

Para equipos con builds macOS regulares, considera una máquina Mac mini dedicada como self-hosted runner. Inversión de 1.000 € paga en tres meses si gastas US$200/mes en macOS Actions hoy.

Empresa ES en GitLab self-hosted

Usa GitLab CI nativo. Ya estás pagando el coste de operar GitLab; CI viene junto sin coste adicional. Migrar a otra herramienta significaría operar dos sistemas en paralelo — no vale.

Equipo pequeño controlando coste agresivamente

Woodpecker self-hosted en VPS 15 €. Corre CI para diez proyectos sin sudar. Cuesta en ops 1 a 2 horas/mes. Si el equipo tiene alguien con afinidad por herramientas Unix, es la opción más económica y más previsible en cuenta — sabes exactamente el coste cada mes.

Donde HeroCtl entra como infraestructura para runners

Self-hosted CI/CD es exactamente el tipo de carga de trabajo que HeroCtl orquesta bien: servicios largos (servidor de CI, base que mantiene historial de builds), servicios que escalan horizontalmente (runners que suben y bajan con la cola), servicios con necesidad de persistencia (cache de artefactos).

En lugar de operar Docker Compose en un servidor único — single point of failure — describes el setup como una configuración de jobs:

• Servidor de Drone/Woodpecker como job largo, con réplica única y volumen persistente para la base de historial.
• N runners como job replicable, escalando horizontalmente. El orquestador distribuye los runners entre nodos; si un servidor muere, los runners migran a los otros.
• Backup integrado para el estado del CI (base del servidor + cache de artefactos), sin montar tooling externo.
• Métricas y logs integrados — ves uso de CPU, memoria, tiempo de build sin subir un stack de observabilidad separado.

La diferencia práctica: en lugar de operar un stack de CI en paralelo a tu cluster de producción, se vuelve parte del mismo cluster, con las mismas garantías de alta disponibilidad. Si un servidor se cae, los runners migran. Si quieres duplicar capacidad para una sprint pesada, es cambiar replicas: 4 a replicas: 8 en el archivo de configuración.

Para quien está en la frontera "empiezo simple pero voy a crecer", eso resuelve la transición sin necesitar cambiar de herramienta a mitad de camino.

Los 4 errores caros en CI/CD self-hosted (y cómo evitarlos)

Error 1: cache stale silencioso

El síntoma: build pasa local, falla en CI por una dependencia que existe en la máquina del dev pero no en la imagen fresca. Peor caso: pasa en CI también porque cache anterior contiene la dependencia, pero falla en producción cuando la imagen es construida sin cache.

La corrección: cache decente asume que puede ser invalidado en cualquier momento. Siempre que cambies archivos de manifiesto de dependencias (package.json, go.mod, requirements.txt, Cargo.toml), inclúyelos en la clave de cache. Periódicamente (semanal), forzar build sin cache para detectar drift.

Error 2: secret commiteado por accidente

El síntoma: alguien pegó un token en la configuración de CI "solo para probar", commiteó, olvidó. El repo es público; en 12 horas el token está en uso por quien no debía.

La corrección: dos mecanismos en capas. Pre-commit hook que escanea patrones de claves comunes (AWS, Stripe, GitHub PAT). Rotación automática de tokens críticos (90 días máximo). Si un token se filtra, la ventana de exposición es finita.

En GitLab CI, usa variables con flag "masked" y "protected". En Actions, usa environment-scoped secrets con approval rules. En Drone/Woodpecker, secretos son escopados por repo y nunca aparecen en logs por defecto.

Error 3: runner corriendo en el mismo servidor de producción

El síntoma: build pesado consume CPU/RAM, producción se vuelve lenta, latencia sube, alarma dispara, on-call despierta. Caso real común en equipos pequeños que intentan ahorrar máquina.

La corrección: runners en servidor separado de producción, siempre. Si el presupuesto aprieta, runner en VPS de 5 €/mes aún es más barato que un incidente de producción en horario comercial.

Error 4: workflow que no corre fuera de CI

El síntoma: el build de CI es un script de 200 líneas inline en el YAML, con 15 variables de entorno que el sistema inyecta. Cuando algo sale mal, nadie logra reproducir local sin hacer ingeniería inversa del YAML.

La corrección: el CI debe llamar comandos que existen como Makefile, script/build, o package.json scripts. El YAML del CI orquesta; la lógica vive en scripts versionados que corren en cualquier terminal. Si no logras correr make ci localmente y ver el mismo resultado, tu CI no es portable.

Drone/Woodpecker fuerza esa disciplina por diseño (cada step es un container). Actions y GitLab CI permiten el anti-patrón; cabe al equipo evitar.

Preguntas frecuentes

¿GitHub Actions es más rápido que Drone?

En build crudo, depende del runner: el pool gestionado de Actions usa máquinas de 2 vCPU; un runner self-hosted en una máquina de 4 vCPU es más rápido. En tiempo total de pipeline (incluyendo cola), Actions gana cuando hay volumen — tienen capacidad ociosa enorme. Self-hosted (cualquier herramienta) tiene cola proporcional al número de runners que provisionas.

¿Puedo usar GitLab CI con repo en GitHub?

Técnicamente sí, vía "pull mirror" (GitLab espeja el GitHub y corre CI en él). En la práctica es frágil: webhooks atrasan, status checks no vuelven al GitHub de la forma que el equipo espera, MRs quedan confusos. No vale la pena. Si estás en GitHub, usa Actions o Drone/Woodpecker (que aceptan GitHub como fuente nativa).

¿Self-hosted runners de GitHub Actions valen la pena?

Para repos privados con volumen alto (más de 5000 minutos/mes), sí. Ahorras minutos pagados a cambio de operar máquinas. Para repos públicos, no — riesgo de seguridad (forks maliciosos corriendo código en tu máquina) supera el beneficio. ARC (Actions Runner Controller) ayuda en escala, pero añade una capa de Kubernetes; solo tiene sentido para equipos que ya operan K8s.

¿Woodpecker es estable lo suficiente en 2026?

Sí. Releases mensuales, base de código sólida (forkado de Drone, que tenía cinco años de producción), comunidad activa. En producción en cientos de empresas pequeñas y medianas. No es la apuesta segura "nadie es despedido por elegir" — esa es Actions o GitLab — pero en tres años de fork no hubo incidente comunitario grave. Para equipo pequeño self-hosted, es la elección sensata.

¿ArgoCD y FluxCD entran en esa decisión?

No directamente. ArgoCD/FluxCD son herramientas de GitOps para Kubernetes, no CI. Asisten un repo Git y aplican cambios en cluster. CI sigue siendo Actions/GitLab/Drone generando imágenes; ArgoCD/Flux aplican el deploy. Si no estás en Kubernetes, ArgoCD/Flux no son para ti. Equipos en otros orquestadores hacen deploy directo desde el CI o vía APIs del orquestador.

¿Cuántos runners simultáneos para equipo de 5 devs?

Regla práctica: un runner por dos desarrolladores activos, más un runner extra para builds largos no bloquear PRs rápidos. Equipo de cinco devs: tres runners es cómodo. En horas pico (release day), sube a cinco temporalmente. Cada runner consume 1 a 2 GB de RAM en workload típica; un servidor de 8 GB corre cuatro runners sin dolor.

Cache de dependencias — ¿qué herramienta lidia mejor?

GitLab CI tiene cache nativo por clave/path, integrado al registry propio. GitHub Actions tiene actions/cache (gratuito, 10 GB por repo). Drone/Woodpecker dependen de plugin de cache externo (S3, MinIO local) — más setup pero más flexible. En volumen moderado, todos resuelven; en volumen alto (monorepo grande), GitLab tiene ventaja por integración con el registry.

Migrar de GitHub Actions a Drone — ¿cuánto trabajo?

Para workflows simples (build + test + push), 1 a 2 días. Para workflows que dependen de muchas acciones del marketplace, 1 a 2 semanas (necesita reescribir cada acción como container). El mayor dolor son secretos y entornos — exporta y reimporta con cuidado. Recomendación: haz migración proyecto a proyecto, no todo de una vez.

¿Puedo correr runners de Actions y Drone/Woodpecker en el mismo servidor?

Técnicamente sí, ambos son containers. En la práctica, aislamiento mejora: runners en servidores separados evitan que un build pesado afecte al otro. Si el presupuesto es ajustado, dos servidores de 7 €/mes son mejores que uno de 15 €/mes con todo junto.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

En resumen

CI/CD en 2026 no tiene herramienta ganadora. Tiene perfiles de uso y tradeoffs honestos:

• ¿Estás en GitHub y el volumen es ligero a medio? Actions, plan gratuito. No busques problema donde no hay.
• ¿Estás en GitLab self-hosted? GitLab CI nativo. Ya está pagado.
• ¿Quieres coste previsible y tienes 1-2h/mes de ops disponible? Woodpecker self-hosted en VPS 15 €. La elección más económica.
• ¿Tienes monorepo grande con workflow complejo? GitLab CI (DAG nativo) o Actions con reusable workflows.
• ¿Tienes volumen alto y dolor de pricing de minutos? Híbrido: Actions para workflows ligeros, runners self-hosted para pesados.

Si estás pensando en correr la herramienta de CI como parte del mismo cluster que sirve producción — con alta disponibilidad real, métricas integradas y backup sin montar stack aparte — instala HeroCtl en un servidor:

curl -sSL https://get.heroctl.com/install.sh | sh

A partir de ahí, describir un servidor de Woodpecker con tres runners autoescalables es un archivo de configuración de cincuenta líneas. El cluster cuida del resto: distribuye los runners por los nodos, mantiene el servidor disponible incluso con pérdida de máquina, hace backup del estado, expone métricas en el panel embebido.

Para quien quiere más contexto, vale la pena leer también Deploy Docker en producción: de compose a cluster — discute cuándo tiene sentido salir de docker-compose para un plano de control replicado, con los mismos criterios honestos de este post. Y para equipos pensando en simplificar la stack de orquestación entera, Migrar de Kubernetes a una stack más simple — case real tiene números de una migración real, con ganancias y dolores.

La elección de CI/CD es una de las decisiones más duraderas del equipo. Vale algunos días de comparación honesta antes de copiar el .github/workflows/ del proyecto anterior — porque tres años después, migrar cuesta caro.