¿Por qué ejecutar mi propio runner en lugar del alojado por GitHub?

Tres razones reales: tus propias dependencias y toolchain integradas (sin reinstalarlas en cada ejecución), acceso a recursos privados como una registry interna o una base de datos, y control sobre la máquina — su tamaño, sus cachés, su red. Si los minutos alojados por GitHub y un entorno limpio te sirven, quédate en ellos. Autoaloja cuando necesites específicamente una de esas tres.

¿Es seguro usar un runner autoalojado?

En un repo privado, sí. En un repo público, no — nunca. Un workflow ejecuta código arbitrario de quien lo dispare, y en un repo público el pull request de un desconocido puede ejecutar su código en tu runner. La propia documentación de GitHub dice lo mismo. Mantén los runners autoalojados en repos privados, o acepta que estás entregando tu máquina a internet.

¿Cuánta CPU y RAM necesita un runner?

Depende por completo de tu build. Un trabajo típico de compilar-y-testear está cómodo con 2 núcleos y 4-8 GB — Small o Medium aquí. Los builds pesados (grandes compilaciones nativas, imágenes de Docker grandes, suites de tests ávidas de memoria) quieren más, y deberías dimensionar a tu trabajo real, no a una suposición. Vigila una ejecución real y lo sabrás.

¿Puede un runner manejar varios repos?

Un runner puede registrarse en una organización y ser recogido por varios repos, un trabajo a la vez por defecto. Para más paralelismo, ejecuta más runners — cada uno es su propio servicio systemd. Solo mantenlos todos en repos privados.

¿Necesito daros un documento?

No. Correo para registrarse, USDC o USDT para pagar. Sin documentos, root en aproximadamente un minuto.

Ejecutar un runner de GitHub Actions autoalojado en un VPS

Los runners alojados por GitHub son un buen valor por defecto. Dejas de necesitarlos en el momento en que un build quiere algo que no tienen — tu registry de paquetes privada, una versión específica de toolchain que estás cansado de reinstalar en cada ejecución, una base de datos en tu propia red, o simplemente más control sobre la máquina. Ahí es cuando un runner autoalojado en un VPS se gana su sustento.

Esta guía pone uno a funcionar correctamente: instalado, registrado, vivo bajo systemd, y — la parte que la gente hace mal — seguro. Empecemos por esta última, porque es la parte que muerde.

La única regla de seguridad

Un workflow de GitHub Actions ejecuta código arbitrario — lo que sea que esté en el archivo del workflow, y lo que sea que ese código arrastre. En tu propio repo es tu código, y está bien. En un repo público, un pull request de un desconocido puede ejecutar su código en tu runner. Eso no es un bug; es cómo funciona la CI. La propia documentación de GitHub lo dice claramente: no uses runners autoalojados con repositorios públicos.

Así que la regla es simple y no negociable: los runners autoalojados son para repos privados. Si tu repo es público, usa runners alojados por GitHub y sigue adelante. Todo lo de abajo asume un repo privado.

Qué necesita un runner de la máquina

Depende del build, y deberías dimensionar al tuyo en lugar de a un número de una página:

Un trabajo típico de compilar-y-testear — 2 núcleos y 4-8 GB es cómodo. Small (8 $, 4 vCPU / 4 GB) o Medium (12 $, 6 vCPU / 6 GB) cubre la mayoría de estos.
Builds más pesados — grandes compilaciones nativas, grandes builds de imágenes de Docker, suites de tests ávidas de memoria — quieren más margen. Vigila una ejecución real (htop mientras compila) y dimensiona a lo que de verdad ves, no a la esperanza.

El disco también importa: cachés de build, capas de Docker y repos clonados se acumulan. Mantén un ojo en él y prune.

1. Prepara la máquina

Crea un usuario no-root para el runner — el instalador de GitHub se niega a ejecutarse como root de todos modos, y lo quieres así:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # solo si tus builds genuinamente necesitan sudo

Instala lo que tus builds necesiten — una toolchain de lenguaje, Docker, herramientas de build. Por ejemplo, si tus trabajos construyen contenedores:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. Descarga y registra el runner

En tu repo (u org) en GitHub, ve a Settings → Actions → Runners → New self-hosted runner. GitHub te da los comandos de descarga exactos y un token de registro (es de corta duración — cógelo fresco). Como el usuario runner:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# usa la URL exacta que GitHub te muestra para tu OS/arch:
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh pide un nombre de runner, etiquetas y una carpeta de trabajo — los valores por defecto están bien para empezar. Las etiquetas son cómo tu workflow apunta a este runner (runs-on: self-hosted).

3. Ejecútalo como un servicio systemd

El runner viene con un ayudante que instala un servicio systemd por ti — úsalo, para que el runner sobreviva a los reinicios y se reinicie en los fallos. Aún como la instalación del usuario runner, pero los comandos de servicio necesitan root:

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

Eso registra actions.runner.* como una unidad systemd que corre como el usuario runner, arrancando al inicio. Los logs van a journald:

sudo journalctl -u 'actions.runner.*' -f

De vuelta en la página de Runners de GitHub, tu runner ahora muestra Idle — punto verde. Apunta un workflow a él:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

Haz push, y el trabajo corre en tu máquina.

4. Mantenlo limpio

Un runner autoalojado reutiliza su sistema de archivos entre trabajos — esa es la ganancia de velocidad (cachés calientes) y la trampa (estado sobrante). Dos costumbres lo mantienen sano:

Prune con regularidad. Docker especialmente — docker system prune en un cron, o el disco se llena en silencio de capas muertas.
No almacenes secretos en la máquina. Usa los secretos de GitHub Actions, inyectados por ejecución, no archivos en el home del runner. Si el runner es comprometido, todo lo que esté en disco se va con él.

Si necesitas un entorno de verdad limpio por trabajo, ejecuta cada trabajo dentro de un paso de contenedor — el runner se queda, el desorden del trabajo no.

Cuándo autoalojar, con honestidad

Autoaloja cuando necesites tu propia toolchain integrada, acceso a recursos de red privados, o control sobre la máquina. Quédate en runners alojados por GitHub cuando un entorno limpio y desechable y sus minutos te sirvan — eso es genuinamente más simple, y más simple vale algo. Y nunca, en un repo público, autoalojes. Esa no es una preferencia.

Si un runner de repo privado es lo que necesitas: elige un plan — Small (8 $) para builds más ligeros, Medium (12 $) cuando se ponen más pesados — paga en USDC o USDT (sin KYC, sin documentos), y tendrás root en unos 60 segundos. Luego trabaja esta página hacia abajo y tendrás un runner recogiendo trabajos unos minutos después.