Arcane Docker Management: The Lightweight Portainer Alternative I’d Try First

I like Portainer, but I do not love what it becomes after a homelab grows past “three containers and a dream.”

The UI is capable. Maybe too capable. You open it to restart one container, and suddenly you are staring at RBAC menus, environments, edge agents, stacks, registries, and a tiny voice in your head asking whether you accidentally joined an enterprise procurement meeting.

That is why Arcane caught my attention. It is a modern Docker management UI built for people who want to run containers, manage Compose stacks, and keep the workflow simple enough that Sunday maintenance does not become a second job.

This is a quick Friday guide, so I am not going to pretend Arcane is magic. It is a young tool. It has had security issues, including a GitOps secrets leak that was fixed in newer releases. Treat it like any tool with Docker socket access: useful, sharp, and not something you casually expose to the internet.

Why Arcane is interesting

Arcane sits in the same mental bucket as Portainer, Dockge, and Komodo: a web UI for Docker and Docker Compose.

The difference is the vibe. Portainer feels like a full platform. Dockge feels wonderfully simple but narrow. Arcane aims for the middle: friendly container management, Compose stack handling, Git-based deployments, and enough structure for a real homelab.

That middle ground matters.

Most self-hosters do not need Kubernetes. Most also outgrow SSH-ing into a box and editing random docker-compose.yml files in /opt with no history. I have done that. It works right up until you forget which folder contains the “real” version and which one was a 2 a.m. experiment.

Arcane is for the person who wants a dashboard, but still wants their stack to feel like code.

My opinionated rule for Docker UIs

A Docker UI should make boring work faster.

That is it.

If it encourages you to click random buttons in production, it is a liability. If it hides too much state, it is also a liability. The best Docker UI is the one that helps you inspect, restart, deploy, and troubleshoot without becoming the source of truth for your whole server.

So I would use Arcane like this:

• Git is the source of truth for Compose files.
• Arcane is the convenient control panel.
• Backups still happen outside Arcane.
• Secrets do not live in random UI fields unless I understand exactly how they are stored.
• Public exposure is behind a VPN, mTLS, SSO, or not happening at all.

That sounds paranoid. It is not. Anything that can talk to Docker can usually do terrifying things if compromised.

Before you install it

Start with a tiny checklist.

You want a Linux host with Docker and Docker Compose already installed. You also want a reverse proxy if you plan to use a real domain, though I would strongly suggest keeping Arcane private at first.

For a VPS, I would put it behind WireGuard, Tailscale, Caddy mTLS, or at minimum a very boring firewall rule that only allows your IP. Exposing Docker management panels directly is how homelab people learn humility.

Also: update Arcane aggressively. Young admin tools move fast, and the boring patch release is often the one that saves your weekend.

A simple Docker Compose setup

Create a folder for Arcane:

mkdir -p /opt/arcane
cd /opt/arcane

Then create a Compose file:

services:
  arcane:
    image: ghcr.io/getarcaneapp/arcane:latest
    container_name: arcane
    restart: unless-stopped
    ports:
      - "3552:3552"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - arcane-data:/app/data

volumes:
  arcane-data:

Start it:

docker compose up -d

Then open:

http://your-server-ip:3552

Do not leave it like that on a public VPS. That port should either be firewalled or only reachable through your private access layer.

The Docker socket problem

Mounting /var/run/docker.sock is convenient. It is also the part you should respect.

The Docker socket is basically root access with extra steps. If a web app can control Docker, it can start privileged containers, mount host paths, read files, and generally ruin your day if someone gets in.

For a safer setup, use a Docker socket proxy. The idea is simple: Arcane talks to the proxy, and the proxy only exposes the Docker API endpoints it needs.

A rough pattern looks like this:

