VPS para CI/CD runner: GitHub Actions self-hosted runner

Para un funcionamiento eficaz de un GitHub Actions self-hosted runner, lo óptimo es utilizar un VPS con 4 GB de memoria RAM, 2 vCPU y un disco NVMe; esta configuración garantiza una compilación estable de contenedores Docker y acelera los procesos de CI/CD entre 5 y 10 veces en comparación con los runners gratuitos estándar de GitHub.

¿Por qué GitHub Actions self-hosted es el estándar para el desarrollo profesional?

El uso de runners en la nube de GitHub es conveniente para pequeños proyectos Open Source, pero el desarrollo profesional choca rápidamente con limitaciones: procesadores lentos, límites de tiempo de compilación (2000 minutos al mes en el plan gratuito) y falta de control sobre el entorno. Mover los procesos a su propio VPS para CI/CD resuelve estos problemas, proporcionando recursos dedicados que no se comparten con otros usuarios.

Aceleración de compilación y almacenamiento en caché

El principal factor de aceleración es el almacenamiento local de datos. En la nube de GitHub, cada ejecución comienza desde un "lienzo en blanco": las dependencias (node_modules, paquetes de Go, caché de Maven) se descargan de nuevo o se restauran desde una caché de red, lo que consume hasta el 70% del tiempo del pipeline. En un self-hosted runner en VPS, la caché se guarda en el disco físico. Por ejemplo, la compilación de una aplicación React pesada, que en la nube tarda 8 minutos, en un VPS con disco NVMe se reduce a 45–60 segundos gracias al acceso instantáneo a las capas de Docker y dependencias ya descargadas.

Eficiencia económica al escalar

Los minutos gratuitos de GitHub se agotan rápido, y el coste de los minutos adicionales en la nube es desproporcionadamente alto. Alquilar un único VPS potente permite ejecutar decenas o cientos de builds al día sin costes adicionales. Esto es especialmente importante para equipos que utilizan Sentry self-hosted u otras herramientas de monitoreo que requieren despliegues frecuentes y pruebas de integración.

Elección de la configuración de VPS para CI/CD según las tareas

El rendimiento del actions runner depende directamente de los recursos asignados. Para compilar proyectos pesados en C++ o Java se requiere una alta frecuencia de procesador y volumen de RAM, mientras que para el despliegue de sitios estáticos bastan recursos mínimos.

Tabla comparativa de características de VPS para runners

Tipo de proyecto CPU recomendado RAM (GB) Disco (NVMe) Rendimiento (vs Cloud) Frontend (React/Vue/Next.js) 2 vCPU (3.0+ GHz) 4 GB 40 GB 5x más rápido Backend (Go/Rust/Java) 4-8 vCPU 8-16 GB 80 GB 8x más rápido Docker-heavy (Microservicios) 4 vCPU 8 GB 100 GB 10x más rápido Móvil (Android/iOS) 8 vCPU 16+ GB 200 GB Depende de la emulación Al elegir un servidor, es importante considerar no solo el número de núcleos, sino también su arquitectura. Los procesadores modernos con frecuencias superiores a 3 GHz reducen significativamente el tiempo de ejecución de las pruebas unitarias, que a menudo funcionan en un solo hilo.

Instalación paso a paso de GitHub Actions self-hosted en Ubuntu

El proceso de instalación no toma más de 10 minutos. Para empezar, necesitará un VPS limpio con Ubuntu 22.04 o 24.04. Se recomienda crear un usuario independiente para ejecutar el runner y evitar el uso de root por motivos de seguridad.

Preparación del sistema y creación de usuario

sudo useradd -m -s /bin/bash github-runner
sudo usermod -aG sudo github-runner
sudo apt update && sudo apt upgrade -y
# Instalación de dependencias necesarias
sudo apt install -y curl git jq build-essential libssl-dev libffi-dev python3

Registro del runner en el repositorio

Vaya a la configuración de su repositorio en GitHub: Settings -> Actions -> Runners -> New self-hosted runner. Seleccione Linux y siga las instrucciones para descargar el archivo. Ejemplo de comandos para la descarga (la versión puede variar):

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64-2.311.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz
tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz
./config.sh --url https://github.com/OWNER/REPO --token YOUR_TOKEN

Tras completar la configuración, el script le preguntará el nombre del runner y las etiquetas (labels). Las etiquetas son críticas para la gestión: puede marcar un servidor como `production`, `gpu` o `high-performance` para dirigir tareas específicas a los nodos adecuados.

Configuración de Docker-in-Docker y trabajo con contenedores

La mayoría de los pipelines de CI/CD modernos utilizan Docker para compilar imágenes o ejecutar pruebas en entornos aislados. Para que el github actions self hosted pueda interactuar con Docker, es necesario configurar correctamente los permisos de acceso e instalar Docker Engine en la máquina host.

Instalación de Docker para el runner

sudo apt install -y docker.io
sudo usermod -aG docker github-runner
# Reiniciar para aplicar los permisos
sudo systemctl restart docker

El uso de Docker en un self-hosted runner ofrece la ventaja de un registro de imágenes local. Si recompila con frecuencia los mismos microservicios, las capas de Docker se tomarán de la caché local `/var/lib/docker`, lo que prácticamente elimina el tiempo de `docker pull`. Para gestionar secretos y accesos a registros privados, es conveniente utilizar Bitwarden self-hosted integrado en el proceso de compilación.

