Quale VPS dovrei usare per Claude Code o altri agenti di coding?

Una macchina da 4 vCPU / 4 GB è il punto ideale per un agente su un progetto reale (il piano AI-Agent di EQVPS); 2 GB bastano per repo leggeri. L'agente in sé è leggero — dimensiona per la toolchain di build e test del tuo progetto, non per l'agente.

Posso far girare agenti di coding su un VPS senza KYC?

Sì. Registrati con un'email e paga in crypto (USDC o USDT su Base o Ethereum) — niente ID, niente carta. Comodo quando avvii macchine usa-e-getta per agente e non vuoi legare ciascuna alla tua identità.

NAT o IP dedicato per un agente di coding?

NAT è sufficiente — un agente di coding fa solo chiamate in uscita (API del modello, git, registri di pacchetti), quindi l'SSH su porta inoltrata di un piano NAT lo copre. Scegli un IP dedicato solo se ospiti anche qualcosa in entrata, come un ricevitore di webhook o un server di anteprima.

Un agente IA può fare provisioning del proprio VPS?

Sì — EQVPS espone un server MCP, così un agente può elencare i piani, pagare in crypto e avviare la propria macchina in modo programmatico. Dettagli su /docs.

Perché eseguire un agente di coding su un VPS invece che sul mio laptop?

Persistenza. Su un server l'agente continua a lavorare quando il tuo laptop va in sospensione, si chiude o perde il wifi — un lungo refactor o un test run sopravvivono alla tua giornata. Tiene anche installazioni pesanti e detriti di build fuori dalla tua macchina, e dà all'agente un ambiente pulito e riproducibile in cui lavorare.

Quanta RAM serve a un agente di coding su un server?

Il processo dell'agente in sé è leggero — chiama un modello tramite un'API, quindi 2 GB gestiscono comodamente l'agente più un checkout git ed editor. Ciò che mangia RAM è la toolchain di build/test del tuo progetto (una grossa build Node o di un compilatore), quindi dimensiona per quella. 4 GB è un default sicuro per progetti reali.

Come tengo l'agente in funzione dopo aver disconnesso l'SSH?

Avvialo dentro tmux (o screen). Ti connetti, avvii l'agente, stacchi e chiudi il laptop — continua a girare sul server. Riconnettiti dopo con tmux attach per vedere i progressi. Per esecuzioni pianificate non presidiate, un servizio systemd o cron è più pulito.

È sicuro dare a un agente autonomo l'accesso alla shell su un server?

Trattalo come qualsiasi strumento potente: eseguilo su un VPS dedicato, non accanto a qualcosa di prezioso, usa un utente non-root, tieni i segreti in variabili d'ambiente e lavora in un repo git così ogni modifica è revisionabile e reversibile. L'isolamento di una macchina separata è esattamente il motivo per cui un VPS è il posto più sicuro per questo, non la tua macchina principale.

L'agente ha bisogno di una CPU potente?

Non per il ragionamento — quello avviene sull'hardware del provider del modello. La CPU conta solo per le build e i test del tuo progetto. Una macchina a 2 core va bene per la maggior parte dei repo; aumenta i core se la tua suite di test è pesante o esegui diversi agenti insieme.

Il miglior VPS per Claude Code e agenti di coding (no-KYC, pagato in crypto)

Un agente di coding sul tuo laptop si ferma nel momento in cui chiudi il coperchio. Va bene per una modifica rapida — e diventa silenziosamente frustrante nel momento in cui vuoi che macini un lungo refactor, sforni una suite di test, o continui mentre vai a fare qualcos'altro. Spostalo su un server e quella limitazione semplicemente sparisce: lavora mentre dormi, sopravvive alla caduta del wifi, e ti consegna il risultato quando sei di ritorno. Questo copre quale VPS si adatta davvero a un agente di coding — Claude Code, la CLI di Cursor, Cline, OpenCode o aider — cosa pagare, e come tenerlo in funzione, senza KYC e con pagamento in crypto.

Cosa ti dà davvero "su un server"

Non si ferma. Un task lungo arriva a completamento indipendentemente dal tuo laptop.
Stanza pulita. L'agente ottiene un ambiente riproducibile; la tua macchina resta libera da spazzatura di build e dipendenze installate a metà.
Isolamento. Un agente con accesso alla shell è potente. Molto meglio che abbia quel potere su una macchina usa-e-getta che accanto alle tue foto e chiavi SSH.

