Self-Hosted AI Agent on Proxmox: The 2026 LXC Guide

Why Proxmox Homelabbers Are Running AI Agents in LXC Containers

If you already have a Proxmox box humming under your desk with Pi-hole, Home Assistant, and Nextcloud on it, adding a self-hosted AI agent to that stack is the obvious next move. The homelab community has largely converged on the same answer for how to do it: put the agent in an LXC container, not a VM, not on the bare host. A recent Uptown4 walkthrough and a widely shared dev.to write-up of seven autonomous agents on a 3-node Proxmox cluster both land on LXC for the same reason: an agent container idles at 200-400MB of RAM and near-zero CPU, so you can run five to eight of them on a 16GB machine without noticing.

This post walks through what a self-hosted AI agent on Proxmox actually looks like in 2026: how to size the LXC, whether to run Docker inside it or go native, how to back it up so a bad upgrade does not cost you your memory store, and where GPU passthrough is worth the trouble. It is written for someone who already knows Proxmox and wants a concrete recipe, not a Proxmox intro.

LXC vs VM for an AI Agent: The Numbers Actually Matter

The most common question is whether to use an LXC container or a full QEMU VM. For a text-based AI agent talking to a cloud LLM API, LXC wins on every axis that matters to a homelabber.

The overhead gap is real. A bare Debian LXC uses 30-60MB of RAM before you run any services, while a Debian VM with the same footprint uses 200-400MB, mostly because the container does not need a guest kernel, QEMU, or virtio device state (source). CPU overhead lands around 1-3% for LXC versus 5-15% for VMs, and containers boot in 1-3 seconds instead of 30-90. One production cluster reported running 180 LXC containers on hardware that previously handled 35 VMs, a 5x density improvement.

For an AI agent this matters concretely. The agent runtime itself is small: a Python or Node process, a Postgres for state, and a webhook listener. The heavy work is happening on someone else's GPU, in OpenAI or Anthropic or a local Ollama VM on the same host. The container is a light coordinator, not a workload. Paying VM overhead to host a coordinator is money you could spend on more agents.

The one place VMs win is isolation. If you do not trust the agent's code or its extensions, a VM is a stronger boundary. For a personal agent you wrote or an open-source runtime you audited, LXC's shared-kernel model is fine.

The Reference Recipe: Ubuntu 22.04 LXC, 2 Cores, 2GB, 8GB Disk

The default sizing for a first self-hosted AI agent on Proxmox is small on purpose. You can always grow the container, and there is no reason to reserve RAM you are not using.

Setting	Value	Why
Template	`ubuntu-22.04-standard`	The best-supported base for Docker, Node, Python
CPU	2 cores	Idle load is trivial, but LLM callbacks are IO-bound spikes
RAM	2GB	Enough headroom for Postgres plus the agent process
Swap	512MB	Cheap insurance against a Chrome-like memory spike
Disk	8GB local-lvm	Grow later if you add a vector store on disk
Network	vmbr0, DHCP	Behind your router, not directly on WAN
Unprivileged	Yes	Default; keep it unless you need Docker
Features	`nesting=1, keyctl=1`	Only if you plan to run Docker inside

Create it from the Proxmox UI or with pct create from an SSH session on the host. If you plan to run Docker inside the container (see the next section), toggle nesting and keyctl on when you create it, not after; changing them later means editing the config and rebooting the container.

Once the container is up, harden it the way you would any Debian family box. A non-root user with sudo, SSH keys instead of passwords, unattended-upgrades enabled, and the Tailscale client installed if you want to reach it from your phone without opening a port on your router.

Docker Inside the LXC, or Native Systemd?

There are two philosophies for how to actually run the agent process, and they both work.

Docker inside the LXC. You install Docker in an unprivileged Ubuntu 22.04 container with nesting enabled, then run the agent from a docker-compose.yml. This mirrors what most self-hosted AI agent runtimes ship, so you follow the vendor's exact instructions. The cost is a bit of complexity: the container has to be created with features: nesting=1,keyctl=1, and troubleshooting sometimes means asking whether a problem is a container issue, a Docker issue, or an agent issue. The CoSci guide to Docker in a Proxmox LXC covers the required flags in detail.

