Runner autoalojado de GitHub: configuración en Linux, Docker y Kubernetes

Un runner autoalojado de GitHub ejecuta jobs de GitHub Actions en una máquina que tú proporcionas, usando el agente de código abierto actions/runner de GitHub. El runner se conecta a GitHub mediante HTTPS saliente para recibir trabajo. A fecha del 4 de noviembre de 2026, la documentación de facturación de GitHub indica que el cómputo de runners autoalojados es gratuito; tú pagas la máquina y su mantenimiento. Referencia de runners de GitHub, facturación de GitHub Actions.

Creamos Lizard, que vende runners de GitHub Actions; precios comprobados el 4 de noviembre de 2026.

La vía más rápida es una VM de Linux, un token de registro de la configuración de tu repositorio y un workflow con etiquetas de runner coincidentes. Empieza con un repositorio privado de prueba. Para una flota, elige VM efímeras, Kubernetes con ARC o el módulo de Terraform para AWS. Para runners existentes, ve a seguridad, resolución de problemas o costos de la máquina.

Runner autoalojado vs runner alojado en GitHub

GitHub aprovisiona y mantiene un entorno nuevo para cada job alojado. Con un runner autoalojado, tú proporcionas la máquina, aplicas sus parches y la proteges.

Fuentes: descripción de runners autoalojados, descripción de runners alojados y documentación de facturación de GitHub.

Mantén los runners alojados en GitHub si tu proyecto de código abierto ya se ejecuta gratis o si tu equipo no quiere mantener máquinas de compilación. El autoalojamiento tiene sentido cuando necesitas hardware específico, acceso a una red privada o suficiente trabajo constante para justificar la operación de las máquinas.

¿Qué configuración encaja?

¿Cómo configuras un runner autoalojado de GitHub Actions en Linux?

Para añadir un runner autoalojado de GitHub Actions:

1. Abre Settings → Actions → Runners → New self-hosted runner en tu repositorio.
2. Descarga actions/runner y comprueba su suma de verificación SHA-256.
3. Regístralo con ./config.sh, la URL del repositorio y el token de registro de la página.
4. Inicia ./run.sh y confirma que está a la escucha.
5. Envía un job con runs-on: [self-hosted, linux, x64, linux-build], que coincida con la etiqueta personalizada de abajo.

Usa una VM x64 de Ubuntu 24.04 o Debian 12 con systemd. Inicia sesión con un usuario normal que no sea root y pueda usar sudo. Necesitas un repositorio privado de GitHub que administres, acceso saliente a internet y suficiente disco y memoria para tu compilación. Los requisitos de runners de GitHub admiten ambos sistemas operativos y exigen HTTPS saliente por el puerto 443. El runner no necesita un puerto entrante para webhooks.

El 4 de noviembre de 2026 probamos estos pasos en una VM nueva de Debian 12 x64 con systemd y actions/runner v2.338.2: descarga y suma de verificación, registro en un repositorio privado de prueba, el workflow de prueba básica, instalación del servicio, eliminación y un runner JIT a nivel de repositorio. Las salidas de abajo son extractos de esa prueba; nuestro usuario de prueba era builder.

Descarga el runner y verifícalo

En el repositorio, abre Settings → Actions → Runners → New self-hosted runner y selecciona Linux y x64. Para un runner de organización, usa la configuración de la organización y una cuenta de propietario de la organización. Los administradores de empresas también pueden añadir runners con ámbito de empresa. Las instrucciones de configuración de GitHub explican cada ámbito.

Ejecuta esto en Bash con tu usuario que no sea root. Obtiene la versión actual y su hash SHA-256 de la API de versiones de GitHub, y comprueba el archivo antes de extraerlo:

sudo apt-get update
sudo apt-get install -y ca-certificates curl jq
mkdir actions-runner
cd actions-runner
curl -fsSL https://api.github.com/repos/actions/runner/releases/latest -o release.json
RUNNER_VERSION=$(jq -er '.tag_name | ltrimstr("v")' release.json)
RUNNER_TARBALL="actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz"
RUNNER_URL=$(jq -er --arg name "$RUNNER_TARBALL" \
  '.assets[] | select(.name == $name) | .browser_download_url' release.json)
