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:

• Komodo — multi-server, GitOps deployments, unlimited agents, free forever, no Kubernetes support
• Portainer — single-node free, Kubernetes support, Business Edition required for most team features
• Dockge — single-host, dead simple, Docker Compose only, no fleet management

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:

• CPU: 2 cores
• RAM: 1 GB (2 GB if you plan to run MongoDB instead of SQLite)
• Disk: 20 GB
• Network: Static IP (you'll be hitting this address from other nodes)

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:

• CWWK N100 Mini PC (8GB RAM, 256GB NVMe) — perfect for a dedicated management node at around $120
• Kingston 32GB DDR4 SO-DIMM — if you're expanding RAM on an existing node for the extra headroom

Networking (for clean inter-node traffic):

• TP-Link TL-SG108E 8-Port Managed Switch — VLANs between your Proxmox nodes and the Komodo LXC
• Cat8 Ethernet Cable 10-Pack — worth running proper cabling once if your rack is within reach

Storage for the host:

• Samsung 870 EVO 500GB SATA SSD — solid choice for a boot drive if you're not on NVMe yet
• WD Blue SN580 1TB NVMe — step up if your board supports M.2; makes a visible difference under load

For a more capable Periphery node:

• Beelink SER7 Mini PC (Ryzen 7, 32GB RAM) — handles heavier stacks (Immich ML, Jellyfin transcoding) as a managed Periphery host
• Crucial 64GB DDR5 SO-DIMM Kit — if you're maxing out RAM and running multiple workloads on one box

UPS (don't skip this):

• APC Back-UPS 600VA — clean shutdown matters more when your infrastructure is managed through a single node
• CyberPower CP1500PFCLCD 1500VA Pure Sine — if you're protecting multiple nodes and NAS

Komodo vs Portainer: The Honest Verdict

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

Use Komodo if:

• You manage more than one Docker host
• You want GitOps-style deployments without paying for it
• You don't need Kubernetes
• You want a tool that won't surprise you with a paywall

Stick with Portainer if:

• You're already on Business Edition and integrated with your team's workflow
• You need Kubernetes support alongside Docker
• You prefer the more polished UI and don't mind the cost

Use Dockge if:

• It's genuinely just one machine and a handful of Compose stacks
• You value zero operational overhead above everything else

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.