Agente AI self-hosted su Proxmox: la guida LXC 2026

Perché i homelabber Proxmox mettono gli agenti AI in container LXC

Se hai già una macchina Proxmox che ronza sotto la scrivania con Pi-hole, Home Assistant e Nextcloud, aggiungere un agente AI self-hosted a quello stack è il passo successivo ovvio. La community homelab è convergenta in gran parte sulla stessa risposta: metti l'agente in un container LXC, non in una VM, non sull'host nudo. Un tutorial recente di Uptown4 e un articolo molto condiviso su dev.to su sette agenti autonomi in un cluster Proxmox a 3 nodi arrivano entrambi a LXC per lo stesso motivo: un container agente in idle consuma 200-400 MB di RAM e praticamente zero CPU, quindi puoi farne girare da cinque a otto su una macchina da 16 GB senza accorgertene.

Questo articolo mostra com'è davvero un agente AI self-hosted su Proxmox nel 2026: come dimensionare l'LXC, se far girare Docker al suo interno o andare nativo, come fare backup in modo che un upgrade sbagliato non ti costi la memoria dell'agente, e dove il passthrough della GPU vale lo sforzo. È scritto per chi conosce già Proxmox e vuole una ricetta concreta, non un'introduzione a Proxmox.

LXC vs VM per un agente AI: i numeri contano davvero

La domanda più frequente è se usare un container LXC o una VM QEMU completa. Per un agente AI testuale che parla con un'API LLM in cloud, LXC vince su tutti gli assi che contano per un homelabber.

Il divario di overhead è reale. Un LXC Debian nudo usa 30-60 MB di RAM prima di qualsiasi servizio, mentre una VM Debian con la stessa impronta ne usa 200-400, soprattutto perché il container non ha bisogno di kernel guest, QEMU o stato dei dispositivi virtio (fonte). L'overhead di CPU è intorno all'1-3% per LXC contro il 5-15% delle VM, e i container fanno il boot in 1-3 secondi invece di 30-90. Un cluster di produzione ha riportato 180 container LXC su hardware che prima gestiva 35 VM, una densità 5x maggiore.

Per un agente AI questo conta in modo concreto. Il runtime dell'agente in sé è piccolo: un processo Python o Node, un Postgres per lo stato e un listener di webhook. Il lavoro pesante avviene sulla GPU di qualcun altro, su OpenAI, Anthropic o una VM Ollama locale sullo stesso host. Il container è un coordinatore leggero, non un carico. Pagare l'overhead di una VM per ospitare un coordinatore è denaro che potresti spendere in più agenti.

L'unico punto in cui vincono le VM è l'isolamento. Se non ti fidi del codice dell'agente o delle sue estensioni, una VM è un confine più solido. Per un agente personale che hai scritto tu o un runtime open source che hai auditato, il modello a kernel condiviso di LXC va bene.

La ricetta di riferimento: LXC Ubuntu 22.04, 2 core, 2 GB, 8 GB di disco

Il dimensionamento di default per un primo agente AI self-hosted su Proxmox è piccolo di proposito. Puoi sempre far crescere il container, e non c'è motivo di riservare RAM che non stai usando.

Impostazione	Valore	Perché
Template	`ubuntu-22.04-standard`	La base meglio supportata per Docker, Node, Python
CPU	2 core	Il carico in idle è banale, ma le callback LLM sono picchi IO
RAM	2 GB	Margine sufficiente per Postgres più il processo dell'agente
Swap	512 MB	Assicurazione economica contro un picco di memoria in stile Chrome
Disco	8 GB local-lvm	Fallo crescere dopo se aggiungi un vector store su disco
Rete	vmbr0, DHCP	Dietro al tuo router, non direttamente sulla WAN
Non privilegiato	Sì	Default; tienilo così a meno che tu non voglia Docker
Features	`nesting=1, keyctl=1`	Solo se hai intenzione di far girare Docker dentro

Crealo dall'interfaccia Proxmox o con pct create da una sessione SSH sull'host. Se hai intenzione di far girare Docker dentro il container (vedi la sezione seguente), attiva nesting e keyctl in fase di creazione, non dopo; cambiarli in seguito vuol dire modificare la config e riavviare il container.

Una volta su, temperalo come qualsiasi macchina della famiglia Debian. Un utente non root con sudo, chiavi SSH invece delle password, unattended-upgrades attivo e il client Tailscale installato se vuoi raggiungerlo dal telefono senza aprire una porta sul router.

Docker dentro l'LXC, o systemd nativo?

Ci sono due filosofie per far girare davvero il processo dell'agente, e funzionano entrambe.

Docker dentro l'LXC. Installi Docker in un container Ubuntu 22.04 non privilegiato con nesting attivo e lanci l'agente da un docker-compose.yml. Questo rispecchia ciò che la maggior parte dei runtime di agente AI self-hosted rilascia, quindi segui le istruzioni esatte del vendor. Il costo è un po' di complessità: il container va creato con features: nesting=1,keyctl=1, e il debug a volte diventa il chiedersi se il problema è del container, di Docker o dell'agente. La guida di CoSci a Docker in un LXC Proxmox copre le flag necessarie in dettaglio.