RUNNER_SHA=$(jq -er --arg name "$RUNNER_TARBALL" \
  '.assets[] | select(.name == $name) | .digest | select(startswith("sha256:")) | ltrimstr("sha256:")' release.json)
curl -fsSL "$RUNNER_URL" -o "$RUNNER_TARBALL"
printf '%s  %s\n' "$RUNNER_SHA" "$RUNNER_TARBALL" | sha256sum -c - && \
  tar xzf "$RUNNER_TARBALL" && \
  sudo ./bin/installdependencies.sh && \
  ./config.sh --help

Resultado esperado: actions-runner-linux-x64-2.338.2.tar.gz: OK. La extracción solo se ejecuta si la suma de verificación coincide; detente si falla o si GitHub no proporciona un hash. Las versiones se distribuyen progresivamente, así que usa la versión y la suma de verificación de la página de configuración de tu repositorio si es necesario. Versiones del runner de GitHub.

En Debian 12, installdependencies.sh imprimió E: Unable to locate package libicu80 y líneas similares mientras probaba versiones de ICU, y después encontró libicu72. Esos intentos con alternativas eran esperados en nuestra prueba; comprueba que el script termine correctamente.

Regístralo y ponlo a la escucha

Copia el token de registro de la página de configuración. GitHub indica que este token caduca al cabo de una hora. Es un token de registro de runner, no un token de acceso personal. Sustituye YOUR_OWNER/YOUR_REPO de abajo por la ruta del repositorio; usa https://github.com/YOUR_ORG para el ámbito de organización.

read -rsp 'Registration token: ' RUNNER_TOKEN
printf '\n'
./config.sh --unattended \
  --url https://github.com/YOUR_OWNER/YOUR_REPO \
  --token "$RUNNER_TOKEN" \
  --name linux-build-01 \
  --labels linux-build
unset RUNNER_TOKEN
./run.sh

Resultado esperado: √ Connected to GitHub, √ Runner successfully added, √ Settings Saved. y, después, Listening for Jobs tras ./run.sh. En Settings → Actions → Runners, busca Idle cuando esté conectado y listo. Deja la terminal en ejecución para el primer job. Registro, estado del runner.

Envíale un job

Guarda este archivo en un commit como .github/workflows/runner-check.yml en la rama predeterminada de tu repositorio:

name: Check self-hosted runner
on:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  check:
    runs-on: [self-hosted, linux, x64, linux-build]
    steps:
      - name: Show the execution environment
        run: |
          echo "Runner accepted the job"
          uname -s -m
          whoami

Abre Actions → Check self-hosted runner → Run workflow. Resultado esperado de nuestra prueba: Runner accepted the job / Linux x86_64 / builder. Tu nombre de usuario puede ser distinto. Esta prueba básica no necesita checkout ni herramientas de compilación; añádelos para tu compilación. Si se queda en cola, consulta por qué el job está esperando.

GitHub exige que coincidan todas las etiquetas de la lista runs-on. El runner recibe self-hosted, linux y x64 durante el registro; linux-build es nuestra etiqueta personalizada de ejemplo. Una etiqueta describe un runner, pero no instala software ni concede acceso a repositorios. Asignación de workflows de GitHub a runners.

Mantenlo en ejecución como servicio

Cuando termine la prueba, pulsa Ctrl-C y confirma que el proceso de escucha ./run.sh en primer plano haya terminado antes de iniciar el servicio. De lo contrario, el registro de systemd puede mostrar A session for this runner already exists. y Conflict, mientras el proceso de escucha anterior recibe jobs. Nos ocurrió en nuestra prueba. Desde el directorio del runner, con el mismo usuario que no sea root:

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

Resultado esperado: Active: active (running) de svc.sh status. GitHub crea svc.sh después del registro; en systemd, estos comandos mantienen el runner en ejecución tras cerrar sesión y reiniciar. Configuración del servicio de GitHub.

Elimina un runner

En Settings → Actions → Runners, selecciona el runner y haz clic en Remove para obtener un token de eliminación. Desde su directorio, detén y desinstala el servicio y, después, elimina el registro:

