VPS per runner CI/CD self-hosted
I minuti di CI ospitata sono misurati, messi in coda e lenti da riscaldare. Un VPS VeloxMedia trasforma qualsiasi sistema CI in un runner persistente che controlli: installa Docker e il tuo agente runner una volta, mantieni calde le cache di build tra i job e paga una tariffa mensile fissa invece di un'eccedenza al minuto.
Ogni server include accesso root completo, storage SSD NVMe, traffico dati illimitato e un IPv4 dedicato. Registra un GitLab Runner, un runner self-hosted di GitHub Actions, un agente Jenkins, Drone, Woodpecker o un agente Buildkite, poi punta le tue pipeline su hardware che controlli. I deploy si completano in circa 60 secondi, e la reinstallazione con un clic riporta un runner a uno stato pulito ogni volta che un ambiente di build va alla deriva.
Poiché il traffico è illimitato, scaricare immagini di base, installare dipendenze e caricare artefatti non attiva mai costi di egress. L'alta disponibilità in cluster mantiene i runner online durante i guasti hardware, e la migrazione live senza downtime sposta i carichi di lavoro durante la manutenzione dell'host, così le build lunghe non vengono interrotte.
- Prezzo mensile fisso da $5 senza addebiti al minuto per le build e senza costi di attivazione
- Storage SSD NVMe per rapidi ripristini delle dipendenze e caching dei layer Docker
- Traffico dati illimitato per il download di immagini e il caricamento di artefatti
- Accesso root completo per installare Docker e qualsiasi agente runner self-hosted
- Deploy in 60 secondi e reinstallazione con un clic per runner puliti e riproducibili
- IPv4 dedicato per inserire i runner nella allowlist di registri privati e target di deploy
Perché eseguire i tuoi runner CI/CD su un VPS
I runner ospitati fatturano al minuto e limitano la concorrenza su piani che non controlli. Un VPS dedicato ribalta questo modello. Paghi un prezzo mensile fisso senza addebiti al minuto e senza costi di attivazione, così una pipeline impegnata costa quanto una tranquilla. Il runner resta online tra i job, il che significa che le cache delle dipendenze, i layer Docker e i repository clonati sono già su disco quando parte la build successiva. Decidi tu il toolchain, la concorrenza e i tag del runner, e nulla viene limitato dietro un livello di utilizzo.
Build più veloci su NVMe con traffico illimitato
La maggior parte del tempo di CI viene speso installando dipendenze, ripristinando cache e scaricando immagini container. Lo storage SSD NVMe riduce questo overhead: le cache di npm, pip, cargo, go mod e Maven si ripristinano rapidamente, il caching dei layer Docker legge e scrive alla velocità NVMe, e i checkout di grandi monorepo restano veloci. Il traffico dati illimitato significa che il costante scaricamento di immagini di base e caricamento di artefatti di build non aggiunge una bolletta di banda. Lo storage NVMe distribuito e replicato è alla base di ogni server, così i dati in cache sono protetti contro il guasto di un singolo disco o host.
Root completo per Docker, container e qualsiasi agente runner
Ottieni accesso root o amministratore completo su ogni server, così puoi installare Docker, Podman, buildx, i toolchain dei linguaggi e l'agente runner di tua scelta. Registra un GitLab Runner con executor Docker o shell, un runner self-hosted di GitHub Actions, un agente Jenkins o agenti Drone, Woodpecker e Buildkite. Scegli tra Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora, CentOS o Alpine, e scegli Windows Server quando devi compilare target .NET, MSVC o altri Windows. La console via browser ti offre accesso VNC, SSH e RDP direttamente dal portale se mai ti blocchi fuori a metà configurazione.
Runner puliti e riproducibili che puoi resettare in pochi secondi
L'igiene delle build conta quando i job condividono un host. La reinstallazione e la ricostruzione con un clic riportano un runner a un OS pulito in circa 60 secondi, così puoi riciclare una macchina che ha accumulato stato. Gli snapshot catturano un runner golden completamente configurato e ti permettono di ripristinarlo o clonare la configurazione su un nuovo server. I backup e la modalità di soccorso recuperano un host che non si avvia, e il monitoraggio delle vulnerabilità segnala pacchetti non aggiornati prima che raggiungano una build. Un IPv4 dedicato più le regole del firewall ti permettono di inserire il runner nella allowlist di un registro privato, di un archivio di artefatti o di un target di deploy in produzione, e il reverse DNS è modificabile dal pannello.
Dimensiona un piano sulla tua pipeline e posizionalo vicino al tuo codice
Sei piani uniformi scalano da pipeline leggere a pesanti. Micro (1 vCPU / 2 GB / 20 GB) e Small (2 / 4 / 40) sono adatti al linting e a singole build piccole. Medium (4 / 8 / 80) è un solido runner container generico. Plus (4 / 12 / 120) aggiunge memoria per build JVM, grandi alberi node_modules e suite di integrazione, mentre Pro (6 / 16 / 160) e Max (8 / 32 / 200) gestiscono job matrix in parallelo e grandi monorepo. Esegui un piano più grande o aggiungi più istanze di runner man mano che il carico cresce. Distribuisci a London, Amsterdam, US East (Ohio) o US West (California), con Warsaw, Montreal e Utah in arrivo, così un runner sta vicino al tuo host git e ai target di deploy. I prezzi partono da $5 al mese, Amsterdam da $6, con la fatturazione annuale che offre due mesi gratis. Ogni deploy, reinstallazione e snapshot avviene nel portale clienti, supportato da checkout con carta ospitato e sicuro e supporto 24/7.
VPS per runner CI/CD self-hosted domande
Quali sistemi CI/CD posso eseguire su questi runner VPS?
Qualsiasi sistema CI che supporti runner o agenti self-hosted. Le scelte comuni sono GitLab Runner, runner self-hosted di GitHub Actions, agenti Jenkins e agenti Drone, Woodpecker o Buildkite. Hai root completo per installare l'agente, Docker e il tuo toolchain su Ubuntu, Debian, AlmaLinux, Rocky Linux, Fedora, CentOS, Alpine o Windows Server.
Che dimensione di VPS mi serve per un runner CI/CD?
Dipende dalle tue build. Small (2 vCPU / 4 GB) gestisce una singola pipeline leggera, Medium (4 / 8) è un buon runner container generico, e Plus (4 / 12) è adatto a build JVM o di integrazione pesanti per la memoria. Pro (6 / 16) e Max (8 / 32) eseguono job matrix in parallelo e grandi monorepo. Quando il carico cresce, passa a un piano più grande o distribuisci più istanze di runner.
Come mantengo puliti gli ambienti di build tra i job?
Esegui ogni job in un container per l'isolamento, e usa la reinstallazione o ricostruzione con un clic per riportare l'intero runner a un OS pulito in circa 60 secondi. Gli snapshot ti permettono di salvare un runner golden configurato e ripristinarlo su richiesta, mentre i backup e la modalità di soccorso recuperano un host che non si avvia.
Scaricare immagini e caricare artefatti conta rispetto a un limite di banda?
No. Ogni server include traffico dati illimitato, così scaricare immagini di base, ripristinare cache e caricare artefatti di build non comporta costi di egress al GB. Ogni server include anche un IPv4 dedicato che puoi inserire nella allowlist di un registro privato o firewall.
Distribuisci il tuo primo server in meno di un minuto
Scegli una regione, seleziona una dimensione e connettiti via SSH. Nessun costo di attivazione, disdici quando vuoi.