Woodpecker CI, sin ningún SaaS por medio

Servidor y agentes en una máquina pequeña de Praga o Covilhã, conectados a su propia forja - la versión de CI en la que nada de la pipeline sale de una infraestructura que usted puede nombrar.

Certificado Tier III ISO 9001 ISO/IEC 27001 ISO 14001 Conforme con el RGPD

Para quién es

Un equipo que ya autoaloja todo lo demás

La forja es suya, el registro es suyo, el destino de despliegue es suyo - y CI es el único salto que todavía sale del edificio, justo el salto que sostiene el código.

Una instalación de Drone que dejó de moverse

Woodpecker es el fork que siguió adelante y se mantuvo Apache-2.0. La migración es pequeña; la pregunta es sobre qué ejecutarlo.

Un equipo pequeño que quiere que CI sea aburrido

Dos contenedores, un fichero YAML por repositorio, ningún plano de control que aprender y ningún contador por minuto que vigilar. Solo necesita un sitio donde vivir.

Lo que le da esta forma

  • Servidor y agente como dos contenedores en un host, lo bastante pequeño para que CI deje de ser un proyecto de infraestructura.
  • Cualquier forja que Woodpecker soporte - GitHub, GitLab, Gitea, Forgejo o Bitbucket - incluida una que aloje usted mismo en la misma red.
  • Agentes añadidos después como hosts aparte, todos autenticándose contra el mismo servidor, cuando una máquina deja de bastar.
  • Apache-2.0 de principio a fin, así que nada de la pipeline depende de que un proveedor decida mantener un plan gratuito.
  • Una IPv4 estática de AS204057, para que el webhook de la forja y el destino de despliegue tengan ambos una sola dirección en la que confiar.
  • NVMe local para el espacio de trabajo y la caché de capas de Docker, caliente entre pipelines.

Dimensionado por lo que la pipeline hace de verdad

Woodpecker en sí es ligero: el servidor es un pequeño proceso Go con base de datos embebida hasta que lo apunta a Postgres, y el agente es un supervisor que arranca contenedores. Lo que consume el host es la compilación, exactamente igual que con cualquier otro runner - así que dimensione la máquina por el trabajo más pesado y deje sitio en el disco para la caché de capas que hace rápida la segunda pipeline. El tamaño de entrada de abajo lleva servidor y agente juntos con holgura para un equipo pequeño. La única salvedad honesta: un host mensual fijo cuesta lo mismo en una semana sin subidas, donde los minutos de CI alojados no cuestan nada.

Un primer runner
15.00
por mes

Pedir Ahora
servidor y un agente juntos
2 vCPU
4 GB RAM
64 GB NVMe
1 IPv4 estática
1 copia semanal incluida
Un runner de equipo
19.96
por mes

Pedir Ahora
servidor más un par de workflows en paralelo
4 vCPU
8 GB RAM
120 GB NVMe
1 IPv4 estática
1 copia semanal incluida
Un pool con carga
39.90
por mes

Pedir Ahora
un host de agente dedicado junto al servidor
8 vCPU
16 GB RAM
240 GB NVMe
1 IPv4 estática
1 copia semanal incluida

Cómo instalar Woodpecker CI con Docker Compose