sudo ./svc.sh stop
sudo ./svc.sh uninstall
read -rsp 'Removal token: ' REMOVAL_TOKEN
printf '\n'
./config.sh remove --token "$REMOVAL_TOKEN"
unset REMOVAL_TOKEN

Resultado esperado: √ Runner removed successfully, √ Removed .credentials, √ Removed .runner. Las instrucciones de eliminación de runners de GitHub cubren la interfaz; la automatización puede solicitar un token de eliminación de runners a nivel de repositorio.

¿En qué se diferencian los grupos de runners de las etiquetas?

Un grupo de runners de GitHub Actions controla qué repositorios pueden usar un conjunto de runners. Las etiquetas ayudan a seleccionar un runner dentro de ese conjunto permitido. Para runners de organización, abre Settings → Actions → Runner groups, selecciona un grupo y restringe Repository access a los repositorios que lo necesiten. Controles de grupos de runners de GitHub.

Para un runner de organización, crea un grupo llamado trusted-builds y, después, registra el runner con --url https://github.com/YOUR_ORG --runnergroup trusted-builds. El grupo debe existir antes; este flag no se aplica a la configuración con ámbito de repositorio de arriba. Un job puede exigir tanto grupo como etiqueta:

runs-on:
  group: trusted-builds
  labels: linux-build

Mantén los jobs de publicación de versiones separados de los runners que usan repositorios de menor confianza. Los grupos limitan quién puede planificar trabajo; no aíslan procesos ni hacen seguros los discos compartidos. La documentación de asignación de jobs a runners de GitHub exige tanto acceso al grupo como etiquetas coincidentes.

¿Cómo funcionan los runners efímeros y just-in-time?

Un runner efímero acepta un job antes de que GitHub elimine su registro; activa este comportamiento con --ephemeral. Tu infraestructura debe destruir la VM o borrar sus discos igualmente. GitHub recomienda runners efímeros para el escalado automático e indica que debes conservar sus logs externamente antes de usarlos en producción. Referencia de escalado automático de GitHub.

Si conservaste un runner anterior con la misma etiqueta linux-build, detén su servicio con sudo ./svc.sh stop o usa una etiqueta distinta tanto en el runner nuevo como en el workflow. De lo contrario, GitHub podría enviar el job de prueba al runner anterior. En una VM nueva y un directorio de runner sin configurar, usa un token de registro nuevo:

read -rsp 'Registration token: ' RUNNER_TOKEN
printf '\n'
./config.sh --unattended \
  --url https://github.com/YOUR_OWNER/YOUR_REPO \
  --token "$RUNNER_TOKEN" \
  --name "ephemeral-$(hostname)" \
  --labels linux-build \
  --ephemeral
unset RUNNER_TOKEN
./run.sh

Destruye la máquina cuando termine el proceso de escucha, también después de un fallo. Gestiona también las cancelaciones y las máquinas que nunca reciben un job. Volver a registrar la misma VM con restos de ejecuciones anteriores no crea un entorno limpio.

Genera una configuración just-in-time mediante la API

Un runner JIT recibe su configuración al arrancar y puede ejecutar como máximo un job. Un componente de aprovisionamiento puede obtener esa configuración sin colocar una credencial de larga duración de la API de GitHub en el worker. GitHub sigue advirtiendo que reutilizar el hardware subyacente requiere un entorno limpio. Guía de seguridad de JIT de GitHub.

Para este ejemplo a nivel de organización, usa un token de API autorizado para la organización con el permiso Self-hosted runners: write. Un administrador de la organización puede usar un token de permisos detallados para una prueba; usa un token de instalación de GitHub App en la automatización. Obtén el ID numérico del grupo de la API de grupos de runners de GitHub y restringe primero el acceso de ese grupo a los repositorios.

En Bash, sustituye los valores de ejemplo de la organización y el grupo. Ejecútalo desde el directorio del runner en una máquina nueva (repite primero el bloque de descarga), solo para una prueba de confianza; en producción, ejecuta la solicitud a la API en el componente de aprovisionamiento y entrega al worker únicamente la configuración devuelta.

