Todos los productos 
VPS para desarrollo y CI/CD: qué importa
Un servidor propio para builds y tests se amortiza en cuanto dejan de bastarte los minutos gratuitos de GitHub Actions o GitLab CI. Un runner propio no tiene límite de tiempo y conserva las cachés de dependencias e imágenes Docker, así que los builds repetidos van varias veces más rápido. El mismo VPS sirve también como entorno de trabajo remoto o como entorno de pruebas.
Núcleos y memoria: el build necesita mucho, pero poco rato
La compilación, el build del frontend y la ejecución de tests se reparten entre los núcleos, así que para un runner el número de núcleos importa más que para un servidor web. Como referencia:
- 2 núcleos y 4 GB: proyectos pequeños en Node.js, Python o PHP, linters y tests unitarios;
- 4 núcleos y 8 GB: build de imágenes Docker, frontend con Webpack o Vite, tests de integración con base de datos;
- 8 núcleos y 16 GB: compilación de Go, Rust, Java o C++, builds de Android, tareas en paralelo.
Si haces pocos builds al día, el servidor pasa la mayor parte del tiempo parado. Aquí ayuda la facturación por horas: levantas un servidor potente mientras trabajas y luego lo eliminas, y solo pagas las horas de uso. Muchos proveedores permiten hacerlo por API, así que el runner se puede encender automáticamente.
Disco: las cachés ocupan más de lo que parece
Las imágenes Docker, las cachés de npm, pip, Maven o Gradle y los artefactos de build ocupan enseguida decenas de gigabytes. Elige NVMe desde 50–80 GB y configura la limpieza: docker system prune programado y un plazo máximo de conservación de artefactos. La velocidad del disco influye directamente en el tiempo de instalación de dependencias: en un disco lento puede tardar más que el propio build.
Cómo conectar el runner
- GitHub Actions: el self-hosted runner se instala con un solo comando desde la configuración del repositorio o de la organización y funciona como servicio.
- GitLab CI:
gitlab-runnercon el executor Docker; cada tarea se ejecuta en un contenedor limpio y las imágenes se cachean en el servidor. - Gitea, Forgejo, Woodpecker, Drone: alternativas ligeras si también alojas el repositorio en tu propio servidor; consulta también VPS para GitLab.
Virtualización y seguridad
Para builds con Docker necesitas KVM: en la virtualización por contenedores, Docker a menudo no arranca o funciona con limitaciones (más detalles en la página VPS para Docker). No conectes un self-hosted runner a repositorios públicos: un pull request ajeno podría ejecutar cualquier código en tu servidor. Pasa los secretos mediante variables de CI en lugar de guardarlos en disco, y actualiza el runner junto con el sistema.
Dónde alojarlo
Un servidor más cerca de tu hosting Git y de tu registro de imágenes descarga las dependencias más rápido. Para GitHub y Docker Hub van bien los servidores en Europa y EE. UU.; si algún registro responde lento o limita las descargas, configura de antemano mirrors o una caché proxy.