Servidor y agente en un host, conectados a GitHub en este ejemplo. Cambie el bloque de la forja por las variables de Gitea, Forgejo, GitLab o Bitbucket si su forja es una de esas.

  1. Instalar Docker y Compose

    sudo apt install docker.io docker-compose-v2
    sudo systemctl enable --now docker

    Los dos contenedores y cada paso de la pipeline se ejecutan sobre este demonio, así que es la única dependencia que necesita el host.

  2. Registrar una aplicación OAuth en su forja

    # GitHub: Settings -> Developer settings -> OAuth Apps -> New OAuth App
    # Homepage URL:     https://ci.example.com
    # Authorization callback: https://ci.example.com/authorize

    Woodpecker autentica a los usuarios a través de la forja y lee repositorios con ese permiso, así que el id de cliente y el secreto que devuelve son lo que necesita el servidor. Cada forja soportada tiene un formulario equivalente.

  3. Generar el secreto compartido del agente

    openssl rand -hex 32

    El servidor y los agentes se autentican entre sí con esta cadena, y la documentación de Woodpecker nombra exactamente este comando para producirla. Manténgala fuera del fichero de compose - póngala en un fichero .env al lado.

  4. Escribir el fichero de compose

    services:
      woodpecker-server:
        image: woodpeckerci/woodpecker-server:v3
        ports:
          - 8000:8000
        volumes:
          - woodpecker-server-data:/var/lib/woodpecker/
        environment:
          - WOODPECKER_OPEN=true
          - WOODPECKER_HOST=${WOODPECKER_HOST}
          - WOODPECKER_GITHUB=true
          - WOODPECKER_GITHUB_CLIENT=${WOODPECKER_GITHUB_CLIENT}
          - WOODPECKER_GITHUB_SECRET=${WOODPECKER_GITHUB_SECRET}
          - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
      woodpecker-agent:
        image: woodpeckerci/woodpecker-agent:v3
        command: agent
        restart: always
        depends_on:
          - woodpecker-server
        volumes:
          - woodpecker-agent-config:/etc/woodpecker
          - /var/run/docker.sock:/var/run/docker.sock
        environment:
          - WOODPECKER_SERVER=woodpecker-server:9000
          - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
    volumes:
      woodpecker-server-data:
      woodpecker-agent-config:

    Este es el ejemplo oficial. WOODPECKER_HOST es la URL pública a la que llegan usuarios y webhooks, el puerto 8000 es la interfaz web y el 9000 es el puerto gRPC por el que se conectan los agentes. WOODPECKER_OPEN=true deja entrar a cualquiera con una cuenta en la forja - desactívelo en cuanto su equipo esté registrado.

  5. Arrancarlo

    docker compose up -d
    docker compose logs -f woodpecker-agent

    El agente se conecta al servidor con el secreto compartido y se registra solo en el primer contacto. Si entra en bucle con un error de autenticación, los dos secretos no coinciden - casi siempre porque no se leyó el fichero .env.

  6. Añadir una pipeline

    when:
      - event: push
    
    steps:
      - name: smoke
        image: alpine:latest
        commands:
          - cat /etc/os-release
          - echo "built on $CI_MACHINE"

    Haga commit de eso como .woodpecker.yaml, active el repositorio en la interfaz web para que se cree el webhook, y suba los cambios. Cada paso es un contenedor, y por eso el agente necesita el socket de Docker.

Comprobado con la documentación oficial el 2026-08-15 — leer la fuente

Lo que no somos

  • No somos el proyecto Woodpecker. Woodpecker CI es un proyecto Apache-2.0 independiente y nada de esto cuenta con su respaldo. Vendemos la máquina donde se ejecuta.
  • En esta página no alojamos su forja. Gitea, Forgejo o un GitLab autogestionado al lado es un segundo servidor sencillo, pero es otro tamaño y otro presupuesto.
  • No escribimos sus pipelines. El YAML es suyo; el host, la red y la dirección son nuestros.
  • Woodpecker no se gestiona por usted por defecto. Usted ejecuta los dos contenedores, o añade nuestro servicio de administración y los mantenemos actualizados y respaldados.
  • Montar el socket de Docker dentro del agente da a los pasos de la pipeline muchísimo poder sobre el host. Así funciona este diseño, y es una razón para tener el agente en una máquina que no haga nada más.

Las partes que los equipos descubren tarde

  • WOODPECKER_AGENT_SECRET tiene dos modos. El mismo valor en el servidor y en todos los agentes es un token de sistema; un token por agente sale de registrar antes el agente en la interfaz, que es lo que quiere en cuanto más de un equipo puede llegar al host.
  • Toda variable sensible tiene también una forma _FILE, de modo que el secreto se puede leer de un fichero montado en lugar de estar en el fichero de compose o en el entorno.
  • La base de datos embebida está bien para empezar y sigue siendo lo primero que hay que mover. Apunte el servidor a Postgres antes de que la instalación le importe a alguien.
  • WOODPECKER_OPEN=true significa que cualquier cuenta de la forja conectada puede entrar. Cómodo el primer día y equivocado el día treinta.
  • El agente necesita el socket de Docker porque cada paso es un contenedor, lo que en la práctica concede a la pipeline root en ese host. Mantenga el host del agente aburrido y separado.
  • WOODPECKER_HOST tiene que ser la URL a la que la forja puede llegar de verdad, no la interna - el webhook se crea contra ella, y una dirección privada ahí produce pipelines que nunca se disparan.

Minutos de CI alojados frente a un runner propio

Minutos de CI alojados por el proveedorUn runner en DCXV
Por lo que pagaCada minuto de cada trabajo, mientras exista el proyectoUn host mensual fijo, haga lo que haga la pipeline ese mes
Una compilación que se vuelve más lentaCuesta más cada mes que siga siendo lentaNo cuesta nada más - la máquina ya está pagada
Caché de capas de DockerFría en cada trabajo salvo que la suba y la baje usted mismoCaliente en NVMe local, entre trabajos y entre días
ConcurrenciaUn escalón de plan que se contrataUn número que usted pone en su propio fichero de configuración
Dónde aterriza el checkoutUna flota compartida, a menudo en una región que no puede fijarUna máquina en Praga o Covilhã, bajo contrato chipriota
Dirección salienteUn rango compartido enorme que nada puede autorizarUna IPv4 estática de AS204057, suya para autorizar
Lo que la máquina puede contenerLo que la imagen del runner traiga de serieCualquier cadena de herramientas, licencia o conjunto de datos que instale una vez