ORG='YOUR_ORG'
RUNNER_GROUP_ID='REPLACE_WITH_NUMERIC_GROUP_ID'
read -rsp 'GitHub API token: ' GH_API_TOKEN
printf '\n'
JIT_CONFIG=$(
  jq -n --arg name "jit-$(date +%s)" --argjson group "$RUNNER_GROUP_ID" \
    '{name: $name, runner_group_id: $group,
      labels: ["self-hosted", "linux", "x64", "linux-build"],
      work_folder: "_work"}' |
  curl -fsSL -X POST \
    -H 'Accept: application/vnd.github+json' \
    -H "Authorization: Bearer $GH_API_TOKEN" \
    -H 'X-GitHub-Api-Version: 2026-03-10' \
    --data-binary @- \
    "https://api.github.com/orgs/$ORG/actions/runners/generate-jitconfig" |
  jq -er '.encoded_jit_config'
)
unset GH_API_TOKEN
[ -n "$JIT_CONFIG" ] && ./run.sh --jitconfig "$JIT_CONFIG"
unset JIT_CONFIG

GitHub documenta esta solicitud JIT de organización y un endpoint JIT a nivel de repositorio para pruebas con un solo repositorio; nuestra prueba usó este último con runner_group_id: 1. El flag --jitconfig funciona aunque ./run.sh --help no lo muestre. Trata la configuración codificada como un secreto; la asignación de jobs a runners sigue dependiendo del ámbito, los grupos y las etiquetas.

Resultado esperado después del job JIT: Job check completed with result: Succeeded, √ Removed .credentials, √ Removed .runner y, después, Runner listener exit with 0 return code, stop the service, no retry needed. y Exiting runner....

¿Cómo ejecutas un runner autoalojado de GitHub en Docker?

La imagen ghcr.io/actions/actions-runner, mantenida por GitHub, ejecuta el agente en un contenedor. Este ejemplo usa la etiqueta 2.338.2, la versión más reciente del runner a fecha del 4 de noviembre de 2026; comprobamos su manifiesto de Linux x64, pero no hemos ejecutado un job de Docker con ella.

Instala primero Docker Engine siguiendo las instrucciones para Ubuntu o las instrucciones para Debian de Docker. El comando usa sudo; la alternativa de Docker de configurar el grupo docker concede acceso de nivel root.

Obtén una configuración nueva para un solo job de la API generate-jitconfig de GitHub usando la solicitud JIT, pero omite las líneas de inicio local del runner y unset JIT_CONFIG. Con la configuración devuelta en JIT_CONFIG, ejecuta:

sudo docker run --rm --init --platform linux/amd64 \
  --entrypoint /home/runner/run.sh \
  ghcr.io/actions/actions-runner:2.338.2 \
  --jitconfig "$JIT_CONFIG"
unset JIT_CONFIG

Envía el workflow de prueba básica a la etiqueta del contenedor. Se ejecuta con el usuario runner de la imagen, no monta un espacio de trabajo persistente y se elimina al terminar. El código fuente de la imagen de GitHub enumera sus herramientas; añade las dependencias de compilación a una imagen derivada.

Ejecutar el agente en Docker es distinto de usar la opción container: de un workflow para ejecutar los pasos del job en Docker. GitHub requiere Linux y una instalación funcional de Docker para acciones en contenedores de Docker y contenedores de servicio. El comando anterior no configura un daemon de Docker para jobs con contenedores anidados. Jobs en contenedores de GitHub.

Montar el socket de Docker del host permite que el código del job controle ese daemon, lo que puede exponer el sistema de archivos del host. Docker-in-Docker suele requerir un contenedor privilegiado y necesita su propio plan de disco, redes y limpieza. Ninguna de las dos opciones hace que un host compartido normal de Docker sea seguro para pull requests hostiles. Usa una VM desechable como límite de aislamiento para trabajo no confiable y lee la guía de seguridad del daemon de Docker.

¿Cómo escalas automáticamente en Kubernetes con Actions Runner Controller?

Actions Runner Controller (ARC) es un controlador de Kubernetes de código abierto para runners autoalojados de GitHub Actions, mantenido por GitHub y colaboradores de la comunidad. Crea pods de runners para jobs en cola y escala la flota dentro de los valores de minRunners y maxRunners, hasta cero si así lo configuras. Úsalo cuando tu equipo ya opere Kubernetes; la guía de inicio rápido de ARC de GitHub requiere un clúster y Helm 3. Arquitectura de ARC.

