Komodo on Proxmox LXC: The Best Free Portainer Alternative for Home Labs in 2026

If you've been running Portainer on Proxmox for a while, you've probably noticed the slow squeeze. Multi-environment management? Business Edition. RBAC? Business Edition. OAuth/SSO? Business Edition — starting at $231/year per node for the features that used to be free.

Komodo is what people are switching to in 2026, and once you've used it for a week you'll understand why. It's fully open source, has zero feature gating, supports unlimited servers, and ships Git-backed deployments out of the box. This guide walks you through running Komodo on a Proxmox LXC from scratch.

What Is Komodo and Why Is Everyone Switching?

Komodo is a Rust-based container management platform built around a core server, a lightweight per-host agent (called Periphery), and an optional database. The architecture is deliberately minimal — the Core handles the web UI and orchestration, Periphery runs on each managed server and executes commands locally, and the two communicate over a secure WebSocket connection.

The reason Komodo vs Portainer conversations keep appearing in 2026 is simple: Portainer moved RBAC, SSO, and multi-environment support behind a paid tier. For a home lab running three or four Proxmox nodes, suddenly you're looking at a subscription for features that should be table stakes. Komodo covers all of it, free, with the caveat that it doesn't support Kubernetes (that's still Portainer's lane if you need it).

Key differences at a glance:

If you're just running Compose stacks on one machine, Dockge is still the right answer. If you want to manage Compose deployments across multiple Proxmox nodes from one screen with Git-backed configs, Komodo wins on every dimension that matters for a home lab in 2026.

Architecture: How Komodo Runs on Proxmox

For a typical Proxmox homelab, the recommended setup is:

1. One dedicated LXC running Komodo Core + Periphery (managing itself) 2. Periphery agent installed on every other node/LXC you want to manage

Komodo Core requires a SQLite or MongoDB database. For a home lab, SQLite is sufficient and keeps the resource footprint low. The entire Core stack idles at around 150–200 MB RAM, which is well within LXC territory.

Step 1: Create the Proxmox LXC

Log into your Proxmox web UI and create a new LXC container. Use the Debian 12 template (preferred for compatibility with the install scripts).

Recommended specs:

Enable nesting if you want the Core LXC to manage Docker containers on itself as well:

# In Proxmox shell, after creating the LXC:
pct set <CTID> --features nesting=1

Then start the container and attach:

pct start <CTID>
pct enter <CTID>

Step 2: Install Docker Inside the LXC

Komodo Core runs in Docker, so you need Docker installed first:

apt update && apt install -y curl
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

Verify it's running:

docker version

Step 3: Deploy Komodo Core with Docker Compose

Create a directory and drop the official Compose file in:

mkdir -p /opt/komodo && cd /opt/komodo

Create compose.yaml:

services:
  komodo:
    image: ghcr.io/moghtech/komodo:latest
    restart: unless-stopped
    ports:
      - 9120:9120
    environment:
      KOMODO_HOST: http://<YOUR_LXC_IP>:9120
      KOMODO_PASSKEY: <GENERATE_A_RANDOM_PASSKEY>
      KOMODO_FIRST_SERVER: http://periphery:8120
    volumes:
      - /opt/komodo/data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - periphery
  periphery:
    image: ghcr.io/moghtech/komodo-periphery:latest
    restart: unless-stopped
    ports:
      - 8120:8120
    environment:
      PERIPHERY_PASSKEY: <SAME_PASSKEY_AS_ABOVE>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/komodo/repos:/repos

Replace with the static IP you assigned and generate a secure passkey (use openssl rand -hex 32).

Bring it up:

docker compose up -d

Komodo Core will be available at http://:9120 within 10–15 seconds.

Step 4: First Login and Server Registration

Navigate to http://:9120 in your browser. On first load, Komodo creates an admin account — set a secure password here.

The KOMODO_FIRST_SERVER variable you set in Compose automatically registers the local Periphery agent, so your first server (the LXC itself) is already connected. You'll see it listed as healthy in the Servers section.

Step 5: Add Additional Proxmox Nodes

This is where Komodo shines vs Portainer Free. Install Periphery on each additional host:

# On the target host (bare metal, VM, or another LXC)
curl -fsSL https://raw.githubusercontent.com/moghtech/komodo/main/scripts/install-periphery.sh | \
  PERIPHERY_PASSKEY=<SAME_PASSKEY> bash

The script installs Periphery as a systemd service listening on port 8120. Back in the Komodo UI, go to Servers → Add Server, enter the IP and port of the new host, and it registers immediately. No tiering, no license key, no limits.

Step 6: Deploy Stacks with GitOps

Komodo's killer feature for home labs is Git-backed stack deployment. Instead of managing Compose files through the UI directly, you point Komodo at a Git repo (GitHub, Gitea, Forgejo — anything with a webhook) and it pulls, deploys, and tracks changes automatically.

To set this up:

1. Create a Stack in the UI → select the server and Git repo URL 2. Add a webhook in your Git provider pointing to http://:9120/listener/github (or the equivalent for your provider) 3. Push a change to your compose.yaml in the repo — Komodo detects it, pulls the update, and re-deploys the stack

For a home lab running Immich, Jellyfin, Nextcloud, or n8n, this means your entire self-hosted stack is version-controlled and re-deployable in minutes after a node failure.

Hardware Worth Having for This Setup

If you're building out or upgrading the Proxmox node that'll run Komodo Core, here's what's worth the spend:

For the Komodo node:

Networking (for clean inter-node traffic):

Storage for the host:

For a more capable Periphery node:

UPS (don't skip this):

Komodo vs Portainer: The Honest Verdict

After running both, here's where each tool makes sense in 2026:

Use Komodo if:

Stick with Portainer if:

Use Dockge if:

For the typical home lab running three to five Proxmox nodes with a mix of services, Komodo hits a sweet spot that Portainer used to occupy before the licensing shift. The GitOps integration alone is worth the migration friction.

Troubleshooting Common Issues

Periphery can't reach Core: Check that port 8120 isn't blocked by the LXC firewall. Proxmox's built-in firewall is disabled per container by default, but if you've enabled it, add an inbound rule for 8120/tcp.

Docker socket permission errors: The Compose file mounts /var/run/docker.sock into both containers. If you get permission errors, verify the containers are running as root or the socket has group read access (ls -la /var/run/docker.sock).

Stacks showing as "Unknown" after Git push: Webhooks require Komodo Core to be reachable from your Git provider. If you're using a local Forgejo/Gitea instance on the same LAN, this just works. For GitHub webhooks, you'll need Komodo exposed via Tailscale, Cloudflare Tunnel, or a reverse proxy.

What's Next

Once Komodo is running, the natural next steps are:

1. Migrate existing Portainer stacks — export the Compose files, put them in a Git repo, import as Komodo Stacks 2. Set up a reverse proxy — Caddy or Traefik in front of Komodo Core gives you HTTPS without needing to open raw ports 3. Add monitoring — Komodo has basic resource graphs built in, but Beszel or Grafana + Prometheus gives you richer historical data

Komodo is the Portainer that Portainer used to be. If you're still paying for Business Edition or managing multiple nodes with the free tier's limitations, the migration is worth doing on a weekend.

---

Disclosure: This post contains affiliate links. If you purchase through these links, I may earn a small commission at no extra cost to you.