Distribuire un agente AI su VPS Hetzner: guida completa 2026

Perché Hetzner torna sempre quando si parla di agenti self-hosted

Se hai passato un po' di tempo nell'angolo del self-hosting di dev.to, Medium o nei gruppi Telegram di indie-AI, avrai notato lo stesso schema: quando qualcuno chiede dove far girare un agente AI sempre attivo per meno del prezzo di due caffè, la risposta più gettonata è Hetzner Cloud. La community continua ad arrivare lì per due motivi che sono rimasti stabili per anni: prestazioni reali della CPU per euro speso e un Cloud Firewall pulito che puoi configurare prima ancora che il server si avvii.

Questa guida è pensata per chi ha deciso di fare self-hosting di un agente AI (Hermes Agent, OpenClaw, una configurazione n8n con un nodo LLM o qualsiasi altra cosa che chiami un'API di un modello da un server sempre attivo) e vuole farlo su Hetzner senza saltare le parti che contano davvero alle 3 di notte. Dimensionamento, hardening, Docker Compose, un test del canale Telegram e l'elenco onesto delle cose che prima o poi andranno storte.

Se stai ancora decidendo quale VPS economico usare, il nostro confronto dei VPS economici copre il panorama più ampio. Questo articolo presuppone che tu abbia scelto Hetzner.

Passo 1: scegli il piano giusto

A metà 2026 Hetzner Cloud divide i suoi piani con vCPU condivise in tre linee:

• CX (Intel) - vecchie vCPU condivise Intel, in via di dismissione in alcune regioni
• CPX (AMD EPYC) - lo standard x86 attuale, il più veloce su singolo thread
• CAX (ARM Ampere) - la linea più economica, con un rapporto prestazioni/euro molto forte

Per un agente AI guidato da API (uno che chiama OpenAI, Anthropic, OpenRouter o la tua macchina Ollama e orchestra le chiamate agli strumenti localmente) il piano che vuoi è il più piccolo in una qualsiasi di queste linee:

I prezzi per la regione USA sono leggermente più alti (circa $4,59-$4,99 per la specifica CX22 equivalente). Hetzner ha aggiornato i prezzi il 15 giugno 2026 - i nuovi ordini usano la nuova tariffa, i server esistenti mantengono la vecchia tariffa finché non li ridimensioni.

Raccomandazione: inizia con CAX11 o CX22. Due vCPU e 4 GB di RAM bastano per un singolo agente, un gateway Telegram, un piccolo reverse proxy e un daemon Docker, con margine per l'occasionale task headless-browser. Se prevedi di far girare più agenti, fare scraping di pagine con Playwright o eseguire skill in batch durante la notte, passa a CPX21.

Se il runtime del tuo agente non distribuisce ancora un'immagine ARM, resta su CX22 o CPX11. La maggior parte dei runtime più diffusi (Hermes Agent, OpenClaw, n8n) oggi distribuisce immagini linux/arm64, quindi la linea CAX è di solito una scelta praticabile.

Passo 2: provisiona e blinda il server prima dell'SSH

Questo è il passo che si salta più spesso e che presenta il conto più avanti. Hetzner ti dà due firewall (il Cloud Firewall a livello edge e l'UFW a livello host). Usali entrambi. Il Cloud Firewall è quello da configurare prima che il server si avvii, così non accetta mai un solo pacchetto su una porta che non intendi aprire.

Nella Hetzner Console, crea un Cloud Firewall con queste regole in entrata:

• TCP 22 solo dal tuo IP (o da un piccolo CIDR se hai un intervallo d'ufficio fisso)
• TCP 80 da 0.0.0.0/0, ::/0 (solo se farai girare un reverse proxy su questa macchina)
• TCP 443 da 0.0.0.0/0, ::/0 (solo se ti serve HTTPS per webhook o un'interfaccia web)
• ICMP da 0.0.0.0/0, ::/0 (così ping funziona per il monitoraggio)

In uscita: lascia il "consenti tutto" predefinito - l'agente deve poter raggiungere l'API del modello.

Ora crea il server, collega il firewall e scegli Ubuntu 24.04 LTS. Nel pannello delle chiavi SSH, aggiungi la chiave pubblica del tuo portatile. Non consentire il login con password.

Una volta che il server è attivo, accedi via SSH come root e fai subito quattro cose:

# 1. Patch
apt update && apt upgrade -y && apt install -y ufw fail2ban unattended-upgrades

# 2. Create a non-root user
adduser --disabled-password --gecos "" agent
usermod -aG sudo agent
mkdir -p /home/agent/.ssh && cp ~/.ssh/authorized_keys /home/agent/.ssh/
chown -R agent:agent /home/agent/.ssh && chmod 600 /home/agent/.ssh/authorized_keys

# 3. Lock down SSH
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

# 4. Host firewall (UFW), redundant with Cloud Firewall but a useful safety net
ufw default deny incoming && ufw default allow outgoing
ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp
ufw --force enable

Poi abilita gli aggiornamenti di sicurezza non presidiati e fail2ban con impostazioni predefinite ragionevoli:

dpkg-reconfigure -plow unattended-upgrades   # answer Yes
systemctl enable --now fail2ban

Fail2ban, per impostazione predefinita, bandisce gli IP dopo 5 tentativi SSH falliti entro 10 minuti. Il Cloud Firewall ne scarta già la maggior parte all'edge, ma fail2ban intercetta tutto ciò che riesce a passare (un collega, un runner CI mal configurato, te stesso).

Esci da root, rientra come agent e prosegui da lì.

Passo 3: installa Docker

Docker è il modo più pulito per far girare un agente AI su un VPS nel 2026. L'agente resta isolato, le dipendenze non inquinano l'host e gli aggiornamenti sono a un pull && up di distanza.

# As the agent user, with sudo
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker agent
newgrp docker
docker run --rm hello-world

Se hello-world stampa il suo output, Docker è pronto.

Passo 4: distribuisci l'agente con Docker Compose

Crea ~/agent/docker-compose.yml sul server. L'esempio qui sotto è per Hermes Agent, ma la struttura è identica per OpenClaw, Open WebUI + un provider LLM o qualsiasi altro runtime di agente containerizzato.

services:
  agent:
    image: ghcr.io/your-runtime/agent:latest
    container_name: agent
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./data:/data
      - ./skills:/skills
      - ./memory:/memory
    ports:
      - "127.0.0.1:8080:8080"   # web UI bound to localhost only

Poi crea ~/agent/.env:

# Model provider (BYOK - bring your own key)
OPENAI_API_KEY=sk-...
# Or any of:
# ANTHROPIC_API_KEY=...
# OPENROUTER_API_KEY=...

# Messaging gateway
TELEGRAM_BOT_TOKEN=...
TELEGRAM_ALLOWED_USERS=12345678   # your Telegram user ID

# Persistence
DATA_DIR=/data
MEMORY_DIR=/memory

chmod 600 .env così altri utenti sulla macchina non possono leggere le tue chiavi, poi avvialo:

docker compose up -d
docker compose logs -f agent

La policy restart: unless-stopped è ciò che mantiene l'agente vivo attraverso i riavvii. Se preferisci un'installazione nativa invece di Docker, l'equivalente è un'unità systemd con Restart=always e WantedBy=multi-user.target.

Passo 5: collega Telegram e fai un test

Se hai scelto Telegram come superficie di messaggistica (la maggior parte di chi fa self-hosting lo fa, perché la Bot API è gratuita e istantanea), il ciclo di test è breve:

1. Parla con @BotFather su Telegram, esegui /newbot, salva il token nel .env.
2. Parla con @userinfobot per ottenere il tuo ID utente Telegram numerico, mettilo in TELEGRAM_ALLOWED_USERS.
3. docker compose restart agent.
4. Apri il tuo nuovo bot su Telegram e invia "hello".

Dovresti vedere una risposta entro pochi secondi. Se non la vedi, docker compose logs -f agent di solito punta dritto al problema (token mancante, ID utente consentito sbagliato, provider del modello che restituisce 401).

Per una guida molto più approfondita sul lato Telegram (gruppi, topic, modalità vocale, risoluzione dei problemi), vedi come costruire un agente AI su Telegram.

Passo 6: backup e monitoraggio (la parte che tutti saltano)

Due cose economiche che si ripagano da sole la prima volta che qualcosa si rompe:

• Snapshot di Hetzner: nella Console, abilita uno snapshot giornaliero del server. Circa €0,012/GB/mese, attorno a €0,50/mese per un disco da 40 GB. Etichettane uno come "before-update" prima di ogni docker compose pull.
• Un ping di uptime: gratuito con BetterStack o UptimeRobot. Fai in modo che colpisca https://your-domain/health (o anche solo un controllo TCP) ogni 5 minuti. La prima volta che il gateway Telegram perderà la connessione alle 3 di notte, lo saprai prima di pranzo invece che a pranzo.

Per lo stato dell'agente stesso (file di memoria, skill, cronologia delle conversazioni), metti un cron job di una riga che fa il tar del volume montato in /var/backups/agent-$(date +%F).tar.gz e ruota le copie più vecchie. Fai un rsync di quello fuori dalla macchina ogni settimana verso un secondo VPS economico, un bucket compatibile con S3 o il tuo portatile.

Passo 7: aggiornamenti

Una volta a settimana, con lo snapshot già fatto:

cd ~/agent
docker compose pull
docker compose up -d
docker image prune -f

Di solito tutto richiede meno di un minuto. Se la nuova immagine si rompe, ripristina lo snapshot dalla Hetzner Console - l'unico stato che perdi sono le conversazioni tra lo snapshot e adesso, che risiedono nel volume di memoria dell'agente.

Cosa prima o poi si rompe

Un elenco breve e onesto:

• Il long-polling di Telegram cade durante lunghi cali di rete. La maggior parte dei runtime si riconnette automaticamente, ma se il tuo non lo fa, è il ping di uptime a intercettarlo.
• docker compose pull porta con sé un cambio di configurazione che rompe tutto. Fissa il tag dell'immagine a una versione specifica in produzione invece di usare :latest.
• Il provider del modello ti limita la frequenza (rate-limit) e l'agente smette di rispondere senza un errore evidente. Logga sempre lo stato HTTP del provider e preferisci provider con dashboard di utilizzo.
• Un disco si riempie perché una skill scrive su /tmp senza rotazione. du -sh /* e docker system df dovrebbero far parte della tua memoria muscolare di debugging.
• Ti dimentichi la regola del firewall quando aggiungi un secondo servizio. Entrambi i firewall (Cloud + UFW) hanno bisogno della nuova porta, altrimenti passi 20 minuti a fare debug di "connection refused" dall'indirizzo giusto.

Nessuno di questi è specifico di Hetzner. Sono la tassa che paghi per far girare qualsiasi cosa da solo.

Quando i conti del VPS non tornano più

Se stai leggendo questo e i passi qui sopra ti sembrano interessanti - ottimo, è esattamente il flusso di lavoro per cui Hetzner è valido. Economico, veloce, trasparente.

Se ti sembrano una tassa su un fine settimana, il confronto cambia. L'hosting gestito scambia €4/mese e un pomeriggio di domenica con una configurazione che include già il gateway Telegram, il BYOK verso il tuo provider, i volumi di memoria persistente, gli snapshot e "resta semplicemente su". La nostra guida hosting vs self-hosting ripercorre tutti i conti, incluso quanto vale il tuo tempo.

Inizia con Hermify se vuoi la strada gestita - un agente su infrastruttura di produzione in meno di 30 minuti, nessun Cloud Firewall da configurare e nessun fail2ban da mettere a punto. Se invece preferisci farlo da solo su Hetzner, questa guida dovrebbe portarti a destinazione.

Fonti

• Hetzner Cloud Pricing 2026 - bestusavps.com
• Hetzner Price Adjustment - Hetzner Docs
• Hetzner Data Center Locations - Hetzner Docs
• Basic Cloud Config - Hetzner Community
• Running an AI Agent on a VPS: Security-First Setup - Medium / Tim Daniel Walter
• How to Deploy an AI Agent to Production - Paxrel
• Running AI Coding Agents on Hetzner - Pere Villega