Instala el controlador en su propio namespace:

helm install arc \
  --namespace arc-systems \
  --create-namespace \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller
kubectl create namespace arc-runners

Para este ejemplo con ámbito de organización, crea e instala una GitHub App con el permiso de organización Self-hosted runners: read and write y el permiso de repositorio Metadata: read-only. Guarda su clave privada localmente como github-app.pem. El registro con ámbito de repositorio también requiere Administration: read and write. Sigue las instrucciones de autenticación de ARC de GitHub.

Sustituye los ID de la App y de la instalación y, después, crea el secreto en el namespace de runners:

kubectl create secret generic arc-github-app \
  --namespace arc-runners \
  --from-literal=github_app_id=YOUR_APP_ID \
  --from-literal=github_app_installation_id=YOUR_INSTALLATION_ID \
  --from-file=github_app_private_key=./github-app.pem

Guarda esto como runner-values.yaml. El ejemplo elige cero runners inactivos y un máximo de cuatro runners; son los valores de configuración de tu presupuesto, no límites del producto ARC.

githubConfigUrl: https://github.com/YOUR_ORG
githubConfigSecret: arc-github-app
runnerScaleSetName: arc-linux
minRunners: 0
maxRunners: 4

Instala el conjunto de escalado de runners e inspecciona el controlador:

helm install arc-linux \
  --namespace arc-runners \
  --values runner-values.yaml \
  oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set
helm list -A
kubectl get pods -n arc-systems

En el workflow de prueba básica anterior, sustituye la lista de etiquetas por:

runs-on: arc-linux

Dispara el workflow y observa el namespace de runners:

kubectl get pods -n arc-runners -w

El resultado que GitHub indica como esperado es un controlador en ejecución y un pod de runner creado para el job. Escalar los pods de runners a cero no elimina los costos fijos de tu clúster. Estos nombres de charts y valores se comprobaron con la documentación de despliegue y los valores del chart de GitHub; no desplegamos un clúster para este artículo.

Antes de pasar a producción, fija versiones probadas de los charts y las imágenes, recopila logs del controlador y de los runners, y define solicitudes de recursos de los pods que se ajusten a tus compilaciones. Restringe el acceso al secreto de GitHub App. Para jobs en contenedores, elige el modo de contenedores Docker-in-Docker o Kubernetes documentado por ARC y revisa sus privilegios. Los valores mínimos de arriba no configuran ninguno de los dos modos.

¿Cómo escalas automáticamente runners autoalojados en AWS?

terraform-aws-github-runner es un módulo de Terraform de código abierto que escala automáticamente runners autoalojados en EC2 dentro de tu cuenta de AWS, sin Kubernetes. Su configuración basada en webhooks recibe eventos de jobs en cola mediante una GitHub App y usa Lambda y SQS para gestionar la demanda. Admite runners efímeros e instancias Spot. Arquitectura del proyecto.

Usa el ejemplo del proyecto que corresponda a tu configuración y fija la versión del módulo. Proporciona tu VPC, subredes, GitHub App e imagen de runner y, después, revisa los permisos de IAM y el plan de Terraform antes de aplicarlo. Prevé jobs de Spot interrumpidos, fallos de aprovisionamiento e instancias huérfanas. Incluye en la factura EC2, discos, logs, servicios de red y los recursos de AWS del controlador.

Elige esta configuración si la política exige que los runners estén en tu cuenta de AWS. Tu equipo sigue aplicando parches a las imágenes y gestionando los fallos. No hemos desplegado esta configuración de Terraform para el artículo.

¿Puedes usar runners autoalojados de forma segura para repositorios públicos?

No de forma predeterminada. GitHub recomienda runners autoalojados solo para repositorios privados porque un pull request de un fork puede ejecutar código controlado por un atacante en la máquina. Los repositorios privados también requieren cuidado: alguien con permiso para crear un fork y abrir un pull request podría ejecutar código en el entorno de tu runner. Guía de seguridad de GitHub.