Native systemd. You skip Docker entirely and install the agent, its Python or Node runtime, and Postgres directly in the LXC as systemd services. This is lighter, easier to reason about, and plays much nicer with LXC snapshots (you are snapshotting an actual filesystem, not a stack of overlay layers). The cost is that not every open-source agent publishes clean systemd install instructions, so you may end up translating a Dockerfile into a systemd unit yourself.

For a first setup, Docker inside the LXC is almost always the pragmatic choice - it lets you follow whichever runtime you picked without deviation. For a long-lived homelab agent you plan to upgrade for years, native systemd is worth the effort. See our self-hosted AI agent in Docker guide for the compose-file shape either path ends up with.

Snapshots and Backups: The One Thing You Cannot Skip

An AI agent accumulates memory: conversations, embeddings, scheduled jobs, per-user preferences. A month in, that state is worth more than the container itself. Proxmox gives you two related but distinct tools for protecting it, and it is worth being explicit about the difference: a snapshot is not a backup. A snapshot lives on the same disk as the container, so a dead SSD takes both.

The homelab-scale recipe that actually holds up:

Snapshot before every upgrade. From the container's Snapshots tab, take one right before you apt upgrade, before you edit docker-compose.yml, before you flip a feature flag. Rolling back is a click if the upgrade breaks the agent's tool loop.
Nightly backups to Proxmox Backup Server. PBS is the right tool: it does variable-length deduplication, so seven nightly snapshots of a 4GB LXC use closer to 4GB than 28GB. Run PBS on a second small box or a NAS, not on the Proxmox host itself.
Snapshot mode, not stop mode. For an agent that people talk to on Telegram, snapshot mode is the right default: the container keeps running during the backup. Stop mode is safer for databases but drops incoming messages.
Retain with a policy. A common retention that works for personal agents: keep the last 3 backups, daily for 7 days, weekly for 4 weeks, monthly for 6 months. Test the restore path at least once, before you actually need it.

If you skip PBS, at least send vzdump archives to an external disk on a cron. Losing a homelab agent's memory to a dead disk is a bad way to discover that snapshots were never backups.

GPU Passthrough: Almost Always Not Worth It

The seductive homelab dream is a local GPU running Ollama, paired with a Proxmox LXC agent, so the whole stack stays inside your walls. It is technically possible and, for the right setup, satisfying. But be honest about the trade.

Most homelabs are bandwidth-constrained for serious local inference. A single RTX 3090 will run a 32B model at maybe 30-50 tokens per second, which feels fine for a chat but sluggish for an agent that makes tool calls in a loop. Anything bigger needs professional GPUs that cost more than a used car. And the operational tax is real: kernel modules, PCIe passthrough quirks, driver upgrades that break the LXC namespace, all of which you did not sign up for when you wanted an AI assistant on Telegram.

The pragmatic homelab pattern in 2026 is the small box, big brain elsewhere setup. Run the agent in a 2GB LXC on a $200 used Mini-PC that costs pennies of electricity, and let the model live on OpenRouter or OpenAI or Anthropic. Your privacy story is "the agent's code runs on my hardware, the API call is stateless, no data is retained by the provider," which is defensible and cheap. If you later want local models for specific tasks, put Ollama on a sibling VM with GPU passthrough and let the agent call it as one provider among several.

When Proxmox Is the Wrong Answer

Proxmox is fantastic if you have already committed to it. If you have not, be honest about whether it is what you actually want.

You just want an AI agent on Telegram. Managed hosting is a minute and a coffee. Proxmox is a weekend and a used Mini-PC. See our take on self-hosted vs managed Hermes Agent pricing.
You do not already run Proxmox. The Proxmox learning curve is worth it for a 10-service homelab, not for one AI agent. A $5 VPS and Docker Compose gets you there in an evening.
You want a strong security boundary between the agent and everything else on the box. Use a VM, not an LXC, or use a separate machine entirely.

The Hermify Alternative: Same Ownership, No Container

There is a middle path that a lot of homelabbers actually settle on after a few upgrade cycles. Run the boring things on Proxmox - Home Assistant, media, network - and let a managed Hermes Agent handle the AI side. You get the same "your data, your model key, your agent" ownership story, without the LXC to babysit or the PBS retention policy to think about. Hermify runs the container fleet, you bring your OpenRouter or OpenAI key, and the agent lives on Telegram in about a minute. Get started with Hermify if that trade is more interesting than another node in your cluster.