¿Cuántas vCPU dedicadas necesita un VPS para GitLab Runner?

¿Cuántos jobs de CI puede ejecutar un VPS a la vez?

Un job de CI necesita dos vCPU dedicadas y la RAM que las acompaña; el ajuste concurrent del runner decide cuántos de esos jobs comparten el VPS. En config.toml, concurrent limita los jobs de todos los runners registrados, y limit los limita para un runner registrado (0, el valor por defecto, significa sin límite). La página de requisitos de GitLab indica las tres entradas para dimensionar: la carga de CPU de los jobs, su uso de memoria y cuántos se ejecutan de forma concurrente.

¿Cómo se comparan los tamaños de los runners alojados de GitLab con un VPS?

Los runners Linux alojados de GitLab dan 4 GB de RAM por vCPU; los planes de Cobaltfell dan 2 GB por vCPU. Los recuentos de vCPU coinciden uno a uno, lo que hace de la tabla una forma directa de elegir un tamaño para pipelines que ya se ejecutan en GitLab.com. Los jobs que usan la mayor parte de la memoria de su máquina actual necesitan el plan de Cobaltfell un tamaño superior, o menos jobs a la vez.

Según el estudio de Cobaltfell del 2 de noviembre de 2026, una vCPU dedicada en un procesador de 2022 o posterior costaba una mediana de $8.20 al mes en hosts que aceptan criptomonedas sin comprobación de identidad, así que cada job de CI en paralelo de dos vCPU cuesta aproximadamente el doble.

Todos los hosts y precios detrás de esa mediana están en cuánto cuesta una vCPU dedicada en un VPS por núcleo en noviembre de 2026.

¿Por qué importan los núcleos dedicados para los jobs de CI y de compilación?

Una compilación mantiene la CPU a plena carga durante minutos seguidos, justo el patrón que los planes de VPS compartidos están diseñados para limitar. Dos hosts del mismo estudio lo indican en sus reglas: los términos de Spartan Host prohíben usar más del 50% de los núcleos asignados durante más de una hora, y la política de uso razonable de Advin Servers limita el uso de CPU al 75%.

En una vCPU compartida, el coste también aparece como steal time. Un pipeline que es rápido en una noche tranquila se alarga en horas punta, y los timeouts de los jobs se disparan por motivos ajenos al código; qué es el steal time de CPU y cómo comprobarlo en un VPS muestra cómo leerlo.

En Cobaltfell: Se permite la carga completa durante todo el tiempo que tu trabajo lo necesite: sin créditos de CPU, sin ventana de ráfaga y sin limitación tras unos minutos al 100 %. Una vCPU es un hilo de hardware del procesador del host. Los tuyos están fijados uno a uno a tu VPS y nunca se prestan a otro cliente, y los dos hilos de un núcleo físico permanecen juntos, así que cada 2 vCPU forman un núcleo entero que ningún vecino comparte. Sin ningún vecino en los hilos, un pipeline con la caché caliente tarda aproximadamente lo mismo en cada ejecución, así que un job lento apunta al código. Cómo funciona la regla de vCPU a núcleo se explica en ¿una vCPU dedicada es un núcleo o un hilo?.

¿Cómo evito que las compilaciones en paralelo se peleen por las mismas vCPU?

Da a cada job una cuota fija del VPS y pasa el mismo número a la herramienta de compilación. Las herramientas de compilación no coinciden en sus valores por defecto. GNU make ejecuta una receta a la vez salvo que se le pase -j. Cargo ejecuta tantos jobs como CPUs lógicas haya. Ninja se ejecuta en paralelo según el recuento de CPU sin que se lo pidas. Cuatro compilaciones así en Fell 8 arrancarían cada una ocho compiladores: 32 procesos para 8 hilos y 16 GB de RAM.

Con el executor de Docker, cada job se ejecuta en su propio contenedor, y [runners.docker] toma un límite cpus y un límite memory para ese contenedor. Configura ambos y luego ajusta el paralelismo dentro del job:

concurrent = 4            # jobs at once, all runners together
check_interval = 3

[[runners]]
  name = "fell-8-docker"
  url = "https://gitlab.com"
  token = "REPLACE_WITH_YOUR_RUNNER_TOKEN"
  executor = "docker"
  limit = 4
  [runners.docker]
    image = "debian:13"
    cpus = "2"             # CPUs for each job container
    memory = "3g"          # leaves room for the system and Docker

variables:
  MAKEFLAGS: "-j2"          # GNU make
  CARGO_BUILD_JOBS: "2"     # cargo (build.jobs)

build:
  script:
    - make
    - cargo build --release
    - ninja -C build -j 2

¿Qué necesita compilar Rust o C++ en un VPS?

Las compilaciones necesitan hilos y memoria a la par: cada proceso de compilación en paralelo y cada paso de enlazado toma su propia parte de RAM. Las unidades de traducción grandes de C++ y los crates de Rust con muchos genéricos son los picos de memoria habituales, y el enlazado final de un binario grande puede necesitar más que cualquier compilación individual.

Una compilación que muere por falta de memoria necesita un -j o un CARGO_BUILD_JOBS más bajo, no más vCPU: con menos jobs terminan más, con más jobs fallan más. Mantén las cachés de compilación en el disco propio del VPS (Almacenamiento NVMe en todos los planes) y elimina las imágenes antiguas con docker image prune, porque un runner con mucho trabajo llena un disco más rápido de lo que sugieren sus pipelines.

Un monorepo que necesita decenas de gigabytes de RAM por compilación es territorio de bare metal, que Cobaltfell no vende. Las suites de pruebas con base de datos tienen sus propias reglas de dimensionamiento, tratadas en cuánta CPU y RAM necesita PostgreSQL en un VPS.

¿Qué executor debería usar un runner en un VPS?

El executor de Docker es la opción por defecto correcta: la guía de executors de GitLab dice que da a cada compilación un entorno limpio y aislado, mientras que el executor Shell no ofrece ni un entorno limpio por compilación ni protección del sistema de archivos del runner. Los executors Shell, SSH y VirtualBox están en modo de mantenimiento.

Quién puede iniciar un job importa igual: una merge request desde un fork ejecuta su propio código en el VPS. La guía de seguridad de GitHub dice que los runners autohospedados casi nunca deberían usarse para repositorios públicos, y el mismo razonamiento se aplica a cualquier sistema de CI que ejecute pull requests no confiables.

Los agentes de Forgejo, Woodpecker, Jenkins y GitHub Actions se dimensionan igual: cuenta los jobs solapados, da a cada uno hilos y memoria fijos. Los precios de plan para cada tamaño están en cuánto cuesta un VPS con núcleos dedicados.