Proxmox setup — analysis, alternatives & what we left out

Part 1

The steps, re-examined

Each guide step made one choice for clarity. Here's the reasoning and the roads not taken.

Creating the container — LXC, the default

We chose: a single Ubuntu LXC container called ai-box, created through the Proxmox web UI.

Why: an LXC is light, starts instantly, and sips resources — one always-on box for the whole house without the overhead of a full virtual machine. The UI wizard is the most teachable path.

Alternatives worth knowing

A full VM instead of an LXC. A VM is a complete, separately-kernelled virtual computer — stronger isolation and security, the obvious choice if you want the AI box truly walled off from the host and everything else. The trade is weight: more RAM, slower to boot, heavier on the host. An LXC is lighter but shares the host kernel, so its isolation is weaker. For autonomous agents that run unattended, a VM is the more defensible choice.
Unprivileged vs privileged LXC. The guide didn't stress this and should have: an unprivileged container (root inside ≠ root on the host) is meaningfully safer and is the right default. A privileged container is easier for some hardware tricks but a much bigger risk if anything inside is compromised. Create it unprivileged unless you have a specific reason not to.
Proxmox community helper-scripts (community-scripts.github.io, formerly tteck's) create a container in one line — real convenience, but they're community-maintained code you're running as root on your host. Convenience vs. trust: only run them if you trust the source, and read what they do first.

2–4 · ✦

Inside the container — Node, the agents & Hermes

We chose: install Node LTS, then npm-install Claude Code, Codex, and Gemini, plus Hermes as the bonus 4th agent — all inside the container.

Why: once the container exists, it's just a small Linux machine. From here the setup is identical to the Linux guide, so the reasoning and alternatives are the same too.

Same as the Linux guide

Everything inside the container — Node version managers, the native Claude Code installer, model choices, editor extensions, Codex's GPT-5.5 refresh and Claude's Opus 4.7 — is covered in the Linux guide and its analysis. Don't duplicate the reasoning; the container is Linux.
Hermes (Nous Research's self-improving, model-agnostic agent) installs natively in the container too — a good reminder that "the big three" isn't the whole field.

Tailscale — the network & the TUN grant

We chose: Tailscale, with two options — on the host, or inside the container after granting it the host's TUN device.

Alternatives & the trade-off

Running Tailscale on the Proxmox host is the simpler, cleaner option — the container reaches the tailnet through the host and you never touch its config. We led with the in-container route for self-containment, but host-side is often the better call.
The TUN device grant has security implications. The two lxc.cgroup2.devices.allow / lxc.mount.entry lines hand the container direct access to a host kernel device — that widens what the container can do and weakens its isolation. It's the right trade for many people, but it is a trade. Running Tailscale on the host avoids it entirely.
ZeroTier / Netbird / raw WireGuard are all alternatives, same as elsewhere on the network. We didn't cover Tailscale ACLs in the guide — they're how you stop a misbehaving agent box from reaching everything else. Covered in Security below.

Ollama & the GPU

We chose: Ollama + llama3.2 inside the container, CPU-only by default, with GPU passthrough noted as advanced.

Alternatives & the GPU question

GPU passthrough to a VM is the cleaner, more isolated path: dedicate the NVIDIA card to a VM, install the drivers there, and run Ollama in that VM. It's better walled off and the drivers behave more predictably.
Bind-mounting the GPU into an LXC is lighter (no full VM) but genuinely advanced — driver-version matching on host and container, device passthrough config, and a weaker isolation story. Worth it only once you're comfortable.
Better models (qwen3, deepseek-r1, gemma3) and the LM Studio / Jan / llama.cpp alternatives are the same as in the Linux analysis. llama3.2 is a gentle start, not the ceiling. Without a GPU, keep models small or use a GPU cloud.

Optional · the editor route

The editor route — never on the host, always on the workload

Proxmox is the hypervisor — the box that runs the box that runs the agents. The editor question on Proxmox has a hard rule baked into it: never put an editor (or any GUI tool) on the host itself. The host's job is to be lean, predictable, and snapshot-and-restore reliable. Editors belong on the workload — the LXC or VM you actually code in. Once you accept that, the editor route on Proxmox is cleaner than on any other platform on this site, because snapshots make experimentation cheap. Here are the two paths that work, and the one that doesn't.

The two real paths on Proxmox

Path A (recommended): VS Code on your laptop + Remote-SSH into the ai-box LXC. Install VS Code locally (Mac, Windows, or Linux); install the official Remote Development extension pack; Connect to Host… the LXC's Tailscale name or LAN IP. Your editor lives on your laptop; the agent CLIs and files live in the container. The host runs neither — exactly what you want.
Path B (browser-based): a dedicated code-server LXC. Make a separate Ubuntu LXC just for code-server, install via the one-line script (curl -fsSL https://code-server.dev/install.sh | sh), bind it to 127.0.0.1:8080 and reach it over Tailscale. Snapshot the LXC before first use; revert with one click if it ever misbehaves. Useful when your client device is a Chromebook, iPad, or browser-only.
Path X (don't): VS Code on the Proxmox host. The Proxmox host is intentionally a near-minimal Debian. Installing a desktop environment, a graphical editor, or anything that ships its own runtimes against the host's libraries fights the hypervisor's job and breaks its snapshot/restore guarantees. Use a VM or LXC; never the host.

Set up Path A — laptop VS Code + Remote-SSH into the LXC

Inside the LXC, install openssh-server and add your public SSH key to the user you'll connect as (not root). On an unprivileged LXC this is the same step as on any Linux box.
From the Proxmox host, note the LXC's IP (pct exec <CTID> -- ip a) — or, if you've joined the LXC to your tailnet, just its tailnet hostname.
On your laptop, install VS Code (winget install Microsoft.VisualStudioCode on Windows / brew install --cask visual-studio-code on Mac) and the official Remote Development extension pack.
Connect: F1 → Remote-SSH: Connect to Host… → ai@ai-box-tailscale-name. The agent CLIs and your project files are on the LXC; everything you see and click is on the laptop.
Snapshot first. Take a Proxmox snapshot of ai-box before letting an agent loose. A bad agent run becomes a one-click revert in the Proxmox UI.

Set up Path B — a dedicated code-server LXC

Create a new unprivileged Ubuntu LXC (e.g. code-server, 2 GB RAM, 2 cores) — keep it separate from ai-box so a code-server compromise can't touch the agents' files directly.
Install code-server in the LXC: curl -fsSL https://code-server.dev/install.sh | sh, then systemctl --user enable --now code-server. Bind it to 127.0.0.1:8080, not 0.0.0.0.
Reach it over Tailscale only. Join the LXC to your tailnet; open http://code-server.tail-net:8080 from a tailnet device. Never expose port 8080 to the open internet, and never reverse-proxy code-server through a public name.
Snapshot before first use and after every meaningful config change. A clean baseline is half the value of running an editor in an LXC at all.
Mount the agents' code into code-server with an LXC bind mount or NFS share so you're editing the same files the ai-box agents see — otherwise you're working on a copy.

Pick one or two AI extensions, not all of them

Claude Code for VS Code (Anthropic, official) — companion to the same CLI the agents in ai-box use; works in both Path A and Path B.
GitHub Copilot + Copilot Chat — multi-model autocomplete and chat (Claude Sonnet 4.6, GPT-5.5, Gemini 2.5). Subscription.
Cline — agentic coding in the editor; bring your own key, including a local Ollama you've put on a sibling LXC. The closest in-editor analog to Claude Code's autonomous mode.
Continue — open-source, bring-your-own-model; the right pick if you want to point at a local Ollama LXC and keep the loop on-box.
Codex VS Code extension / Gemini Code Assist — the editor companions to the CLIs in ai-box.

Five minutes to set it up well

Don't run any editor or its services as root inside the LXC. Same hygiene as the Linux analysis: a non-root user, sudo when needed, never an editor running as root.
Pin code-server to its own LXC. The reason it's a separate container, not a service inside ai-box, is so a misbehaving extension can't read every file the agents touch.
Lock down what extensions can read. Add .env, .git, node_modules, .secrets/ to files.exclude in .vscode/settings.json so AI extensions don't index them.
Set LXC resource caps. Both ai-box and the code-server LXC should have explicit CPU and RAM limits (Part 2 covers this) so a runaway extension or agent can't pin the whole host.
Snapshot before, vzdump backup after. Snapshots are local rollback; vzdump (or PBS) is the off-host backup. The editor route makes both more valuable, not less.

Pros — what the editor route gives you on Proxmox

Snapshots make experimentation free. The single biggest pro on this page: try an autonomous agent + a sketchy extension, revert in seconds. No other platform offers that.
Hard isolation between editor and agent. Path B's separate LXC means a compromised editor can't reach the agent's project folders unless you mount them in.
Remote-SSH is genuinely a superpower for a home lab — your laptop edits code that lives on a dedicated LXC on dedicated hardware.
The home lab finally feels like one machine. One Proxmox box can host ai-box (agents), code-server (editor), ollama (local model), and Tailscale — and you reach any of them from any device.
You see diffs visually. When the agent rewrites 12 files in ai-box, you see the diff before accepting.
Backups and PBS protect the editor configuration the same way they protect the agents.

Cons — what it costs you

Path B is another always-on service. code-server in its own LXC consumes RAM, CPU, and a snapshot/backup slot. Worth it for the right use case; overkill if you only need Path A.
Bind mounts between LXCs are fiddly. Sharing the same project folder between ai-box and code-server requires either a bind mount, an NFS share, or a shared dataset — none are zero-effort.
Extension supply-chain risk. A malicious VS Code extension can read every file in your workspace. The LXC isolation helps; it doesn't replace being picky about extensions.
Path A still needs SSH open on ai-box. One more port to think about; mitigated by Tailscale-only access.
Telemetry, by default. Microsoft VS Code reports usage data; each AI extension reports its own. VSCodium and a tightened telemetry.telemetryLevel are the answer if that matters.
It's not designed AI-first. Cursor and Windsurf are VS Code forks that are. Both work over Remote-SSH into an LXC and may be the better front-end if you want editor-first AI.

When to pick which

Stay terminal-only (over SSH or pct exec) if: you're comfortable in vim/nano and the agents do most of the heavy lifting. Lightest path; matches the hypervisor's "do less" ethos.
Use VS Code on your laptop + Remote-SSH into ai-box if: you want visual diffs and real refactor tooling without adding a service to the home lab. The recommended path for most home labs.
Use a dedicated code-server LXC if: your client is a Chromebook, iPad, or locked-down work machine, or multiple people need the same shared editor — and you want hard isolation from the agents' LXC.
Use Cursor or Windsurf on the laptop if: you want the editor experience and care most about how the AI feels. Both work over Remote-SSH into the LXC.
Don't: install a desktop on the Proxmox host. Don't run code-server inside ai-box. Don't skip snapshots before turning agents loose.

🪟The honest take: the home-lab editor question has a beautifully boring answer on Proxmox — put the editor where editors belong (a container), put the agents where agents belong (a container), put the model where models belong (a container), and let the hypervisor be a hypervisor. Snapshots make this safer than any other platform on the site; the only mistake is installing anything fancy on the host itself.

Part 2

What we left out — and why

The guide is deliberately a clean six-step spine. That clarity has a cost: real omissions — and on a hypervisor, several of them are about safety. Here they are, honestly, with the reason each was cut.

Left out	What it is	Why it was cut
Hermes Agent	Nous Research's self-improving, model-agnostic coding agent	Genuinely an oversight in v1 — it's newer and niche. Now added as the bonus 4th agent, installed inside the container. A good reminder that "the big three" isn't the whole field.
Unprivileged containers	An LXC where root inside isn't root on the host	The real security omission. We should have stressed that the AI box belongs in an unprivileged container by default — it's the single biggest "free" hardening on this page. See Part 5.
Proxmox backups	vzdump snapshots and Proxmox Backup Server (PBS)	Cut to keep the spine to "make it work." But a container running autonomous agents is exactly what you want backed up — set a scheduled vzdump, or stand up PBS, before you lean on it.
Snapshots before agents run	An instant point-in-time copy you can roll back to	Skipped for length, but it's the home-lab superpower: take a snapshot, let an autonomous agent loose, roll back in seconds if it makes a mess. Covered in Part 5.
Resource limits	RAM, CPU, and disk caps on the container	We set starter values and moved on. A runaway agent can pin the host; explicit limits keep one container from starving everything else on the box.
A non-root user inside	A normal login instead of running everything as root	The guide does everything as root for simplicity. Real setups add an unprivileged user inside the container so the agents don't run with full root rights.
Its own VLAN	Putting the AI box on an isolated network segment	One layer past a first setup, but the right answer for an autonomous box: a VLAN means a misbehaving agent can't reach your other machines. See Part 5.
The host firewall	Proxmox's built-in firewall, at datacenter / node / container level	Off by default and not covered. It's how you make sure only Tailscale — never the open internet — reaches the web UI and the container.

🧭The pattern: we cut anything that wasn't needed to get a working AI box. The price, on a hypervisor especially, is that "production-ready" needs unprivileged containers, backups, snapshots, resource limits, and network isolation on top. This analysis page is where that depth lives.

Part 3 · what the AI crowd is actually using

Trending & cool — tools worth a look

Scanning the developer conversation on X and GitHub in May 2026, here's what's hot that the guide doesn't yet mention. All run happily inside your Linux container.

OpenCode

The open-source CLI agent everyone's talking about — 150K+ stars, ~6.5M monthly devs. LSP integration, multiple parallel sessions, shareable session links. The strongest "free, bring-your-own-model" alternative to Claude Code.

Warp 2.0

A terminal that's also an agent cockpit — runs Claude Code, Codex, and others in one windowed UI with panes. Nice if the bare terminal feels stark.

Goose · OpenHands

Goose (from Block) and OpenHands are open-source autonomous agents that take a goal and run a long multi-step job. The frontier of "set it and walk away."

GitHub Spec Kit

93K+ stars. A "spec-driven development" workflow that teaches any agent (Claude Code, Copilot, Gemini, etc.) to plan before it codes. Tessl and Kiro play in the same space.

MCP servers

The plug-ins that matter: chrome-devtools-mcp (let an agent drive Chrome), filesystem, GitHub, database connectors. This is the fastest-moving, highest-leverage area right now.

Qwen 3.6-Plus (local)

An agentic open model with a 1M-token context and MCP-native tool use — a serious local option for Ollama if your hardware can handle it.

⚖️Why these aren't in the main guide: they're powerful but move fast, need more setup, or assume comfort with the basics. The guide's job is to get you to "it works." This list is your "now go further." Honorable mentions from the same conversation: Amazon Q Developer CLI, Sourcegraph Amp, Qwen Code, Crush, Plandex, Kimi CLI, Aider, Cline.

Part 4 · the next wave

Getting ready for Mythos

Mythos is Anthropic's first model specialized for one domain: defensive cybersecurity. Announced April 7 2026 as the engine of Project Glasswing, it has already found a 27-year-old vulnerability in OpenBSD and bugs in FFmpeg. It is invitation-only ($25 / $125 per million tokens), shipped to 12 founding orgs and 40+ critical-infrastructure partners — not a download. Full briefing →

So "getting ready" isn't an install — it's preparing your environment so that when domain-specialized models (Mythos and the wave behind it) open up, you can point them at something useful:

Proxmox is uniquely well-positioned for this. A dedicated, isolated VM is the ideal place to run a security-research model safely — sandboxed from the rest of your network, snapshot-able before each run, and disposable if a job goes sideways. A hypervisor is exactly the right tool for Mythos-class work: give it its own VM, its own VLAN, and you can let it probe hard without risking your other machines.
Get on MCP now. Specialized models reach your code and infrastructure through MCP. A working MCP setup today is the plug Mythos-class tools will use tomorrow.
Have your code in Git, reachable over Tailscale. A security model is only useful pointed at your systems. Repos in Git + machines on your tailnet = ready to analyze.
Tighten your own security first (Part 5). The irony: you can't safely run a vulnerability-finding model on a sloppy host. Hardening is the prerequisite, not the reward.
Keep a clean Anthropic account & current Claude Code. Access to new models lands through the same account and tooling you already use.
Watch Glasswing. If you run anything critical (a business, rentals, client sites), the initiative is where defensive tooling will surface first.

🔭Honest take: as an individual you won't get Mythos itself soon. What you can do is build the habits — MCP, Git, a private network, a hardened, isolated VM — that make any future specialized model immediately useful. On Proxmox that "isolated VM" is a one-click reality (see the tool map).

Part 5 · don't skip this

Securing the install — the part most guides skip

You're running a hypervisor with a web admin panel, plus a container full of tools that can read files, run commands, and reach the internet, a private network, and a local model server. That's a lot of power on one box. Here's how to keep it from biting you — Proxmox and home-lab specifics first, then universal rules.

⚠Real incident (Feb 2026): Check Point Research disclosed that a malicious config could redirect Claude Code's traffic via the ANTHROPIC_BASE_URL setting and exfiltrate your API key in plaintext. Anthropic patched it before disclosure — the lesson stands: keep Claude Code updated, install only from official sources, and be suspicious of any config that reroutes where a tool "phones home."

Proxmox & home-lab specifics

Use an UNPRIVILEGED LXC. Root inside an unprivileged container isn't root on the host — the single biggest free hardening here. Or go further and run the AI box in a full VM for stronger isolation. Either way, don't run autonomous agents in a privileged container.
Do NOT expose the Proxmox web UI to the internet. Port 8006 should never face the open internet — reach it over Tailscale only. Use the host firewall to enforce that.
Enable 2FA on the Proxmox login. The web UI is the keys to the whole castle; turn on TOTP/two-factor for your Proxmox account.
Take a SNAPSHOT before letting an autonomous agent run. Proxmox snapshots are instant and let you roll the container or VM back in seconds if an agent makes a mess — the home-lab superpower the cloud doesn't give you for free.
Isolate the AI box on its own network / VLAN. Put the container or VM on a segment of its own so a misbehaving agent can't reach your other machines, NAS, or cameras. Pair with Tailscale ACLs.
The TUN grant is a trade-off. Handing the container the host's /dev/net/tun widens what it can do and weakens isolation. If you don't strictly need Tailscale inside the container, run it on the host instead.
Keep Proxmox + the containers patched. apt update && apt upgrade on the host and inside each container — the hypervisor is a second attack surface and gets CVEs of its own.

Protect your keys & logins

Never paste API keys into files you might share or commit. Anthropic + GitHub run secret-scanning that auto-deactivates leaked Claude keys — helpful, but don't rely on it. Use the browser login flow (no key on disk) where you can.
Store any keys in environment variables or a secrets manager, never in plaintext in a repo.
Rotate a key the moment you suspect it leaked; give helpers their own keys, never yours.

Keep the agents on a leash

Block agent access to secrets. Configure Claude Code's permissions to deny reading .env files, SSH keys, .secrets, and certificates — and to not read its own config (which could be used to manipulate it).
Start agents in ask-before-acting mode on a new container; only loosen once you trust the workflow. Don't run "auto/yolo" modes against irreplaceable data — and remember the snapshot trick above.
Work inside a project folder, not the whole container — limit what the agent can even see.

Supply chain (the install commands themselves)

npm install -g and curl … | sh run other people's code. Only use the exact official sources in the guide; don't paste install one-liners from random blog posts or X replies — and be doubly careful with the community helper-scripts, which run as root on the host.
Keep everything updated (apt upgrade, npm update -g); most agent fixes ship fast.

Lock down Ollama & Tailscale

Ollama: setting OLLAMA_HOST=0.0.0.0:11434 exposes your model server to the network. Only do this behind Tailscale — never on a public IP or open Wi-Fi. There's no password on Ollama by default.
Tailscale ACLs: in the admin console, restrict who can reach port 11434 and who can SSH where. Turn on key expiry so a lost device drops off. Tailscale's new Aperture (alpha) can even keep API keys off your devices entirely, behind your tailnet identity.

✓ Good shape when: the container is unprivileged (or it's a dedicated VM), the Proxmox UI is Tailscale-only with 2FA on, you snapshot before autonomous runs, the AI box is on its own VLAN, no keys live in plaintext, agents can't read your secrets, Ollama is Tailscale-only, and everything auto-updates. That's a setup you can hand a vulnerability-finding model without flinching.

The Proxmox setup, under the microscope.