Un agente IA è raramente un singolo processo. C'è il loop dell'agente stesso, uno store vettoriale per la memoria, una cache, di solito un database per lo stato, e forse una piccola dashboard. Eseguire ciascuno a mano — avviarli, riavviarli dopo un reboot, ricordare quale porta è quale — stanca in fretta. Docker Compose descrive il tutto in un file e lo esegue con un comando. Questo è lo stack copia-incolla per mettere un agente su un VPS in modo ordinato.
Se vuoi solo la versione deploy-senza-Docker, la guida esegui un agente IA 24/7 copre systemd. Questa pagina è la versione container-native.
Lo stack
Un tipico agente self-hosted vuole quattro cose accanto a sé: il processo dell'agente, Qdrant (memoria vettoriale), Redis (cache / code) e Postgres (stato). Ecco un docker-compose.yml che esegue tutto ciò, con i servizi interni tenuti lontani dall'internet pubblico:
# /opt/agent/docker-compose.yml
services:
agent:
build: . # your agent image (or image: your/agent:latest)
restart: unless-stopped
env_file: [.env] # OPENAI/ANTHROPIC keys etc. — never in this file
environment:
QDRANT_URL: http://qdrant:6333
REDIS_URL: redis://redis:6379
DATABASE_URL: postgres://agent:${DB_PASSWORD}@postgres:5432/agent
depends_on: [qdrant, redis, postgres]
# no ports: — this agent only makes outbound calls. Publish one only if it serves webhooks.
qdrant:
image: qdrant/qdrant:latest
restart: unless-stopped
volumes: ["qdrant:/qdrant/storage"] # internal only — not published
redis:
image: redis:7-alpine
restart: unless-stopped
command: ["redis-server", "--save", "60", "1"]
volumes: ["redis:/data"]
postgres:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_USER: agent
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_DB: agent
volumes: ["pg:/var/lib/postgresql/data"]
volumes: { qdrant: {}, redis: {}, pg: {} }
I segreti vivono in .env, non nel file compose:
# /opt/agent/.env (chmod 600, never committed)
ANTHROPIC_API_KEY=sk-ant-...
DB_PASSWORD=a-long-random-string
Tiralo su:
apt update && apt install -y docker.io docker-compose-v2
systemctl enable --now docker
cd /opt/agent && docker compose up -d
docker compose logs -f agent
Ogni servizio interno (Qdrant, Redis, Postgres) è raggiungibile solo sulla rete compose tramite il nome del servizio — nessuno di essi è pubblicato su internet. L'agente ci parla su quella rete privata, e nulla su quelle porte è rivolto al mondo.
I dettagli che contano
restart: unless-stoppedsu ogni servizio — è ciò che sopravvive a un reboot o crash. Abilita Docker al boot e l'intero stack torna da solo.- Chiavi in
.env, non in YAML. Referenziale come variabili env; tieni.envachmod 600e fuori da git. Un file compose trapelato con una chiave attiva è l'errore classico. - Non pubblicare nulla che non serva. Un agente che chiama solo le API dei modelli e i propri servizi non ha bisogno di alcuna porta in ingresso — quindi un piano NAT va bene. Aggiungi un IP dedicato solo se serve webhook o una dashboard.
- Dimensiona per memoria, non per core. Gli agenti basati su API sono leggeri. Quando l'indice di Qdrant cresce o aggiungi un modello locale, è lì che sali — vedi VPS ad alta memoria per agenti.
La parte che è davvero nostra: l'agente può costruirsi la propria macchina
Poiché EQVPS espone un server MCP, un agente che esegue questo stack può fornire da sé un altro VPS pulito — ordinarlo, ottenere root, smontarlo — pagando da un saldo cripto prepagato. Uno stack compose che ha bisogno di un sandbox fresco può tirarne su uno senza un umano nel loop.
Perché EQVPS per un agente dockerizzato
- Immagini pulite, root in ~60 secondi. Ubuntu/Debian;
docker compose upe lo stack è attivo. - Niente KYC, pagamento in cripto. Email per registrarti, USDC/USDT per pagare — nulla lega la macchina alla tua identità.
- NVMe + 1 Gbit/s non misurato, UE (Germania/Finlandia). Tirare immagini e spedire log non produrrà una bolletta a sorpresa.
VPS per agenti IA (la panoramica) → · VPS per Docker → · Ospita un DB vettoriale per la memoria dell'agente →
Commenti
Ancora nessun commento. Sii il primo.