Runners autoalojados de GitHub Actions, en la UE

Los mismos workflows, en una máquina de Praga o Covilhã que es suya por meses en lugar de por minutos - con la caché de compilación aún caliente y una dirección que un cortafuegos sí puede autorizar.

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

Para quién es

Un equipo que vigila el contador de minutos

Un minuto de Linux de 2 núcleos cuesta 0,006 USD y uno de 16 núcleos 0,042 USD, así que la compilación en matriz que hizo rápida la suite es lo mismo que hizo interesante la factura.

Un workflow que tiene que llegar a algo privado

El paso de despliegue necesita hablar con una base de datos, un registro o un equipo que solo acepta direcciones conocidas, y los runners alojados de GitHub llegan desde un rango demasiado grande para autorizarlo.

Una compilación que necesita más de lo que trae la imagen

Un compilador con licencia, un emulador, 30 GB de datos de prueba o simplemente más disco del que tiene el runner alojado - e instalarlo de nuevo en cada trabajo es la mayor parte de la pipeline.

Qué cambia cuando el runner es suyo

  • El espacio de trabajo y las cachés persisten entre trabajos, así que restaurar dependencias deja de ser el paso más largo del workflow.
  • Una IPv4 estática de AS204057 que su base de datos, su registro o su VPN pueden autorizar por dirección.
  • Lo que instale sigue instalado - cadenas de herramientas, SDK con licencia, emuladores, grandes conjuntos de datos, todo lo que la imagen alojada no lleva.
  • Runners registrados a nivel de repositorio, organización o empresa, con las etiquetas que elija y un workflow que los selecciona con runs-on.
  • Disco y RAM que elige usted, en lugar de la forma fija con la que viene un runner alojado.
  • Una máquina en Praga o Covilhã bajo contrato chipriota, que es una respuesta de residencia de datos y no un ajuste de región.

Dimensionado por lo que la pipeline hace de verdad

Un servicio de runner es un trabajo a la vez, así que aquí la concurrencia es un recuento de procesos de runner y no un escalón de plan - varios en un host, cada uno en su propio directorio, es la forma normal. Dimensione por el trabajo más pesado y no por la media, y deje holgura de disco: el espacio de trabajo, la caché de herramientas y las capas de contenedor viven todos ahí, y esa persistencia es la razón misma de autoalojar. La mitad honesta del trato: un host mensual fijo cuesta lo mismo en una semana sin subidas, donde los minutos alojados no cuestan nada. Sale a cuenta en cuanto la pipeline se ejecuta casi todos los días.

Un primer runner
16.49
por mes

Pedir Ahora
uno o dos servicios de runner
2 vCPU
8 GB RAM
80 GB NVMe
1 IPv4 estática
1 copia semanal incluida
Un runner de equipo
32.99
por mes

Pedir Ahora
de cuatro a seis servicios de runner
4 vCPU
16 GB RAM
160 GB NVMe
1 IPv4 estática
1 copia semanal incluida
Un pool con carga
62.94
por mes

Pedir Ahora
una compilación en matriz, o varios repositorios
8 vCPU
32 GB RAM
240 GB NVMe
1 IPv4 estática
1 copia semanal incluida

Cómo instalar un runner de GitHub Actions en un host nuevo

Linux x64, en el orden que documenta GitHub. El token de registro se genera por runner y caduca una hora después de abrir la página, así que consígalo el último.

  1. Cree un usuario sin privilegios para él

    sudo adduser --disabled-password --gecos "" runner
    sudo -iu runner

    El runner ejecuta lo que le diga un workflow, así que no debería ser root ni compartir su directorio personal con nada más. Todo lo de abajo se ejecuta como este usuario.

  2. Descargar y desempaquetar el runner

    mkdir actions-runner && cd actions-runner
    curl -O -L https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-x64-2.336.0.tar.gz
    echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d  actions-runner-linux-x64-2.336.0.tar.gz" | shasum -a 256 -c
    tar xzf ./actions-runner-linux-x64-2.336.0.tar.gz

    Esa versión y esa suma de verificación son las publicadas con la release v2.336.0. Compruebe si hay una más nueva en la página de releases antes de copiar esto: el runner se actualiza solo después, pero la primera descarga es suya para verificarla.

  3. Configurarlo contra un repositorio o una organización

    ./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token AXXXXXXXXXXXXXXXXXXXXXXXXX --labels self-hosted,linux,x64,eu

    Tome el token en Settings, luego Actions, luego Runners, luego New self-hosted runner - está limitado en el tiempo y caduca una hora después de emitirse. Apunte la URL a la organización en lugar del repositorio para compartir un runner entre repositorios.

  4. Ejecutarlo como servicio

    sudo ./svc.sh install runner
    sudo ./svc.sh start
    sudo ./svc.sh status

    svc.sh recibe el usuario con el que debe ejecutarse el servicio, y por eso se creó antes el usuario runner. Use ./run.sh si solo quiere ver aterrizar un trabajo antes de comprometerse con un servicio.

  5. Impedir que needrestart mate trabajos a medio ejecutar

    echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.conf

    En Debian y Ubuntu, needrestart reinicia los servicios cuyas bibliotecas se han actualizado - incluido un runner en mitad de un trabajo. GitHub documenta exactamente este fichero como la forma de exceptuarlo.

  6. Apuntar un workflow hacia él

    name: smoke
    on: [push]
    jobs:
      build:
        runs-on: [self-hosted, linux, x64, eu]
        steps:
          - uses: actions/checkout@v6
          - run: cat /etc/os-release

    runs-on casa con todas las etiquetas de la lista, así que un trabajo que pide cuatro etiquetas solo aterriza en un runner que lleve las cuatro. Si se queda en cola, falta una etiqueta - y un trabajo más de 24 horas en cola falla.

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