Quell'ultimo punto è sottovalutato: un VPS è la casa più sicura per un agente autonomo, proprio perché è separata.

Dimensionarlo bene

L'agente in sé è leggero — chiama un modello tramite un'API, quindi il ragionamento avviene altrove (lo stesso motivo per cui la maggior parte degli agenti IA ha bisogno di poca RAM). Ciò che consuma davvero risorse è la toolchain del tuo progetto: una grossa build, un test run pesante, un database locale. Quindi dimensiona per il progetto, non per l'agente:

2 GB / 2 core — comodo per l'agente + un checkout git + build leggere.
4 GB — un default sicuro per progetti reali con suite di test serie.
Di più solo se la tua build è davvero affamata o esegui diversi agenti insieme.

Quale piano si adatta — e come paghi

Per un singolo agente di coding su un progetto reale, il punto ideale è 4 vCPU / 4 GB — spazio per l'agente più la tua suite di build e test. Su EQVPS quello è il piano AI-Agent ($10/mese); una macchina da 2 GB va bene per repo leggeri, sali solo se i tuoi test sono pesanti o esegui diversi agenti insieme.

Due scelte pratiche:

NAT, non IP dedicato. Un agente di coding fa solo chiamate in uscita — API del modello, git, registri di pacchetti — quindi un piano NAT con SSH su porta inoltrata è tutto ciò che serve, ed è più economico. Ricorri a un piano con IP dedicato solo se ospiti anche qualcosa a cui altri si connettono (un ricevitore di webhook, un server di anteprima).
No-KYC, pagato in crypto. Registrati con un'email e paga in USDC o USDT su Base o Ethereum — niente carta, niente ID. Utile se avvii macchine usa-e-getta per agente e non vuoi che ciascuna sia legata alla tua identità. Anche una carta funziona, ma l'on-ramp ha un minimo di ~$27, quindi ricaricare un piccolo saldo una volta è più fluido per i piani economici.

È solo CPU e gira da un singolo datacenter in Germania — adatto a un agente di coding (il ragionamento pesante è dalla parte del provider del modello), utile sapere se ti serve specificamente una GPU o un'altra regione.

Metterlo in funzione

Fai SSH, configura la tua toolchain e l'agente (Claude Code, la CLI di Cline, aider — quello che usi), clona il tuo repo, ed esporta la tua chiave API:

export ANTHROPIC_API_KEY=...    # o la chiave del tuo provider
cd ~/myproject

Ora il trucco chiave — non eseguirlo in una sessione SSH nuda, o muore quando ti disconnetti. Eseguilo dentro tmux:

sudo apt install -y tmux
tmux new -s agent
# dentro tmux: avvia il tuo agente di coding, puntalo al task
# poi stacca con: Ctrl-b, poi d

Stacca, chiudi il laptop, vai a pranzo. L'agente continua a lavorare sul server. Torna e fai tmux attach -t agent per vedere cosa ha fatto. Per esecuzioni pianificate, non presidiate (es. una passata di manutenzione notturna), avvolgilo invece in un servizio systemd — stesso schema del tenere vivo qualsiasi processo.

Le avvertenze oneste

Dagli una sandbox, non le chiavi del regno. Usa un utente non-root, tienilo in un repo git (ogni modifica revisionabile e reversibile), e non mettere credenziali di produzione sulla macchina. Autonomia più accesso alla shell più disattenzione è come accadono gli incidenti.
Sorveglia la spesa in token. Un agente a lunga esecuzione che chiama un modello in loop costa vero denaro API — imposta limiti e controlla. Il server è economico; l'inferenza è ciò che si somma.
Non è magia. Un agente in background è ottimo per task ben delimitati e verificabili. Puntalo su qualcosa di vago e non presidiato e tornerai a trovare sciocchezze dette con sicurezza. Delimita strettamente.

Entro questi paletti, un agente di coding sul proprio server è uno schema davvero utile — il tuo lavoro continua che tu lo faccia o no. Avvia una macchina da 4 GB, metti tmux e il tuo agente, e lascialo cuocere. L'agente può persino noleggiare il server da solo tramite MCP se vuoi l'intero ciclo autonomo.