Cómo se pone esto en marcha en su host

1

Díganos qué hace la pipeline

El trabajo más pesado que ejecuta hoy, cuántos quiere a la vez y si construye imágenes de contenedor. Con eso basta para dimensionar un host sin adivinar.

2

Le entregamos la máquina

Praga o Covilhã, acceso root y una IPv4 estática, en menos de diez minutos. Traiga su propia imagen si el runner ya viene dentro.

3

Siga el paso a paso de esta página

Es la secuencia del fabricante, tomada de su documentación actual y no de una entrada de blog, y lleva unos minutos en un host limpio.

4

Haga un snapshot y añada el segundo

Haga un snapshot en cuanto la primera pipeline esté en verde, para que la siguiente máquina sea una restauración y no una reconstrucción. Un grupo crece añadiendo hosts, no haciendo uno enorme.

Por qué elegirnos

  • Instalaciones certificadas Tier III, SLA de instalación del 99,982 %
  • Red propia, AS204057, IPv4 e IPv6
  • Soporte 24/7/365 con unos 10 minutos de respuesta media
  • Sociedad chipriota, jurisdicción de la UE, conforme al RGPD desde 2007

FAQ

- ¿Qué es Woodpecker CI?

Un motor de CI ligero con licencia Apache-2.0, forkeado de Drone, que se ejecuta como un servidor más uno o varios agentes. Cada paso de la pipeline es un contenedor, las pipelines son un fichero YAML en el repositorio, y la autenticación pasa por su forja. Soporta GitHub, GitLab, Gitea, Forgejo y Bitbucket, incluidas instancias que aloje usted mismo

- ¿Cómo instalo Woodpecker CI?

Docker Compose es la vía documentada: un contenedor woodpecker-server exponiendo el puerto 8000 y un contenedor woodpecker-agent con el socket de Docker montado, compartiendo un secreto generado con openssl rand -hex 32, más el id de cliente y el secreto OAuth de su forja. El fichero de compose oficial y los pasos que lo rodean están en esta página

- ¿Qué es WOODPECKER_AGENT_SECRET y cómo lo genero?

Es el secreto compartido con el que se autentican el servidor y los agentes, y la documentación de Woodpecker nombra openssl rand -hex 32 para producirlo. Poner el mismo valor en todas partes lo convierte en un token de sistema; registrar antes el agente en la interfaz le da a ese agente un token propio, que es lo que quiere en cuanto más de un equipo puede llegar al host. Toda variable sensible tiene también una forma _FILE para leer el valor de un fichero montado

- ¿Qué tamaño de servidor necesita Woodpecker?

El software en sí es ligero - el servidor es un pequeño proceso Go con base de datos embebida hasta que lo apunta a Postgres, y el agente es un supervisor que arranca contenedores. Lo que consume la máquina es la compilación. 2 vCPU, 4 GB y 64 GB de NVMe llevan servidor y agente juntos para un equipo pequeño; pase a un host de agente dedicado en cuanto las pipelines empiecen a hacer cola

- ¿Por qué necesita el agente el socket de Docker?

Porque cada paso de la pipeline es un contenedor que el agente arranca en el demonio del host. Eso da a los pasos de la pipeline root en esa máquina, lo cual es el diseño y no una mala configuración - y es la razón para tener el agente en un host que no haga nada más, algo barato cuando una segunda máquina cuesta 15 EUR al mes

- Mis pipelines nunca se disparan. ¿Qué pasa?

Nueve de cada diez veces es WOODPECKER_HOST. Ese valor es la URL pública que usa la forja al crear el webhook, así que una dirección interna ahí produce una instalación que parece sana y nunca recibe un push. El otro caso frecuente es WOODPECKER_OPEN=true, que no es un problema de disparo pero sí significa que cualquiera con cuenta en su forja puede entrar - cómodo el primer día, equivocado el día treinta

Si necesita asistencia o tiene preguntas adicionales, por favor contacte a los gerentes o escriba al equipo de soporte en support@dcxv.com

¿Listo para comenzar?

Facturación mensual, sin cuota de instalación, sin compromiso

Servidores en la nube desde 15 €/mes