systemd nativo. Salti Docker del tutto e installi l'agente, il suo runtime Python o Node e Postgres direttamente nell'LXC come servizi systemd. È più leggero, più semplice da ragionare, e va molto più d'accordo con gli snapshot LXC (stai fotografando un filesystem vero, non una pila di layer overlay). Il costo è che non tutti gli agenti open source pubblicano istruzioni systemd pulite, quindi potresti finire per tradurre un Dockerfile in una unit systemd a mano.

Per un primo setup, Docker dentro l'LXC è quasi sempre la scelta pragmatica, ti permette di seguire il runtime scelto senza deviazioni. Per un agente homelab a lunga vita che intendi aggiornare per anni, systemd nativo vale lo sforzo. Vedi la nostra guida agente AI self-hosted in Docker per la forma del compose-file a cui arrivano entrambe le strade.

Snapshot e backup: l'unica cosa che non puoi saltare

Un agente AI accumula memoria: conversazioni, embedding, job pianificati, preferenze per utente. Dopo un mese quel dato vale più del container stesso. Proxmox ti dà due strumenti correlati ma distinti per proteggerlo, e conviene essere espliciti sulla differenza: uno snapshot non è un backup. Uno snapshot vive sullo stesso disco del container, quindi un SSD morto si prende entrambi.

La ricetta a scala homelab che regge nella pratica:

Snapshot prima di ogni upgrade. Dalla scheda Snapshots del container fanne uno subito prima di apt upgrade, prima di modificare docker-compose.yml, prima di ribaltare una feature flag. Tornare indietro è un click se l'upgrade rompe il loop di tool dell'agente.
Backup notturni verso Proxmox Backup Server. PBS è lo strumento giusto: fa deduplicazione a lunghezza variabile, quindi sette backup notturni di un LXC da 4 GB stanno più vicini a 4 GB che a 28 GB. Fai girare PBS su una seconda macchinetta o su un NAS, non sullo stesso host Proxmox.
Modalità snapshot, non modalità stop. Per un agente con cui la gente parla su Telegram, la modalità snapshot è il default corretto: il container continua a girare durante il backup. La modalità stop è più sicura per i database ma perde i messaggi in arrivo.
Trattieni con una policy. Una retention comune che funziona per agenti personali: tieni gli ultimi 3 backup, giornalieri per 7 giorni, settimanali per 4 settimane, mensili per 6 mesi. Testa il ripristino almeno una volta, prima di averne davvero bisogno.

Se salti PBS, almeno spara archivi vzdump su un disco esterno con un cron. Perdere la memoria di un agente homelab per un disco morto è un brutto modo per scoprire che gli snapshot non sono mai stati backup.

GPU passthrough: quasi mai vale la pena

Il sogno seducente del homelab è una GPU locale che fa girare Ollama, abbinata a un agente LXC su Proxmox, in modo che tutto lo stack resti in casa. È tecnicamente possibile e, nel setup giusto, gratificante. Ma sii onesto sul trade-off.

La maggior parte dei homelab è limitata di banda per inferenza locale seria. Una singola RTX 3090 farà girare un modello da 32B a forse 30-50 token al secondo, cosa che va bene per una chat ma è lenta per un agente che fa tool call in loop. Qualsiasi cosa più grande richiede GPU professionali che costano più di un'auto usata. E la tassa operativa è reale: moduli kernel, particolarità del PCIe passthrough, aggiornamenti driver che rompono il namespace LXC, tutte cose per cui non ti sei iscritto quando volevi un assistente AI su Telegram.

Il pattern homelab pragmatico nel 2026 è il setup piccola scatola, grande cervello altrove. Fai girare l'agente in un LXC da 2 GB su un Mini-PC usato da 200 dollari che consuma centesimi di elettricità, e lascia che il modello viva su OpenRouter, OpenAI o Anthropic. La tua narrazione sulla privacy diventa "il codice dell'agente gira sul mio hardware, la chiamata API è senza stato, il provider non trattiene dati", che è difendibile ed economica. Se più avanti vuoi modelli locali per compiti specifici, metti Ollama su una VM gemella con GPU passthrough e lascia che l'agente la chiami come un provider tra tanti.

Quando Proxmox è la risposta sbagliata

Proxmox è fantastico se ti ci sei già impegnato. Se no, sii onesto su cosa vuoi davvero.

Vuoi solo un agente AI su Telegram. L'hosting gestito è un minuto e un caffè. Proxmox è un weekend e un Mini-PC usato. Vedi la nostra analisi sui prezzi di Hermes Agent self-hosted vs gestito.
Non usi ancora Proxmox. La curva di apprendimento di Proxmox vale per un homelab da 10 servizi, non per un singolo agente AI. Un VPS da 5 dollari e Docker Compose ti portano lì in una sera.
Vuoi un confine di sicurezza forte tra l'agente e tutto il resto della scatola. Usa una VM, non un LXC, o una macchina separata del tutto.

L'alternativa Hermify: stessa proprietà, senza container

C'è una via di mezzo su cui molti homelabber finiscono dopo qualche ciclo di upgrade. Fai girare le cose noiose su Proxmox (Home Assistant, media, rete) e lascia che un Hermes Agent gestito si occupi del lato AI. Mantieni la stessa narrazione "i tuoi dati, la tua chiave del modello, il tuo agente" senza un LXC da coccolare né una policy di retention PBS a cui pensare. Hermify gestisce la flotta di container, tu porti la tua chiave OpenRouter o OpenAI, e l'agente vive su Telegram in circa un minuto. Inizia con Hermify se quel trade ti sembra più interessante di un altro nodo nel tuo cluster.