Para contribuciones públicas, los runners alojados en GitHub son un punto de partida más seguro. No conectes la VM persistente de este tutorial a un repositorio público. Si debes autoalojar código no confiable, usa un entorno aislado y desechable por job con credenciales y acceso a la red restringidos. Un registro efímero por sí solo no proporciona ese límite de aislamiento.

• Mantén las claves SSH, las credenciales de administrador de la nube y los datos de producción fuera de los discos de runners. Usa credenciales de corta duración y ámbito limitado siempre que sea posible.
• Separa los repositorios con distintos niveles de confianza mediante grupos de runners y entornos de ejecución separados. Una etiqueta personalizada no es un control de acceso.
• No hagas checkout ni ejecutes un pull request no confiable en un workflow privilegiado de pull_request_target. Revisa los permisos de eventos y las políticas de aprobación de ejecuciones desde forks.
• Restringe el acceso a los servicios internos y a los endpoints de metadatos de la nube. Permite los endpoints de GitHub que necesiten tus jobs, además de sus registros de dependencias; una conectividad solo saliente sigue permitiendo el robo de datos.
• Trata las cachés como estado compartido. No permitas que jobs no confiables escriban datos que después ejecutará una compilación privilegiada.

Estos controles siguen la guía de uso seguro de GitHub. Su referencia de comunicación enumera los dominios necesarios para actualizaciones de runners, acciones, logs, artefactos y cachés.

Mantén actualizados el runner y su imagen

La referencia de runners de GitHub exige que los runners con actualizaciones automáticas desactivadas se actualicen en un plazo de 30 días desde una nueva versión, incluidas las versiones de parche. GitHub deja de enviar trabajo a la cola de los runners desactualizados; una actualización de seguridad crítica obligatoria puede bloquear los jobs antes. Política de actualizaciones de GitHub.

El runner normalmente se actualiza solo. Usa --disableupdate únicamente si tu equipo reconstruye las imágenes de runners dentro de ese plazo. Las actualizaciones del agente no aplican parches a Ubuntu, Docker ni a tus herramientas de compilación. Sustituye las máquinas o retíralas de la asignación de nuevos jobs para realizar mantenimiento sin interrumpir los jobs activos.

¿Por qué el runner está desconectado o el job está esperando?

Un job espera cuando ningún runner conectado e inactivo coincide con sus etiquetas y el ámbito o grupo permitido. Un runner desconectado ha dejado de escuchar o no puede comunicarse con GitHub. La referencia de asignación de jobs a runners de GitHub indica que los jobs en cola fallan después de más de 24 horas.

La referencia de resolución de problemas de GitHub cubre el estado del runner, los logs, la conectividad y los permisos de Docker.

En la máquina con systemd, revisa, por ejemplo, las últimas 100 líneas del registro y, después, los archivos de diagnóstico y el uso del disco:

sudo ./svc.sh status
sudo journalctl -u "$(cat .service)" -n 100 --no-pager
ls -lt _diag/
df -h

En _diag, los archivos Runner_ describen el proceso de escucha y los archivos Worker_ describen los jobs individuales. Consérvalos antes de destruir runners efímeros. Si el job nunca se inició, lee el log Runner_ más reciente; si se inició y falló, lee su log Worker_ y la salida del job.

¿Cuánto cuesta una máquina para un runner autoalojado?

Presupuesta la máquina y su mantenimiento: parches de imágenes, limpieza del disco, monitorización y jobs fallidos.

A fecha del 4 de noviembre de 2026, la documentación de facturación de GitHub sigue indicando que el cómputo autoalojado es gratuito tras el aplazamiento del cargo propuesto; consulta la lista completa de precios de GitHub Actions para ver los cargos y el uso incluido.

Ejemplo: una VM de Linux siempre activa

El 4 de noviembre de 2026, la tabla de precios de Basic Regular Droplet de DigitalOcean indicaba 2 vCPU compartidas, 4 GiB de RAM, 80 GiB de SSD y 4,000 GiB de transferencia por $24 al mes. Su documentación de facturación indica que los Droplets con recursos incluidos en un paquete siguen facturándose mientras están apagados; destruye el Droplet para detener el cargo.