Lo que no somos

  • No somos GitHub. GitHub, GitHub Actions y el runner son suyos, y nada de esta página cuenta con su respaldo. Vendemos la máquina donde se ejecuta el runner.
  • Esto no sustituye su plan de GitHub. Los runners autoalojados no cuestan minutos de Actions, que es de lo que se trata, pero las licencias, el almacenamiento y todo lo demás siguen en su factura.
  • No gestionamos el runner salvo que lo pida. Lo instala usted, o añade nuestro servicio de administración y lo mantenemos parcheado, registrado y vigilado.
  • Los runners autoalojados están documentados como poco adecuados para repositorios públicos: un fork puede proponer un cambio de workflow y ese cambio se ejecutaría en su máquina. Manténgalos en repositorios privados salvo que lo haya pensado a fondo.
  • Aquí no hay plano de control con autoescalado. Si quiere runners creados y destruidos por trabajo, eso es Actions Runner Controller sobre un clúster de Kubernetes - que alojamos encantados, en otra página.

Las partes que los equipos descubren tarde

  • Un servicio de runner ejecuta un trabajo a la vez. La concurrencia viene de instalar varios, cada uno en su directorio con su propio servicio, no de un ajuste.
  • El token de registro caduca una hora después de emitirse, así que genérelo cuando esté listo para ejecutar config.sh y no al principio de la tarde.
  • Las etiquetas son todo el mecanismo de enrutado. runs-on casa con todas las etiquetas de la lista, así que una errata no da error - el trabajo simplemente espera, y falla tras 24 horas en cola.
  • El runner necesita lttng-ust, OpenSSL, Kerberos, zlib y libicu presentes. Debian y Ubuntu los traen; una imagen de contenedor mínima a menudo no.
  • x64 y ARM64 están soportados en Linux, y ARM32 solo en Linux. Debian 10 o posterior y Ubuntu 20.04 o posterior son las bases documentadas.
  • Todo lo que el workflow deja atrás se queda en el disco - esa es la ventaja, y también la razón por la que un runner autoalojado quiere una tarea de limpieza programada y un snapshot.

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

- ¿Cuánto cuestan los runners alojados de GitHub frente a autoalojar?

GitHub factura los runners Linux alojados por minuto: 0,006 USD para 2 núcleos, 0,012 para 4, 0,022 para 8 y 0,042 para 16, con Windows a 0,010 para 2 núcleos y macOS a 0,062 para una máquina de 3 o 4 núcleos. Los runners autoalojados no consumen minutos de Actions. Un host aquí empieza en 16,49 EUR al mes, que es aproximadamente lo que cuestan 2.700 minutos en un runner alojado de 2 núcleos - así que el punto de cruce está en torno a 45 horas de compilación al mes

- ¿Cómo configuro un runner autoalojado de GitHub Actions?

Cree un usuario sin privilegios, descargue el archivo del runner para linux-x64 desde las releases de actions/runner y verifique su suma de comprobación, ejecute ./config.sh con la URL de su repositorio u organización y el token de registro de Settings, Actions, Runners, y después instálelo como servicio con sudo ./svc.sh install y arránquelo. Los comandos exactos están en esta página. El token de registro caduca una hora después de emitirse

- ¿Cuántos trabajos puede ejecutar un runner a la vez?

Uno. Un servicio de runner toma un solo trabajo a la vez, así que la concurrencia consiste en instalar varios servicios de runner en el host, cada uno en su propio directorio. Por eso el dimensionamiento de esta página cuenta servicios de runner y no trabajos, y por eso una máquina de 8 vCPU lleva con holgura una compilación en matriz pequeña

- ¿Qué sistemas operativos y arquitecturas están soportados?

En Linux, Debian 10 o posterior, Ubuntu 20.04 o posterior, RHEL 8 o posterior, CentOS 8 o posterior, Fedora 29 o posterior, openSUSE 15.2 o posterior y sus parientes, en x64, ARM64 y ARM32. El runner necesita además lttng-ust, OpenSSL, Kerberos, zlib y libicu, que Debian y Ubuntu traen de serie

- ¿Es seguro usar un runner autoalojado en un repositorio público?

GitHub lo desaconseja, y la razón es concreta: cualquiera puede abrir un pull request que cambie el fichero de workflow, y ese workflow cambiado se ejecutaría en su máquina. Mantenga los runners autoalojados en repositorios privados salvo que lo haya leído a fondo y haya puesto aislamiento real. Todo lo que un trabajo deja atrás persiste además en el disco, lo que es una ventaja para la caché y un riesgo para los secretos

- ¿Puede un runner servir a varios repositorios?

Sí. Regístrelo a nivel de organización en lugar de a nivel de repositorio y cualquier repositorio de la organización podrá seleccionarlo, usando etiquetas en runs-on para dirigir el trabajo. Un trabajo que pide una etiqueta que ningún runner lleva simplemente espera, y falla tras 24 horas en cola - así se ve una errata en runs-on

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