services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy:latest
    container_name: socket-proxy
    restart: unless-stopped
    environment:
      CONTAINERS: 1
      IMAGES: 1
      NETWORKS: 1
      VOLUMES: 1
      POST: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

  arcane:
    image: ghcr.io/getarcaneapp/arcane:latest
    container_name: arcane
    restart: unless-stopped
    ports:
      - "3552:3552"
    environment:
      DOCKER_HOST: tcp://socket-proxy:2375
    volumes:
      - arcane-data:/app/data
    depends_on:
      - socket-proxy

volumes:
  arcane-data:

Check Arcane’s current documentation before copying this blindly. Docker APIs and app expectations change. The point is the pattern: avoid handing a web app the raw socket when a narrower path works.

Where Arcane fits against Portainer and Dockge

Here is the short version.

I would still recommend Portainer for someone managing multiple environments or wanting the most battle-tested option.

I would recommend Dockge for someone who only wants a clean way to manage Compose stacks and does not care about broader container management.

Arcane is the one I would test if I were rebuilding a personal VPS today and wanted a lighter, cleaner dashboard with a Git-friendly workflow.

The GitOps part is the real hook

Clicking “deploy” from a UI is fine. Having your Compose files in Git is better.

Git gives you history. It gives you rollback. It gives you a place to review changes before your server changes. When something breaks, git diff is much nicer than “I think I changed an environment variable last Tuesday.”

Arcane’s GitOps direction is the feature that makes it more interesting than yet another container list with start and stop buttons.

My preferred workflow would be:

1. Keep each app in a Git repo or a clean folder structure.
2. Pin image versions where breakage would hurt.
3. Use Renovate to open update pull requests.
4. Let Arcane deploy from the reviewed Compose state.
5. Keep backups and monitoring outside the dashboard.

That is boring infrastructure. Boring is good. Boring means you can go outside.

Lock it down before you get comfortable

Once Arcane is running, do these before adding every app you own.

First, put it behind private access. WireGuard, Tailscale, Caddy client certificates, or a trusted VPN are all better than a naked admin panel.

Second, use strong authentication. If Arcane supports OIDC in your current version, wire it into your identity provider. If not, use the strongest built-in auth available and keep the app off the public internet.

Third, patch quickly. I am repeating this because admin panels are not recipe managers. A vulnerability in a recipe app is annoying. A vulnerability in a Docker control panel is a house key.

Fourth, keep a backup of Arcane’s data volume and your Compose repositories. The UI should be disposable. Your infrastructure state should not be.

What I would not run through Arcane

I would not manage databases casually through any Docker UI unless the backup story is already boring and tested.

Postgres, MariaDB, Redis, and friends deserve a little ceremony. Pin versions. Read release notes. Test restores. If Arcane helps deploy them, great. If it makes you feel safe clicking update without thinking, bad.

I would also avoid storing sensitive Git credentials in a tool like this unless I know how they are encrypted, who can read them, and how revocation works.

This is not a knock on Arcane. It is the same advice I would give for Portainer, CI runners, deployment bots, and anything else that can mutate infrastructure.

A practical first project

Do not migrate your whole stack on day one.

Pick one boring service. Something like Uptime Kuma, Homepage, or a small internal tool. Put its Compose file in Git, deploy it with Arcane, restart it from the UI, change an environment variable, redeploy, and confirm the workflow feels clean.

Then test failure.

Break the Compose file on purpose in a branch. Roll back. Restore the data volume. Make sure you understand what Arcane owns and what Docker owns.

That one hour of deliberate messing around teaches more than a polished dashboard screenshot ever will.

Verdict

Arcane is worth watching, and for some homelabs it is worth trying now.

I would not call it a universal Portainer killer. That is lazy blog drama. Portainer is mature for a reason, and Dockge still nails the simple Compose editor use case.

But Arcane hits a nice nerve: self-hosters want modern tools that respect Docker Compose, Git, and small-server reality. Not everyone wants to graduate to Kubernetes just to restart a container without SSH.

My CTA is simple: spin up Arcane with one non-critical app, keep it private, and see if the workflow makes your server feel calmer. If it does, move slowly. If it does not, delete the volume and go back to your terminal.

Control panels should earn their place. Arcane just might.