Supón que la VM se ejecuta todo el mes en NYC3, donde están disponibles los Basic Droplets, procesa las compilaciones de tu repositorio privado de una en una y no tiene créditos ni uso que supere lo incluido en el paquete. Este ejemplo de presupuesto excluye impuestos, copias de seguridad, snapshots, almacenamiento o tráfico adicional, cargos de GitHub y tiempo del operador; no hace ninguna afirmación de rendimiento.

El importe de la VM se mantiene en $24 tanto si procesa jobs ocasionales como si permanece ocupada bajo esos supuestos. Asigna a alguien su mantenimiento antes de depender de ella para publicar versiones.

Compara facturas mensuales completas usando el historial reciente de jobs, incluida la capacidad inactiva y los reintentos, y aplica tu asignación de runners alojados en GitHub antes de comparar el uso de pago.

¿Cuándo es mejor elegir un runner gestionado?

Los runners de GitHub Actions en Lizard ejecutan actions/runner de GitHub a partir de una configuración JIT en una VM nueva de Firecracker por job; el registro del runner se elimina después. Lizard conserva un disco de caché solo para repositorios privados, y los jobs de forks nunca se ejecutan con él. Los pull requests y otras ramas pueden leer la caché, pero solo los pushes, las ejecuciones programadas y las ejecuciones manuales de la rama predeterminada guardan datos en ella.

Lizard Pro cuesta $19 al mes, impuestos incluidos, con $19 de uso incluido; ese es el mínimo mensual, y el uso por encima de él sigue el modelo pay as you go. El tiempo de VM de los runners se factura por segundo, incluidos el tiempo de preparación y el tiempo inactivo.

Los runners de Lizard admiten solo Linux x64 en Ubuntu 24.04 y organizaciones de GitHub, no cuentas personales. Un administrador de la organización instala la Lizard GitHub App. La prueba de 7 días requiere una tarjeta, incluye $5 de uso y permite solo runners Small, con un máximo de 4 vCPU a la vez; las cargas de trabajo se pausan cuando se agota el uso de prueba, a menos que actives Pro.

Usa la etiqueta Small para un job de prueba:

runs-on: lizard-small-ubuntu-2404

Los jobs de Windows, macOS y ARM se quedan en GitHub; elige un proveedor adecuado para los jobs de GPU. Haz pruebas de rendimiento de los proveedores si te importa que la compilación tarde lo menos posible, usa una configuración en tu propia nube si es obligatorio y conserva los runners gratuitos alojados en GitHub para proyectos públicos cuando cubran tus necesidades. Consulta la comparación de runners gestionados y otras plataformas de CI.

Lizard fue más barato y más lento en nuestra compilación de frontend; consulta la compilación medida y la configuración de runners de Lizard y, después, prueba un job de Linux de confianza y compara su tiempo de ejecución, factura total y mantenimiento.

Preguntas frecuentes

¿Cómo configuras variables de entorno en un runner autoalojado de GitHub Actions? Pon BUILD_MODE=test en actions-runner/.env, por ejemplo, y reinicia el servicio con sudo ./svc.sh stop y sudo ./svc.sh start. Usa líneas literales NAME=value, sin export, expansión del shell ni comillas alrededor de los valores. Las instrucciones de proxy de GitHub documentan el uso de .env; el parser del runner lo lee al arrancar, mientras que env.sh guarda PATH por separado en .path. Los jobs pueden leer estos valores, así que usa env: del workflow para la configuración de los jobs y los secretos de GitHub para las credenciales. Mantén .env fuera del control de versiones.

¿Los runners autoalojados de GitHub son gratuitos? A fecha del 4 de noviembre de 2026, GitHub no cobra por el cómputo autoalojado, según su documentación de facturación. Tú sigues pagando la máquina y su mantenimiento.

¿Un runner autoalojado necesita un puerto entrante abierto? No. Los requisitos de comunicación de GitHub exigen HTTPS saliente por el puerto 443; el runner no necesita un puerto entrante para webhooks.

¿Cuánto dura un token de registro de runner? Las instrucciones de configuración de runners de GitHub indican una hora. Genera un token nuevo si el registro falla porque ha caducado.