Esegui un agente AI 24/7 su un VPS.
Via dal tuo laptop, su hardware che non dorme mai.
Per eseguire un agente AI 24/7 su un VPS servono quattro cose, nessuna delle quali geniale: una macchina che resta accesa, un supervisore che la riavvia, segreti che non entrano mai nell'immagine, e un tetto di spesa — più un host che non richiede la tua identità.
- 01
La maggior parte degli agenti è collante I/O-bound attorno a un'API di modello hosted. L'inferenza non è sulla tua macchina, quindi la macchina è piccola: 2 vCPU e 4 GB reggono un agente a ciclo singolo.
- 02
L'uptime è un problema di supervisione, non di hardware. Una unit systemd o una restart policy Docker — abilitata, e testata con un vero riavvio — è tutto ciò che serve.
- 03
Le due cose che mordono davvero: un segreto incorporato in un layer dell'immagine, e un agente senza tetto di spesa che gira tutta la notte contro un'API a consumo.
Perché il tuo laptop non è un deployment. Quattro modalità di guasto, tutte noiose.
Un agente che funziona sulla tua macchina è un agente funzionante, non uno distribuito. Il divario è fatto di quattro problemi poco affascinanti, nessuno dei quali riguarda il prompt engineering.
Sospensione. Chiudi il coperchio e il processo viene sospeso. La gestione energetica rallenta il lavoro in background ben prima che il coperchio si chiuda, il che produce la versione peggiore di questo guasto: un agente che gira, ma in ritardo e in modo imprevedibile.
Turnover dell'IP. Una connessione domestica o da bar ti assegna un nuovo indirizzo a ogni riconnessione. Tutto ciò che è limitato per IP, ogni webhook che richiede un callback stabile, ogni allowlist che hai registrato si rompe in modo intermittente.
Riavvii. Gli aggiornamenti del sistema operativo riavviano la macchina secondo un proprio calendario. Se l'agente non è registrato presso un service manager, al ritorno trova un desktop, non un ciclo in esecuzione. La maggior parte delle persone se ne accorge una settimana dopo.
Trasferimenti. Viaggi, cambi macchina, reinstalli. Tutto ciò che vive solo nella cronologia della tua shell non è riproducibile — un agente configurato in un pomeriggio di marzo non ha alcuna procedura di deployment.
Un server risolve queste quattro cose e nient'altro — non la correttezza, non il costo, non la sicurezza. Ti dà un runtime i cui guasti spettano a te da correggere. Diffida di chi te lo vende come qualcosa di più.
Dimensionare la macchina. Quale piano VPS per quale forma di agente.
L'istinto è di sovradimensionare, perché l'intelligenza artificiale suona pesante. Non lo è, finché il modello gira sull'hardware di qualcun altro: un agente che chiama un'API hosted passa il suo tempo in attesa di I/O di rete. Una terza forma — eseguire il modello stesso — esula da questo articolo; quel carico di lavoro vuole una GPU più che una macchina virtuale.
Forma uno — il ciclo singolo. Un processo, un ciclo di polling o pianificato, un'API di modello hosted, stato in SQLite. È la forma della maggior parte degli agenti indie e dei bot di monitoraggio, ed è davvero piccola.
Forma due — lo stack piccolo. L'agente più Postgres, una coda basata su Redis, un worker e un vector store. Ora la memoria è il vincolo determinante — un modello di embedding caricato in-process vuole uno o due gigabyte tutti per sé.
Rispetto al catalogo: Sentinel (NB-V1 — 2 vCPU, 4 GB RAM, 120 GB NVMe, 1 Gbps, banda illimitata, $3.90/month) copre la forma uno con margine abbondante. Garrison (NB-V2 — 4 vCPU, 8 GB, 240 GB, $7.90/month) è il minimo onesto per la forma due una volta che Postgres e una coda entrano in gioco. Ravelin (NB-V3 — 8 vCPU, 16 GB, 480 GB, 2.5 Gbps, $16.90/month) è per più agenti che condividono una macchina. L'inferenza locale appartiene all'hardware dedicato.
I contratti sono mensili, con uno sconto per impegni più lunghi — 10% a tre mesi, 20% a sei, 30% a dodici. Se il tuo agente è un client di trading solo-Windows anziché un processo Python, i piani remote-desktop esistono proprio per quel caso.
Il percorso di deploy — esegui un agente AI su un VPS in circa quindici minuti.
Provisiona la macchina con Ubuntu 24.04 LTS o Debian 13 — entrambi offerti al momento dell'ordine, insieme a Ubuntu 22.04, Debian 12, AlmaLinux 9 e Rocky Linux 9. Ricevi le credenziali di root; la prima cosa da fare con loro è smettere di usarle. Se l'autenticazione con chiave SSH è territorio poco familiare, leggi prima la guida di hardening linkata più sotto.
1 — Crea un utente di servizio. adduser --system --group --home /srv/agent agent. L'agente non dovrebbe girare come root e non dovrebbe possedere una shell interattiva. Un comando adesso, e il raggio del danno resta piccolo più avanti se uno strumento che chiama viene usato contro di lui.
2 — Porta il codice sulla macchina. git clone dentro /srv/agent, oppure rsync se preferisci non lasciare una deploy key sul server. Blocca le dipendenze: un lockfile è la differenza tra un redeploy che si riproduce fedelmente e uno che ti sorprende.
3 — Costruisci l'ambiente. python3 -m venv /srv/agent/.venv, poi installa dal lockfile con il pip di quel virtualenv. Oppure installa uv e lascia che gestisca sia l'interprete sia il lockfile. Entrambi vanno bene; mescolare i due no.
4 — Eseguilo una volta a mano. sudo -u agent /srv/agent/.venv/bin/python -m agent --once. Non saltare questo passaggio per andare dritto a una unit di servizio. Nove guasti su dieci qui sono una variabile d'ambiente mancante o un percorso relativo al tuo laptop, ed entrambi si leggono più chiaramente in un terminale che in journald.
5 — Affidalo a un supervisore. Il prossimo capitolo. È questo che trasforma uno script che hai avviato in un servizio di proprietà della macchina. Se la sequenza è durata sensibilmente più di quindici minuti, la causa è quasi sempre una dipendenza implicita dalla tua macchina di sviluppo — un binario globale, una credenziale nel profilo della tua shell, un percorso esterno al repository.
Tenerlo vivo 24/7. systemd, Docker e la trappola del crash-loop.
Un processo avviato tramite una sessione SSH muore quando la sessione termina, e non torna dopo un riavvio. La supervisione non è opzionale, e hai due opzioni ragionevoli.
systemd, per un singolo processo. Una unit in /etc/systemd/system/agent.service con User=agent, WorkingDirectory=/srv/agent, ExecStart che punta all'interprete del virtualenv, Restart=always e RestartSec=5. Poi systemctl daemon-reload, poi systemctl enable --now agent. È l'enable a sopravvivere a un riavvio; avviare senza abilitare è il modo più comune di perdere un agente tre settimane dopo.
Docker, per un insieme di cose. Quando l'agente ha dei fratelli — un database, una coda, un browser headless — descrivili in un unico file Compose con restart: unless-stopped su ogni servizio. unless-stopped differisce da always per un aspetto che conta: un container che hai fermato deliberatamente resta fermo anche dopo un riavvio del daemon.
La trappola del crash-loop. systemd limita i riavvii per impostazione predefinita. Crasha abbastanza spesso entro l'intervallo e la unit entra nello stato failed e smette di riprovare — un agente che sembra morto in silenzio mentre il file della unit dichiara chiaramente Restart=always. Imposta StartLimitIntervalSec=0 per riprovare all'infinito, e alza RestartSec in modo che un agente rotto non faccia girare un core per tutta la notte.
Essere vivo non è essere in salute. Un ciclo bloccato su una lettura di socket per nove ore è un processo in esecuzione secondo qualunque misura systemd possa vedere. Esponi un heartbeat: un watchdog con WatchdogSec, una HEALTHCHECK Docker, oppure un file di timestamp che l'agente tocca a ogni ciclo, con un timer che avvisa quando diventa obsoleto.
Segreti. Il file di environment che non deve mai raggiungere l'immagine.
Un agente detiene materiale più pericoloso di un'applicazione web. Una chiave API di un modello è uno strumento di spesa; una chiave di trading è una con leva; una chiave di wallet sono i fondi stessi. E a differenza di un'app web, un agente agisce su testo che non ha scritto lui, il che rende sottile il confine tra l'agente che detiene una chiave e un attaccante che la detiene.
Tienile fuori dall'immagine. I valori ENV e ARG in un Dockerfile vengono scritti nei layer dell'immagine e sono leggibili con docker history da chiunque ottenga l'immagine. Usa env_file: in Compose, oppure EnvironmentFile= nella unit systemd, e tieni il file fuori dal build context.
Tienile fuori dal repository. .gitignore e .dockerignore al primo commit, non al cinquantesimo. Una chiave che è mai stata committata è compromessa anche dopo che il commit viene riscritto, perché l'oggetto sopravvive in clone e fork. Ruotala invece di riscrivere la history.
Limita ciò che il file può raggiungere. Assegna il file di environment all'utente di servizio e imposta la modalità 600. Combinato con un utente di servizio non-root, una dipendenza compromessa altrove sulla macchina non può semplicemente leggere le tue chiavi dal disco.
Delimita lo scope di ogni chiave presso l'emittente. Una chiave per agente, con i permessi più ristretti che il provider offre — sola lettura dove le letture bastano, prelievi disabilitati sulle chiavi di exchange, allowlist sull'IP del server. Un IP stabile è un vantaggio silenzioso dello spostarsi via dal laptop: l'allowlisting diventa finalmente possibile. Se più persone hanno bisogno delle stesse credenziali, mettile dietro il vault self-hosted descritto nella guida gemella.
Pianificazione. Cicli, timer e il fuso orario che ti morde.
"Girare continuamente" descrive tre architetture diverse, e scegliere quella sbagliata è una causa comune di lavoro duplicato ed esecuzioni mancate.
Il ciclo residente. Un unico processo di lunga durata che dorme tra un ciclo e l'altro. Il più semplice da ragionare, ed è la scelta predefinita giusta. Il suo punto debole è lo stato: tutto ciò che è in memoria va perso al riavvio, quindi tutto ciò che deve sopravvivere a un crash appartiene a SQLite o Postgres, non a una variabile.
L'esecuzione pianificata. Un processo che parte, esegue un'unità di lavoro ed esce. Un timer systemd con OnCalendar è lo strumento migliore qui, soprattutto grazie a Persistent=true: dopo un'interruzione, un timer persistente lancia l'esecuzione che ha mancato, mentre cron la salta semplicemente.
La coda. Un producer accoda i task, i worker li consumano. È ciò che serve nel momento in cui i task arrivano più velocemente di quanto vengano completati. Dà anche retry, gestione delle dead-letter e un tetto di concorrenza.
Due regole qualunque cosa tu scelga. Rendi ogni task idempotente — un supervisore che riavvia dopo un crash ritenterà i task, e un task ritentato non deve pubblicare due volte o ordinare due volte. E lascia l'orologio del server in UTC, convertendo solo ai margini: una pianificazione che si sposta di un'ora due volte l'anno è un bug tedioso da trovare.
Dare strumenti all'agente. Un tool server sulla stessa macchina.
Un agente senza strumenti è un ciclo di chat. Gli strumenti sono ciò che gli permette di leggere un repository, interrogare un database, piazzare un ordine o aprire un issue — e una volta che l'agente vive su un server, dovrebbero farlo anche loro.
Il Model Context Protocol è diventato il modo comune di esporre quegli strumenti, e un server che gestisci privatamente è facile da mettere accanto all'agente: stessa macchina, stessa interfaccia privata, nessuna esposizione pubblica necessaria. Le guide gemelle lo trattano per bene — ospitare un server MCP remoto illustra passo passo TLS, il trasporto streamable-HTTP, OAuth e l'agent card, mentre l'angolazione dell'hosting senza documento copre lo stesso stack dal lato identità.
Prima di tutto, bind su localhost. Se l'unico consumatore è l'agente sulla stessa macchina, il tool server non ha alcun motivo di tenere una porta pubblica. Fai il bind sull'indirizzo di loopback e salta il certificato. Esponilo pubblicamente solo quando una seconda macchina ne ha bisogno — e a quel punto servono TLS e autenticazione, non uno dei due.
Dai agli strumenti la minima autorità che funzioni. L'agente decide quale strumento chiamare in base al testo, e parte di quel testo viene dall'esterno. Il prompt injection non è ipotetico per un agente che legge pagine web o caselle di posta: è il caso atteso. Uno strumento che può solo leggere non può essere convinto a scrivere. Dove uno strumento deve scrivere, fai in modo che i percorsi distruttivi richiedano una conferma umana.
Se stai costruendo strumenti per gli agenti di altre persone piuttosto che per il tuo, l'API macchina e la superficie rivolta agli agenti documentano come questa piattaforma esponga il provisioning direttamente a un agente.
Osservabilità e costi. Cosa registrare, e l'interruttore d'emergenza per i runaway.
Due modalità di guasto dominano i deployment reali di agenti, e nessuna delle due è un crash. Una è l'agente che gira perfettamente e non produce nulla di utile. L'altra è l'agente che gira perfettamente e produce una bolletta API a quattro cifre in una notte.
Registra la forma, non il contenuto. Timestamp, id del task, numero di step, nomi degli strumenti invocati, totali dei token, durata, esito. Questo risponde a ogni domanda operativa che ti porrai davvero. Prompt e completion completi sono una trascrizione di tutto ciò che è mai stato chiesto all'agente, in chiaro, su un disco nell'edificio di qualcun altro.
Metti un tetto alla retention. journald continua a crescere finché non gli dici di smettere. SystemMaxUse e MaxRetentionSec in journald.conf mettono un tetto sia alla dimensione sia all'età. Un agente chiacchierone altrimenti riempie un disco in settimane, e un disco pieno fallisce in modi molto più difficili da leggere di un crash pulito.
Tre livelli di controllo della spesa. Presso il provider, un tetto rigido sulla chiave API — l'unico limite che nessun bug nel tuo codice può aggirare, e quello che si salta più spesso. Nell'agente, un contatore di token per esecuzione con una soglia di interruzione. Intorno all'agente, un numero massimo di step e un timeout in tempo reale, così un modello che discute con se stesso si ferma dopo venti iterazioni anziché quattromila.
Costruisci l'interruttore d'emergenza prima di averne bisogno. Un solo comando che ferma tutto: systemctl stop agent, oppure docker compose down. Assicurati che non richieda un laptop con sopra una chiave specifica. La differenza tra una brutta notte e un brutto mese è se fermare un runaway richiede dieci secondi o un'ora.
Il pavimento dell'identità. Cosa sa l'host — e da cosa non può proteggerti.
Un agente è un processo di lunga durata con credenziali, che agisce per tuo conto da un indirizzo stabile, in modo continuo. Questo rende il registro di locazione più interessante rispetto a un sito web statico: sta facendo cose a te attribuibili, ogni ora, per mesi.
Il pavimento qui è un indirizzo email e una password per iscriversi, pagamento in otto asset — Bitcoin, Ethereum, Tether su due chain, Monero, Litecoin, TRON e Solana — e nessun documento d'identità in nessuna fase. I data center si trovano in quattro regimi costituzionali nordici: Stoccolma, Helsinki, Oslo e Reykjavík. La dottrina operativa stabilisce cosa viene conservato; la pagina network copre il routing.
Ora il limite, che conta più del discorso di vendita. Un host che non chiede identità rimuove il registro di locazione. Non tocca il livello di inferenza: il tuo agente si autentica presso un provider di modello con una chiave legata a un account, da un IP stabile, a ogni chiamata. Se quell'account è a tuo nome legale — e per la maggior parte delle persone lo è — l'identità è stabilita lì, indipendentemente da chi affitta il ferro. Il livello dell'host rimuove un anello: uno vero, e solo uno.
Ciò che segue è poco affascinante. Compartimenta: un agente, un server, una chiave, un wallet. Fai l'hardening della macchina il giorno uno anziché il giorno trenta — la checklist della prima ora è un'ora ben spesa su una macchina che gira incustodita per mesi. Se l'agente deve raggiungere una rete privata, terminala sul server con un tunnel anziché esporre servizi — la guida al tunnel copre la configurazione. E paga in crypto da un wallet che non è quello da cui il tuo agente fa trading.
Niente di tutto questo è esotico, e niente di esso è una garanzia. È la disciplina ordinaria di far girare qualcosa che agisce per tuo conto mentre dormi — che è tutto ciò che significa il funzionamento continuo. Il resto del cluster è nell'indice delle guide.
Domande, con risposta.
Sette domande che gli sviluppatori si fanno prima di spostare un agente fuori da localhost — e nel primo mese successivo.
Quanto VPS serve per eseguire un agente AI 24/7?
Meno di quanto si pensi, perché l'inferenza avviene sull'hardware del provider, non sul tuo. Un agente che chiama un'API di modello hosted ed esegue un ciclo di polling è un processo I/O-bound: il piano Sentinel (2 vCPU, 4 GB RAM, 120 GB NVMe, $3.90/month) è più che sufficiente. Passa a Garrison (4 vCPU, 8 GB, $7.90/month) quando aggiungi Postgres, una coda e un modello di embedding locale.
Devo usare systemd o Docker per tenere l'agente in esecuzione?
Funzionano entrambi; cambiano le modalità di guasto. Una unit systemd con Restart=always è la via più breve per un singolo processo e ti dà gratis journald, limiti di risorse e ordinamento all'avvio. Docker con restart: unless-stopped è preferibile quando l'agente ha dei fratelli, perché Compose descrive l'intero insieme in un solo file. Ciò che conta di più è che tu lo abiliti davvero, e che tu testi un riavvio prima di allontanarti.
Perché il mio agente smette di riavviarsi dopo qualche crash?
Perché systemd limita la frequenza dei riavvii. StartLimitBurst e StartLimitIntervalSec permettono un piccolo numero di riavvii entro una finestra breve; superali e la unit entra nello stato failed e ci resta, il che sembra esattamente una morte silenziosa. O correggi il crash di fondo — la risposta corretta — oppure imposta StartLimitIntervalSec=0 per disabilitare il limitatore e RestartSec=10, in modo che un agente in crash-loop non bruci un core a forza di riprovare.
Dove metto le chiavi API?
In un file che l'immagine del container non vede mai. Tieni un file di environment fuori dal build context, referenziato tramite EnvironmentFile= nella unit systemd o env_file: in Compose, di proprietà dell'utente di servizio con modalità 600. Non usare mai ENV o ARG in un Dockerfile per un segreto: quei valori vengono incorporati nei layer dell'immagine e sono leggibili con docker history. Aggiungi il file a .gitignore e .dockerignore prima del primo commit.
Come evito che un agente spenda tutto il mio budget API in una notte?
Tre livelli, e li vuoi tutti e tre. Presso il provider: un tetto di spesa rigido sulla chiave API, l'unico limite che nessun bug nel tuo codice può aggirare. Nell'agente: conta token o chiamate per esecuzione e interrompi oltre una soglia. Intorno all'agente: un tetto di step per task e un timeout in tempo reale. Nessun host può farlo al posto tuo — un VPS è capacità in affitto, non un guardiano del budget su un'API altrui.
Cosa non dovrei mai scrivere nei log dell'agente?
Prompt e completion completi, argomenti grezzi degli strumenti, chiavi API, materiale di wallet e qualunque cosa un utente abbia digitato. Registra invece la forma dell'esecuzione: timestamp, id del task, numero di step, nomi degli strumenti, totali dei token, durata, esito. Un log dell'agente verboso è una trascrizione di tutto ciò che è mai stato chiesto all'agente, in chiaro, su un disco che non controlli fisicamente.
Un host senza KYC rende anonimo il mio agente?
No, ed è bene essere precisi. Un'iscrizione senza documento e un pagamento in crypto significano che l'host non ha alcuna identità legale da collegare al server. Non cambia nulla riguardo al provider del modello: il tuo agente si autentica a quell'API con una chiave legata a un account, da un IP del server stabile, a ogni chiamata. Il livello dell'host rimuove un anello della catena — il registro di locazione — ed è tutto ciò che rimuove.
Affitta un VPS senza KYC, paga in crypto, sposta l'agente fuori dal tuo laptop stanotte.
Sentinel — 2 vCPU, 4 GB RAM, 120 GB NVMe, banda illimitata, $3.90/month — regge un agente a ciclo singolo con margine anche per il suo tool server accanto. Un indirizzo email e una password per iscriversi; nessun documento in nessuna fase.
Ultima revisione · 2026-08-24 · Fonti · Pagine di manuale di systemd.service, systemd.timer e journald.conf, documentazione Docker restart-policy e Compose, specifica del Model Context Protocol, catalogo NordBastion · Cadenza · annuale
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Docker Compose, PostgreSQL, webhook funzionanti — l'automazione che possiede.
LLM in locale con Ollama su CPU, senza GPU — cosa entra in 4, 8, 16 o 32 GB.