# ¿Cómo configuro un runner de GitHub Actions autoalojado en un servidor dedicado alquilado?

> Configura un runner de GitHub Actions autoalojado en un servidor dedicado en 8 pasos según la documentación de GitHub. Criptomonedas, sin KYC, desde 91,65 US$.

- URL: https://lumenfer.com/es/github-actions-runner-dedicated-server/
- Última actualización: 2026-11-01
- Editor: Lumenfer (https://lumenfer.com)

Registra un runner en una máquina Linux alquilada, ejecútalo como servicio bajo su propio usuario y mantén el código no confiable lejos de él. Cada comando y regla a continuación proviene de la documentación de GitHub.

**Respuesta rápida — ¿Cómo configuro un runner de GitHub Actions autoalojado en un servidor dedicado alquilado?**

Para configurar un runner de GitHub Actions autoalojado en un servidor dedicado alquilado, crea primero un usuario que no sea root. Luego abre Settings → Actions → Runners → New self-hosted runner y ejecuta los comandos que muestra GitHub, después `sudo ./svc.sh install` para mantenerlo en ejecución. Úsalo solo en repositorios privados. Los servidores **Lumenfer** empiezan en 91,65 US$ por 30 días, pagados con criptomonedas y sin KYC.

## Lo que necesita el runner, según la referencia de GitHub

| Atributo | Valor |
| --- | --- |
| Red | HTTPS de salida en el puerto 443 hacia github.com, api.github.com y *.actions.githubusercontent.com; al menos 70 kbit/s en cada dirección |
| Sistemas Linux | Ubuntu 20.04 o posterior y Red Hat Enterprise Linux 8 o posterior, entre otros, en x64 |
| Trabajos en contenedor | Una máquina Linux con Docker instalado |
| Actualizaciones del runner | Automáticas cuando se asigna un trabajo; debes actualizar dentro de los 30 días posteriores a una nueva versión |
| Límites de trabajos | Hasta 5 días por trabajo; un trabajo en cola durante 24 horas se cancela |
| Runners sin conexión | Se elimina tras 14 días sin conectarse; los runners efímeros, tras 1 día |
| Imágenes en Lumenfer | Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10 y Proxmox VE 9 |
| Acceso | You log in as root over SSH. Paste a public key when ordering and password logins stay disabled, or skip it and receive a temporary root password with the server, to replace on your first login |
| Configuración | Pocos minutos después de que se confirme el pago, y nunca más de una hora |

## ¿Qué necesito antes de instalar el runner?

**Necesitas permisos de admin en GitHub y root en una máquina Linux.** Para un runner de repositorio, GitHub te pide ser el propietario del repositorio, un propietario de la organización o un admin del repositorio. Un runner para toda la organización necesita un propietario de la organización.

En el lado del servidor, pide una imagen Ubuntu 24.04 LTS o Debian con tu clave pública SSH. Tu servidor entra en servicio pocos minutos después de que se confirme el pago, y la espera nunca pasa de una hora; el panel sigue la preparación y luego muestra la dirección IP en cuanto la máquina está en marcha. La dirección IP aparece en tu panel cuando la máquina está lista.

Elige el tamaño según tu job más pesado, no según la media. Nuestra [guía de hardware para servidores de build](https://lumenfer.com/es/build-server-hardware/ "What hardware a build server needs: cores, RAM and NVMe") explica cómo usan los núcleos y la memoria los compiladores y enlazadores.

## ¿Puedo usar un runner autoalojado en un repositorio público?

**Evítalo: GitHub recomienda los runners autoalojados solo para repositorios privados.** Cualquiera puede hacer un fork de un repositorio público y abrir un pull request. Ese pull request puede ejecutar código en tu máquina.

La referencia de seguridad de GitHub deja claro lo que está en juego. Un runner puede quedar comprometido de forma persistente por código de workflow no confiable. Ese código puede llegar después a secretos y al `GITHUB_TOKEN`. Los secretos de entorno y los revisores obligatorios no aíslan la máquina en sí.

- **Restringe el token.** Pon el permiso por defecto de `GITHUB_TOKEN` en solo lectura para el contenido de los repositorios y concede más por job.
- **Evita los disparadores privilegiados.** Nunca combines `pull_request_target` o `workflow_run` con un checkout de código de pull request no confiable.
- **Agrupa tus runners.** Los runners de organización pueden recibir jobs de muchos repositorios. Los grupos de runners mantienen un compromiso dentro de un mismo límite.
- **Mantén los secretos fuera del disco.** GitHub te pide minimizar el material sensible almacenado en el runner.

## ¿Cómo instalo el runner, paso a paso?

Estos pasos siguen tres páginas de GitHub Docs —sobre cómo añadir runners, ejecutarlos como servicio y usarlos en workflows— leídas el 1 de noviembre de 2026. Cada uno se ejecuta por SSH.

1. **Pide el servidor con tu clave SSH** — Elige Ubuntu 24.04 LTS o Debian al finalizar la compra y pega tu clave pública. Así los inicios de sesión con contraseña quedan desactivados.
2. **Actualiza el sistema y añade un usuario para el runner** — Ejecuta apt update && apt full-upgrade y luego crea un usuario sin privilegios, como gh-runner. Los jobs nunca deben ejecutarse como root.
3. **Instala Docker solo si los jobs usan contenedores** — GitHub necesita Docker en Linux para las container actions y los service containers. La documentación de Docker advierte que el grupo docker concede privilegios de nivel root.
4. **Abre la página New self-hosted runner** — En el repositorio, ve a Settings → Actions → Runners → New self-hosted runner y elige Linux y x64. Las organizaciones usan primero New runner.
5. **Ejecuta los comandos de GitHub como el usuario del runner** — Pega las líneas de descarga, checksum y ./config.sh --url … --token … en el orden mostrado. El token de registro caduca al cabo de una hora.
6. **Instala el runner como servicio** — Desde la carpeta del runner, ejecuta sudo ./svc.sh install gh-runner y luego sudo ./svc.sh start y sudo ./svc.sh status. Ahora sobrevive a los reinicios.
7. **Apunta un workflow a él** — Define runs-on: [self-hosted, linux, x64]. Un runner debe tener todas las etiquetas indicadas para aceptar el job.
8. **Blinda la configuración del repositorio** — Deja GITHUB_TOKEN en solo lectura por defecto y limita qué repositorios pueden usar el runner. Después ejecuta un job de prueba.

*Pasos 2, 5 y 6 en Ubuntu o Debian (la URL y el token vienen de tu página New runner)*

```bash
# step 2, as root: update and create the runner user
apt update && apt full-upgrade -y
adduser --disabled-password --gecos "" gh-runner

# step 5, as gh-runner, in the folder where you ran GitHub's download lines
./config.sh --url https://github.com/OWNER/REPO --token TOKEN
# for a runner that takes one job, then de-registers:
# ./config.sh --url https://github.com/OWNER/REPO --token TOKEN --ephemeral

# step 6, from the same folder, with sudo rights
sudo ./svc.sh install gh-runner
sudo ./svc.sh start
sudo ./svc.sh status
```

*Paso 7: un job que se ejecuta en el servidor alquilado*

```yaml
permissions:
  contents: read

jobs:
  build:
    runs-on: [self-hosted, linux, x64]
    steps:
      - uses: actions/checkout@v7
      - run: make -j"$(nproc)" test
```

## ¿Debería usar runners efímeros en un único servidor alquilado?

**Sí, para cualquier cosa que vaya más allá de código interno de confianza: GitHub recomienda runners efímeros, que toman un job y luego se dan de baja.** Añade `--ephemeral` cuando ejecutes `config.sh`. Tu propia automatización limpia entonces el workspace y registra un runner nuevo.

GitHub también ofrece runners just-in-time. El endpoint REST `POST /repos/{owner}/{repo}/actions/runners/generate-jitconfig` devuelve una configuración para un solo job. Para el registro clásico, `POST /repos/{owner}/{repo}/actions/runners/registration-token` devuelve un token válido durante una hora.

**Los runners de un solo job en el mismo host físico no son un borrón y cuenta nueva.** GitHub advierte que reutilizar el hardware para runners just-in-time puede exponer información del entorno. En bare metal, da a cada job una máquina virtual o un contenedor desechable.

- **Máquinas virtuales.** Pide la imagen Proxmox VE y clona una VM de plantilla por job. Consulta [cómo montar un clúster de Proxmox en servidores alquilados](https://lumenfer.com/es/proxmox-cluster-dedicated-servers/ "Proxmox cluster with rented dedicated servers").
- **Kubernetes.** Actions Runner Controller de GitHub es un operador de Kubernetes que escala runners autoalojados. Consulta [cómo ejecutar Kubernetes en bare metal](https://lumenfer.com/es/kubernetes-bare-metal/ "Kubernetes on bare metal servers").
- **Logs.** Un runner de un solo job no deja nada para inspeccionar después, así que GitHub te pide reenviar antes sus logs a un almacenamiento externo.

## ¿Cuántos runners puede soportar un servidor?

**Un proceso de runner toma un job, así que registra tantos runners como jobs en paralelo quieras, cada uno en su propia carpeta con su propio servicio.** Divide la máquina según tu job más pesado. Un reparto habitual es un runner por cada 4 a 8 hilos, con RAM para el peor paso de enlazado.

La tabla relaciona cada plan con un punto de partida razonable. Ajusta tras una semana observando `htop` y los tiempos de los jobs.

### Planes de Lumenfer como hosts de runners de CI

| Plan | CPU | Núcleos | Memoria | Discos | Cada 30 días | Buen comienzo |
| --- | --- | --- | --- | --- | --- | --- |
| Lumen 6 | AMD EPYC 4244P | 6 núcleos / 12 hilos | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | 1 a 2 runners: lint, tests unitarios, servicios pequeños |
| Lumen 8 | AMD Ryzen 7 9700X | 8 núcleos / 16 hilos | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | 2 a 4 runners: builds de Go, Rust o Java |
| Lumen 16 | AMD Ryzen 9 9950X | 16 núcleos / 32 hilos | 128 GB DDR5 | 2 × 1.92 TB NVMe | $205.27 | 4 a 8 runners, o un build grande de C++ |
| Lumen 24 | AMD EPYC 9254 | 24 núcleos / 48 hilos | 256 GB DDR5 ECC | 2 × 1.92 TB NVMe | $356.25 | VMs de runner en Proxmox, con memoria ECC |
| Lumen 32 | AMD EPYC 9354 | 32 núcleos / 64 hilos | 384 GB DDR5 ECC | 2 × 3.84 TB NVMe | $749.67 | Un pool de runners para toda una organización |

## ¿Qué gestionan los runners alojados en GitHub que ahora gestiono yo?

**La máquina limpia, las actualizaciones y la recuperación: GitHub te hace responsable del sistema operativo y de todo el demás software.**

- **Crecimiento del disco.** Los workspaces, las imágenes de Docker y las cachés se acumulan entre jobs. Programa una limpieza o el NVMe se llenará durante un release.
- **Actualizaciones del runner.** El runner se actualiza solo cuando recibe un job. Si te registras con `--disableupdate`, aun así debes actualizar en un plazo de 30 días.
- **Bloqueos.** No hay consola IPMI ni KVM-over-IP para los clientes: solicitas reinicios y reinstalaciones en el panel y el equipo los realiza. Prueba los cambios de firewall con una segunda sesión SSH abierta.
- **Correo de los builds.** El SMTP saliente por el puerto 25 está bloqueado en todos los servidores y nunca se desbloquea; los puertos de envío 465 y 587 hacia los proveedores de correo siguen abiertos.
- **Datos.** Las copias de seguridad no están incluidas: guarda copias de tus datos en otro sitio.

**En la comprobación de Lumenfer sobre 30 October 2026, los vendedores de servidores dedicados indicaron tiempos de configuración desde 30 minutos a 10 días hábiles, con una mediana de 24 horas.** Lumenfer está en el extremo rápido: un host de runner entra en marcha minutos después de confirmarse el pago, con una hora como límite. Los costes se comparan minuto a minuto en [runner autoalojado vs coste de GitHub-hosted](https://lumenfer.com/es/self-hosted-runner-vs-github-hosted-cost/ "Is a rented server cheaper than GitHub-hosted runners?"), y todos los planes están en la [página de precios de Lumenfer](https://lumenfer.com/es/pricing/ "Lumenfer plans and prices per 30 days").

## ¿Qué plan debería alojar mis runners?

Máquinas completas, un cliente cada una, facturadas desde un saldo en criptomonedas. Ámsterdam (Países Bajos), Reikiavik (Islandia), Zúrich (Suiza) y Bucarest (Rumanía): los cinco planes en las cuatro ciudades, un mismo precio en todas.

| Plan | Cantidad | 30 days | 3 months | 6 months | 1 year |
| --- | --- | --- | --- | --- | --- |
| Lumen 6 | 6 núcleos · 32 GB DDR5 | 91,65 US$ | 247,45 US$ (−10%) | 439,92 US$ (−20%) | 769,86 US$ (−30%) |
| Lumen 8 | 8 núcleos · 64 GB DDR5 | 109,37 US$ | 295,29 US$ (−10%) | 524,97 US$ (−20%) | 918,70 US$ (−30%) |
| Lumen 16 | 16 núcleos · 128 GB DDR5 | 205,27 US$ | 554,22 US$ (−10%) | 985,29 US$ (−20%) | 1724,26 US$ (−30%) |

En todos los planes: 2022+ CPU · DDR5 · Solo NVMe · RAID 1 · IPv4 dedicada · Sin KYC

**Antes de pagar**

- Recarga mínima 1 US$. Recarga una vez con criptomonedas y luego compra cualquier plan con tu saldo.
- Los créditos de tu saldo no caducan y renuevan cualquiera de tus servidores. Cuando una recarga se hace únicamente para alcanzar el mínimo, la parte no gastada se devuelve a petición dentro de los 30 días posteriores al pago, en USDT o USDC. El resto del saldo no se reembolsa salvo que la ley lo exija.
- Se acredita en cuanto comprobamos tu pago en la blockchain. Tiempo habitual de confirmación de la red: BTC ≈ 20 min · USDT TRC-20 ≈ 1 min · USDT ERC-20 ≈ 5 min · USDC ERC-20 ≈ 5 min · ETH ≈ 5 min · SOL ≈ 1 min · LTC ≈ 15 min · XMR ≈ 20 min

## GitHub runner autoalojado en un servidor alquilado: preguntas frecuentes

### ¿Puedo ejecutar el runner de GitHub como root?

No lo hagas. Crea un usuario dedicado e instala el servicio para él con `sudo ./svc.sh install USERNAME`, como muestra la página del servicio de GitHub. Un job que se ejecuta como root puede modificar el host para todos los jobs posteriores, y también para ti.

### ¿El runner necesita algún puerto de entrada?

Los requisitos de comunicación de GitHub indican HTTPS saliente por el puerto 443 hacia sus dominios, además de al menos 70 kbit/s en cada sentido. De entrada, puedes cerrar todo excepto SSH. El runner abre él mismo todas las conexiones, de salida.

### ¿Puede un solo servidor servir varios repositorios?

Sí, registra el runner a nivel de organización y asígnalo a un grupo de runners. GitHub advierte que los runners de organización pueden recibir jobs de muchos repositorios, así que un grupo limita hasta dónde llega un job defectuoso.

### ¿Qué pasa si mi servidor se reinicia o se cae?

El servicio vuelve a arrancar tras un reinicio. Los jobs esperan en la cola y se cancelan a las 24 horas. Un runner que permanece desconectado más de 14 días se elimina de GitHub y hay que registrarlo de nuevo.

### ¿Puedo alojar runners de GitLab o agentes de Jenkins de la misma forma?

Sí. Cualquier agente de CI para Linux se ejecuta en el servidor con acceso root. Las reglas de seguridad se mantienen: el código no confiable va a una VM o un contenedor desechable, nunca al propio host.

### ¿Cómo pago y necesitáis mi identidad?

Sin KYC: nunca pedimos un documento de identidad, una selfie, documentos, una tarjeta ni un número de teléfono. Recarga un saldo en BTC, USDT, USDC, ETH, SOL, LTC, XMR (mínimo 1 US$) y pide desde él por 30 días, 3 meses, 6 meses o 12 meses.

## Fuentes

1. [Añadir runners autoalojados](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/add-runners) — GitHub Docs (read 2026-11-01)
2. [Configurar la aplicación del runner autoalojado como servicio](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/configure-the-application) — GitHub Docs (read 2026-11-01)
3. [Usar runners autoalojados en un workflow](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow) — GitHub Docs (read 2026-11-01)
4. [Referencia de runners autoalojados (requisitos, escalado automático, runners efímeros, comunicación)](https://docs.github.com/en/actions/reference/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
5. [Runners autoalojados](https://docs.github.com/en/actions/concepts/runners/self-hosted-runners) — GitHub Docs (read 2026-11-01)
6. [Referencia de uso seguro](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub Docs (read 2026-11-01)
7. [Eliminar runners autoalojados](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/remove-runners) — GitHub Docs (read 2026-11-01)
8. [Límites de Actions](https://docs.github.com/en/actions/reference/limits) — GitHub Docs (read 2026-11-01)
9. [Endpoints de la API REST para runners autoalojados](https://docs.github.com/en/rest/actions/self-hosted-runners) — GitHub Docs (read 2026-11-01)
10. [Actions Runner Controller](https://docs.github.com/en/actions/concepts/runners/actions-runner-controller) — GitHub Docs (read 2026-11-01)
11. [Pasos posteriores a la instalación de Docker Engine en Linux](https://docs.docker.com/engine/install/linux-postinstall/) — Docker Docs (read 2026-11-01)
12. [actions/checkout (uso en el README)](https://github.com/actions/checkout) — GitHub (read 2026-11-01)

---

Lumenfer: Lumenfer alquila servidores bare-metal de generación actual en Ámsterdam, Reikiavik, Zúrich y Bucarest, pagados con criptomonedas y sin KYC: sin ID, sin selfie, sin documentos. Cada máquina tiene una CPU lanzada en 2022 o después, memoria DDR5 y discos NVMe, y se alquila entera a un solo cliente con acceso root. La gestiona DomaineGoat LLC, una empresa de Panamá que ignora las notificaciones DMCA, responde solo ante la ley panameña, permite relays de salida de Tor y no guarda logs. En el plazo de 30 días, cada plan tiene un precio al menos un 25% inferior al de un servidor comparable de generación actual con nombre propio de 13 hosts cripto sin KYC, consultados el 30 de octubre de 2026.