Il miglior VPS per OpenHands (2026): specifiche reali per l'agente di coding

Ultima verifica: 26 luglio 2026

OpenHands è il progetto conosciuto in passato come OpenDevin, ora oltre le 74.000 stelle su GitHub e con release mensili. Il quadro dell’hosting è cambiato parecchio all’inizio del 2026, quando il team ha estratto il runtime dal processo principale spostandolo in una sandbox Docker. Un bene per la sicurezza. Doloroso se leggi la vecchia documentazione e provisioni un VPS da 2 GB.

Uso OpenHands da nove settimane come mio agente di coding in background. Ecco cosa la scheda tecnica non ti dice.

Di cosa ha davvero bisogno OpenHands

Tre consumatori di risorse, in ordine di quanto spesso creano problemi:

1. La sandbox. Docker-in-Docker, con un’immagine runtime che va da 800 MB a 2,5 GB a seconda dello stack linguistico. Ogni task attivo ne genera una.
2. I passaggi di build e installazione. Quando l’agente decide di eseguire npm install o pip install su un repository reale, l’uso della RAM schizza in alto.
3. Il modello. Se autoospiti anche l’LLM sulla stessa macchina, ti serve una GPU e una categoria di hardware completamente diversa.

La maggior parte degli utenti vuole i punti 1 e 2 su una macchina solo CPU, con il modello ospitato su Anthropic o OpenAI. È questo il setup che copre il resto di questa pagina.

Confronto VPS per OpenHands

Hetzner Cloud CCX23: la mia scelta attuale

La linea CCX è il punto ideale per OpenHands. Il CCX13 con 8 GB funziona per un uso leggero in solitaria, ma nel momento in cui chiedi all’agente di fare due cose in parallelo, vuoi il CCX23. L’NVMe conta perché la sandbox scrive molto durante i build, e l’I/O di Hetzner è costante in un modo in cui i vecchi nodi di Contabo non lo erano.

Cosa funziona qui per OpenHands:

• Gli snapshot cloud rendono il rollback dopo un task andato male indolore
• Le regioni di Falkenstein ed Helsinki restano entrambe sotto gli 80 ms verso l’API di Anthropic
• La fatturazione oraria permette di far partire una macchina più potente per un job specifico

Contro: la banda in uscita inclusa è di 20 TB, che sembra tanta finché l’agente non decide di clonare in loop repository da cinque gigabyte. Tieni d’occhio il contatore.

Attiva Hetzner: Hetzner Cloud.

Contabo VPS M: la chicca da 8 euro

Difficile discutere 6 vCPU e 16 GB a 8.50 EUR. Sui piani NVMe più recenti, il profilo I/O va benissimo per OpenHands. I due veri svantaggi: il provisioning richiede ore anziché secondi, e la latenza in uscita verso le principali API dei modelli è sistematicamente peggiore di 100-200 ms rispetto a Hetzner. Se tieni la macchina accesa a lungo termine va bene. Se la accendi e spegni spesso, l’attesa è brutale.

Pro:

• La macchina più economica che regge davvero la sandbox senza andare in swap
• 400 GB di disco sono generosi per tenere più clone di repository in parallelo

Aspetto negativo che non voglio addolcire: i tempi di risposta del supporto sui piani più economici possono allungarsi fino a diversi giorni.

Attiva Contabo: Contabo VPS.

DigitalOcean Premium AMD: per i team USA

Se il tuo endpoint del modello è in US-East e lo è anche il tuo team, i nodi NYC3 di DigitalOcean tagliano un round trip da ogni chiamata al modello. Il livello da 8 GB regge un singolo worker OpenHands, ma non ci farei girare più di una sandbox pesante. I nuovi nodi Premium AMD sono decisamente più scattanti rispetto ai vecchi piani a CPU condivisa, vale il sovrapprezzo.

Svantaggio onesto: 28 USD per 8 GB è caro rispetto ai prezzi europei di Hetzner. Pagalo se la latenza conta più dell’euro per gigabyte.

Configura DigitalOcean: DigitalOcean.

Vultr HF General 16 GB: per carichi multi-sandbox

Se usi OpenHands come strumento di team e ti servono tre o quattro sandbox simultanee, la linea High Frequency di Vultr è il posto più semplice dove atterrare. Il piano da 16 GB con 4 vCPU lascia abbastanza margine perché nessun task affami gli altri, e la mappa mondiale delle region di Vultr conta quando il team è distribuito su più continenti.

Attiva Vultr: Vultr.

Insidie comuni nell’autoospitare OpenHands

Tre cose che mi hanno fregato:

1. Esposizione del socket Docker. La sandbox ha bisogno del socket Docker dell’host. Va bene su un VPS a utente singolo, pericoloso su uno condiviso. Non far girare OpenHands come servizio per utenti non fidati senza un utente di runtime separato.
2. Pulizia. I vecchi container sandbox si accumulano in fretta. Imposta un docker container prune giornaliero, altrimenti finirai lo spazio su disco entro una settimana.
3. Limiti di memoria. Limita esplicitamente ogni sandbox a 4 GB. Senza limiti, un npm install fuori controllo divorerà l’intero VPS e trascinerà con sé il layer di orchestrazione.

Cosa sceglierei davvero

Se parti oggi e vuoi OpenHands come programmatore in background:

• UE, uso quotidiano: Hetzner CCX23
• UE, spesa minima: Contabo VPS M, accettando il provisioning più lento
• Team USA: DigitalOcean Premium AMD da 8 GB o superiore
• Setup di team, tre o più sandbox: Vultr HF General 16 GB

Per il quadro più ampio sull’autoospitare, vedi il confronto SelfHostVPS. OpenHands si evolve in fretta, quindi aggiorno questa pagina dopo ogni cambiamento importante di sandbox o runtime che arriva su main.