Runner self-hosted de GitHub Actions en un Cloud Server: instalacion y seguridad

Un servidor cloud te da libertad para desplegar aplicaciones, automatizaciones y bases de datos, pero esa libertad tambien exige criterio operativo.

En esta guia vas a ver una implementacion practica de runner self-hosted de github actions en un cloud server: instalacion y seguridad, con comandos orientados a Ubuntu/Debian, puntos de verificacion y advertencias para no romper disponibilidad ni seguridad.

La idea no es memorizar comandos sueltos, sino dejar un flujo repetible: preparar el servidor, instalar la herramienta, configurar lo minimo seguro, probar que funciona y cerrar con controles de seguridad.

¿Qué es?

Un runner self-hosted es una maquina que ejecuta jobs de GitHub Actions bajo tu control. Sirve para CI/CD con dependencias privadas o ambientes especificos, pero tambien amplia la superficie de riesgo porque ejecuta codigo definido en workflows.

¿Cuándo conviene usarlo?

Necesitas acceso a una red privada o a servicios internos.
Tus builds requieren herramientas o recursos no disponibles en runners hospedados.
Quieres controlar costos o tiempos de jobs repetitivos.

Requisitos previos

Repositorio u organizacion con permisos para agregar runners.
Cloud Server Ubuntu/Debian.
Usuario dedicado.
Politica clara para workflows autorizados.

Puertos necesarios

22/tcp para administracion SSH
salida HTTPS hacia GitHub
puertos internos solo si el job despliega en servicios locales

Paso 1: Crear usuario aislado

Evitar que el runner opere como root.

sudo adduser --disabled-password --gecos '' gha-runner
sudo usermod -aG docker gha-runner

Advertencia: Dar acceso a Docker equivale a privilegios altos; usalo solo si el workflow lo necesita.

Paso 2: Registrar runner en GitHub

Obtener URL y token desde la configuracion del repo u organizacion.

mkdir actions-runner && cd actions-runner
./config.sh --url URL --token TOKEN

Advertencia: Los tokens de registro son sensibles y temporales; no los pegues en chats o repositorios.

Paso 3: Instalar como servicio systemd

Mantener el runner activo tras reinicios.

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

Advertencia: Instala el servicio despues de configurar el runner correctamente.

Paso 4: Restringir uso por repositorio y etiquetas

Evitar que cualquier workflow lo use por accidente.

labels: self-hosted,linux,donweb-cloud
runs-on: [self-hosted, linux, donweb-cloud]

Advertencia: GitHub recomienda mucha cautela con runners self-hosted en repos publicos.

Paso 5: Monitorear y rotar

Revisar logs, actualizaciones y jobs sospechosos.

journalctl -u actions.runner* -n 100 --no-pager
du -sh _work
./svc.sh stop

Advertencia: Limpia workspaces y secretos; un runner persistente conserva estado entre trabajos si no lo gestionas.

Reforzar seguridad

Antes de dar por terminado el despliegue, revisa tres puntos: que el servicio publico sea realmente el que querias publicar, que los puertos internos no hayan quedado expuestos y que los secretos no esten en archivos versionados o historiales de shell. Si el procedimiento toca bases de datos, runners, automatizaciones o certificados, prueba primero en un entorno secundario.

Tambien conviene documentar como se reinicia, como se actualiza, donde estan los logs y cual es el comando de verificacion rapida. Esa informacion vale mucho cuando otra persona del equipo tiene que intervenir.

Problemas frecuentes

El runner aparece offline

Revisa el servicio systemd, conectividad saliente y token/configuracion.

Jobs quedan en cola

Confirma etiquetas runs-on y permisos del runner group.

Builds llenan disco

Limpia _work y configura retencion de artefactos/cache.

Conclusión

En DonWeb Cloud, un runner self-hosted puede acercar CI/CD al entorno donde despliegas. La clave es tratarlo como infraestructura sensible, no como una terminal descartable.