¿Cómo ejecuto un runner autoalojado de GitHub Actions en un VPS?

Aprovisiona un VPS Linux (Small — 4 vCPU / 4 GB — es la opción por defecto sensata), instala el paquete del runner desde Settings → Actions → Runners de tu repositorio, regístralo con el token que da GitHub y arráncalo como servicio. Los pasos completos para copiar y pegar están abajo; obtienes root en aproximadamente un minuto.

¿Puedo ejecutar el runner en Docker?

Sí. Ejecuta la imagen oficial del runner (o la tuya) en un contenedor, o úsalo para dar a cada job un entorno aislado y desechable. No se requiere IP dedicada — el runner solo hace conexiones salientes a GitHub, así que un plan NAT también sirve.

¿Cómo mantengo el runner en marcha como servicio?

El runner incluye un script de ayuda svc.sh que instala una unidad systemd: ./svc.sh install && ./svc.sh start. Luego sobrevive a los reinicios y se reinicia si falla. La guía de abajo muestra los comandos exactos.

¿Es un runner autoalojado más barato que los minutos alojados por GitHub?

Para CI pesado o frecuente, sí. Los runners alojados por GitHub facturan por minuto más allá del nivel gratuito; un VPS de 8 $/mes ejecuta minutos ilimitados por una tarifa fija y se mantiene «caliente» (sin arranque en frío, con dependencias en caché). Un repositorio activo suele pagar la máquina por sí solo.

¿Piden identificación o tarjeta de crédito?

No. Registro con correo, pago con USDC o USDT. Sin documentos, sin tarjeta, nunca KYC.

VPS para runners autoalojados de GitHub Actions

Ejecuta tu propio runner autoalojado de GitHub Actions en un VPS — CI más rápido, sin facturación por minuto, control total del entorno de compilación. Pago en cripto, sin KYC. Desde 8 $/mes.

Los runners alojados por GitHub son cómodos hasta que la factura o el tiempo de espera empiezan a doler. Más allá del nivel gratuito pagas por minuto, cada job arranca «en frío» y vuelve a descargar dependencias en cada ejecución. Un runner autoalojado en tu propio VPS invierte los tres puntos: coste mensual fijo, una máquina «caliente» con tus cachés ya en disco y un entorno de compilación que controlas por completo — versiones concretas de herramientas, más RAM, una caché de capas de Docker que realmente persiste.

Un runner solo necesita alcanzar GitHub de salida, así que funciona en nuestros planes más baratos, se paga en cripto y no requiere KYC.

Qué necesita un runner

CPU y RAM para tus builds. Small (8 $/mes — 4 vCPU, 4 GB RAM, 35 GB NVMe) es la opción cómoda para la mayoría de CI: builds de Node/Go/Rust, suites de pruebas, builds de imágenes Docker. ¿Compilación pesada o jobs en paralelo? Sube a Medium o a un plan Pro.
Disco NVMe para cachés. Todo el sentido del autoalojamiento es la persistencia — cachés de dependencias, capas de Docker y artefactos de build permanecen en disco entre ejecuciones. El NVMe mantiene rápidas las restauraciones.
No se necesita IP dedicada. El runner llama a GitHub por HTTPS; no requiere acceso entrante. Un plan NAT (desde 3 $/mes) basta. Toma una IP dedicada solo si además alojas algo que sirve tráfico.

Configurar un runner (Ubuntu 24.04)

Crea el runner en tu repositorio (u organización): Settings → Actions → Runners → New self-hosted runner → Linux. GitHub muestra un comando de descarga y un token de registro de un solo uso. En el VPS:

# como usuario no root (el runner se niega a ejecutarse como root)
adduser --disabled-password --gecos "" runner
su - runner

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
  https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz

# registrar con la URL + el token de la interfaz de GitHub
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

Mantenerlo como servicio

No ejecutes ./run.sh en una terminal — instala el runner como servicio systemd para que sobreviva a los reinicios:

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

El runner aparece ahora como Idle en la interfaz de GitHub y toma cualquier job que lo apunte.

Usarlo desde un workflow

Dirige un job a tu runner con runs-on:

jobs:
  build:
    runs-on: self-hosted        # o una etiqueta personalizada que definas al registrar
    steps:
      - uses: actions/checkout@v4
      - run: make build && make test

Jobs basados en Docker

Instala Docker una vez y tus workflows podrán construir imágenes o ejecutar contenedores de servicio, con la caché de capas persistiendo entre ejecuciones:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner   # permitir al runner usar Docker sin sudo

Para aislamiento desechable por job, ejecuta el propio runner dentro de un contenedor y recréalo en cada ejecución — un patrón común para builds no confiables o en matriz.

Por qué EQVPS para CI

Coste fijo, minutos ilimitados. Sin medición por minuto — un pipeline ocupado cuesta lo mismo que uno inactivo.
Cachés «calientes». Dependencias y capas de Docker permanecen en NVMe entre ejecuciones; los builds se aceleran, no se ralentizan.
Root en ~60 segundos, imágenes limpias. Ubuntu, Debian y más vía cloud-init; instala exactamente la cadena de herramientas que necesitas.
Sin KYC, pago en cripto. Correo para registrarte, USDC/USDT para pagar. Levanta runners extra para los picos de release y cancélalos después.

Guía de configuración completa paso a paso →