Seguridad: Docker Socket vs Rootless

Por defecto, el runner utiliza `/var/run/docker.sock`. Esto otorga a los procesos dentro del contenedor privilegios de root en la máquina host. Si su CI/CD ejecuta código de Pull Requests externos, esto supone un riesgo de seguridad. En tales casos, se recomienda usar el `Docker Rootless mode` o ejecutar el runner en modo `ephemeral` (de un solo uso), que elimina todos los datos al finalizar la tarea.

Comparación con GitLab Runner: diferencias arquitectónicas en VPS

Aunque la arquitectura de GitHub Actions y GitLab CI es similar, GitLab Runner ofrece capacidades de escalado más flexibles en un solo servidor. En GitLab, un único archivo binario puede gestionar múltiples hilos de compilación paralelos (executors).

Ventajas de GitLab Runner para CI/CD

• Executors: Posibilidad de elegir entre Shell, Docker, VirtualBox o Kubernetes directamente en la configuración del runner.
• Auto-scaling: GitLab Runner puede crear automáticamente VPS adicionales cuando aumenta la carga y eliminarlos después.
• Integración: Conexión profunda con Container Registry y clústeres de Kubernetes.

Para un funcionamiento estable de GitLab Runner en un VPS, se recomienda asignar al menos 2 GB de RAM por cada hilo de compilación paralelo (concurrent job). Si planea una automatización compleja de flujos de trabajo, considere también n8n self-hosted para vincular CI/CD con APIs externas y notificaciones.

Seguridad e aislamiento del VPS del self-hosted runner

El principal riesgo de usar un self-hosted runner en VPS es la ejecución de código arbitrario. Si un atacante envía un Pull Request con código malicioso en `.github/workflows/build.yml`, podría obtener acceso al sistema de archivos del servidor y a sus secretos (claves API, contraseñas de bases de datos).

Estrategias de protección del servidor

1. VM dedicada: Nunca ejecute el runner en el servidor donde reside su producción principal. Utilice una instancia de VPS independiente.
2. Restricción de privilegios: Ejecute el proceso del runner con un usuario sin privilegios de sudo.
3. Cortafuegos de red: Configure el Firewall (UFW) para permitir solo conexiones salientes hacia GitHub y denegar las entrantes en todos los puertos, excepto SSH.
4. Limpieza regular: Utilice tareas Cron en el VPS para limpiar automáticamente imágenes de Docker antiguas y archivos temporales de compilación.

Para limpiar el sistema de basura de Docker, puede añadir la siguiente tarea al crontab:

0 3 * * * /usr/bin/docker system prune -af --volumes

Esto eliminará diariamente a las 3 de la mañana los datos no utilizados, evitando que el disco se llene.

Optimización del rendimiento: cómo exprimir al máximo el hardware

Para lograr una aceleración de 10 veces, no basta con instalar el actions runner. Es necesario optimizar la estructura misma del pipeline.

Uso de disco RAM para archivos temporales

Si su proyecto genera miles de archivos pequeños durante la compilación, el uso de un disco RAM (tmpfs) puede acelerar significativamente el proceso. Asigne una parte de la memoria RAM a `/tmp` o a una carpeta de compilación específica.

Caché local de dependencias

En lugar del estándar `actions/cache`, que descarga archivos de la red, configure sus herramientas para usar rutas locales en el disco del VPS. Para Node.js, esto puede ser la caché global de npm:

npm config set cache /home/github-runner/.npm --global

Esto elimina los retrasos de red y la carga en el canal de comunicación.

Monitoreo y mantenimiento de la infraestructura

Una solución self-hosted requiere supervisión. Las métricas principales a seguir son: espacio libre en disco, uso de RAM y carga de CPU (Load Average).

Actualización automática del runner

GitHub actualiza automáticamente los archivos binarios del runner, pero las dependencias del sistema (git, docker, python) deben actualizarse manualmente o mediante scripts de automatización. Se recomienda configurar notificaciones en caso de que el proceso del runner falle. La forma más sencilla es usar una unidad de systemd que reinicie automáticamente el servicio tras un fallo.

[Unit]
Description=GitHub Action Runner
After=network.target

[Service]
Type=simple
User=github-runner
WorkingDirectory=/home/github-runner/actions-runner
ExecStart=/home/github-runner/actions-runner/run.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Esta configuración garantiza que su VPS para CI/CD esté disponible 24/7. Para almacenar la documentación de sus procesos de CI/CD y configuraciones de servidores, Nextcloud self-hosted es una excelente opción donde el equipo puede editar archivos e instrucciones de forma colaborativa.

Conclusiones

Para un funcionamiento estable de CI/CD basado en GitHub Actions self-hosted runner, lo más adecuado es un VPS con 4-8 GB de RAM y almacenamiento NVMe, lo que permite reducir drásticamente el tiempo de compilación y controlar totalmente la seguridad de los datos. El uso de un servidor propio elimina los límites de minutos gratuitos y ofrece la posibilidad de una optimización profunda del almacenamiento en caché para acelerar el desarrollo.