Arcane Docker Review: Is It Ready to Replace Portainer?

Arcane shipped full role-based access control on June 7, 2026, in the v2.0.0 release. It also scans your images for known vulnerabilities on a schedule you set. Neither was true when Brandon Lee published his first-impressions piece on Arcane on December 29, 2025, just over five months ahead of the RBAC release.

That gap is the awkward part of any Arcane Docker review right now. The tool is already at v2.10.2, released September 5, 2026, less than two weeks after v2.9.0. The v2.10.0 release fixed the GitOps clone leak discussed below and added an experimental Convert to Compose workflow for running containers. A feature list written even a few days earlier describes a different product.

TL;DR

Arcane at v2.10.2 is a workable Portainer replacement for the right operator. It ships full RBAC, OIDC single sign-on, Trivy vulnerability scanning, and GitOps redeployment at no cost and no node ceiling. Portainer keeps that role hierarchy in Business Edition past three nodes. 4 out of 5. What holds it back is tenure, not capability.

• Switch once you are past Portainer's third node and need roles that scope who can touch what. You get six built-in roles, custom roles, per-environment assignment, and OIDC group-claim mapping, unpaid and unmetered.
• Vulnerability scanning is in the box. Arcane runs Trivy, an open-source image scanner, on a cron schedule and stores results per image.
• Portainer Business Edition is free up to three nodes, with no feature restrictions. Below that line you already have RBAC and SSO, so Arcane's free-access argument is much weaker.
• There is still no direct Portainer-stack import. v2.10.0 can experimentally convert running containers into Compose projects, which cuts some manual work, but you still need to review the generated YAML and plan a cutover because names and published ports can collide while the originals are running. Back up volumes first.
• Harden ENCRYPTION_KEY before production, and set APP_URL correctly. ENCRYPTION_KEY still has a development default, and passkey sign-in will not work until APP_URL points at the HTTPS hostname users actually browse to. JWT_SECRET is no longer used, per the current installation docs.
• The GitOps disk-exhaustion bug reported against v2.8.0 and v2.9.0 is fixed in v2.10.0. The fix purges leftover Git clone scratch directories instead of letting them accumulate on the manager host.
• LDAP is still absent. Identity integration is OIDC only.

How this assessment was made: this is an evidence review, not a hands-on test. No sponsorship, no payment, no product provided, no contact with the maintainer. Every capability claim is checked against Arcane's current documentation and release notes, and every reliability claim traces to a dated issue on the project's public tracker or to a named operator writing about their own deployment. Nobody here ran Arcane to write it, so where that limits the read (how the interface feels, how it holds up under sustained load) the piece says so instead of guessing.

What Does Arcane Give You for Free That Portainer Doesn't?

One thing, mainly: full role-based access control. Portainer CE gives you basic user management; the role hierarchy is Business Edition. Arcane ships it free at any node count, alongside Trivy scanning, GitOps redeployment, Swarm support, passkey sign-in, remote agents, and S3 backups added in v2.9.0.

The RBAC is the part worth looking at closely, because "has RBAC" covers a lot of very different things. Arcane's access-control documentation describes six immutable built-in roles: Admin, Editor, No-Shell Editor, Deployer, Monitor, and Viewer. You can clone any of them into a custom role and check off individual permissions, which follow a <resource>:<action> shape like containers:start. Assignments are global or per-environment, and a user can hold several at once. The docs give the example directly: Editor on prod, Viewer on staging.

The part that matters for an SSO rollout is that role assignment can be driven from the identity provider itself: "On every login Arcane reads the user's group claim and re-syncs their OIDC-sourced assignments," and a user in several mapped groups gets the union of them. That is the permission model Portainer CE never had.

Vulnerability scanning is the second piece. Arcane's scanning docs state that "scans are opt-in, run on a cron schedule, and results are stored per image," with the results shown in the UI. The default is daily at midnight, trivyIgnoreUnfixed narrows results to vulnerabilities with a known fix, and Trivy ships in a version-pinned tools image, so scanner updates are not yours to chase.

Now the counterweight, and it is a big one. Portainer's own CE-versus-BE page says Business Edition "is free forever for up to 3 nodes. No trial period. No credit card. No feature restrictions." That is the full BE set: RBAC with its own role hierarchy, OIDC, audit logs with Syslog export, advanced GitOps. The Take 3 terms issue a one-year license renewed annually at no cost for as long as you stay at three nodes or fewer.

So the free-tier math only starts working in Arcane's favor at node four. Below that, the paywall is not there. Arcane still offers something at one or two nodes: no license key, no renewal to remember, a project you can fork. But that is not the same argument as "RBAC costs money."

Arcane is one of four tools seriously competing for the Portainer seat, and the others split along different lines.

READ

Portainer Alternatives: A Use-Case Guide to Dockge, Arcane, Dockhand, and Komodo

How Reliable Is Arcane Right Now?

Better than it looked at v2.9.0, but still young. Arcane's historical bug record reads like an active project fixing things, and the severe GitOps disk-exhaustion bug reported against v2.8.0 and v2.9.0 was fixed in v2.10.0 on August 31, 2026.

An operator reported on August 26, 2026 that GitOps sync leaks a clone directory: "gitops-<N> clone dirs accumulate at roughly 1,000/day (~9 GB/day) and are never cleaned up, eventually filling the disk." Six days of that came to roughly 6,467 directories and 40 GB. Once the disk filled, the manager could no longer write to its SQLite database and went into a restart loop, hitting a restart count of 389 and taking edge-agent connections and API calls down with it. The issue is now closed, and v2.10.0 ships the cleanup fix for leftover Git clone scratch directories.

If you are still on v2.8.0 or v2.9.0: upgrade before relying on frequent GitOps sync. The clone-leak fix ships in v2.10.0.

The older record is more encouraging. A post-update hang between 2.0 and 2.0.1 was resolved. A bug where "Update Projects" hit every container on the host instead of the selected project's was closed against merged fix PR #2289. Image polling silently not firing in v1.13.2 was fixed in v1.14.0. Three bugs, three fixes.

The raw open-issue count says very little on its own on a project shipping this quickly. Projects nobody files against are not thereby more reliable.

My read is still that this is a tenure problem rather than a capability problem. Fast shipping is why the RBAC and scanning gaps closed at all, and it is also why v2.10.0 had to fix a severe GitOps defect less than a week after v2.9.0. New code is where the risk is, and adopting it is a choice.

What Does Switching From Portainer Actually Cost?

A downtime window and some manual cleanup, roughly. Arcane still has no direct Portainer-stack import, but v2.10.0 adds an experimental Convert to Compose action for running containers. It generates a Compose file while the originals keep running, which removes some of the YAML reconstruction work. You still need to review bind mounts, networks, environment values, and the cutover itself; names and published ports can collide until the originals are stopped, so this is not a zero-downtime migration button.

Before v2.10.0, the project's own board reflected a fully manual path. An operator with more than 80 containers across five servers asked whether a live migration was possible without taking web-facing services down first. The reply from someone who had already done it: "you will have no choice but to delete the existing containers (therefore the Portainer stacks) and recreate them from scratch in Arcane." Their sequence: shut down cleanly, back up, delete, copy the data across, recreate and redeploy.

Practically: volume backups before you touch anything, and a maintenance window sized by both how many stacks you run and how much data has to move. Container recreation is usually the quick part; copying large volumes and bringing dependent services back in the right order can stretch the window. One terminology note while you plan: what Portainer calls a stack, Arcane calls a project.

The time cost lands even at homelab scale. Moises Aguirre, writing on February 28, 2026 about moving a homelab off Portainer, called it "a solid weekend of work (and facing my demons)," and the demons were his own drift: he had to audit every container he was running and write YAML for services he had "previously just clicked into existence." That is his experience rather than a rule, but the shape of it travels.

One thing to catch before you carry Compose files across. The v2.7.0 release notes narrowed variable resolution to four sources: your global variables in .env.global, the project's own .env file, defaults written into the compose file itself, and timezone and locale from Arcane's environment. The stated effect is that a project deployed through Arcane resolves its variables the same way docker compose up does in the project directory. That is more correct behavior. It also means anything that was quietly inheriting a value from the manager's own container environment will now resolve to something else, or to nothing, and it will do it without complaining.

None of this is a defect in the product. It is a one-time cost, predictable enough to plan around, which is the main thing you want from a migration.

Build on a Linux VPS with root access, NVMe, and AMD EPYC power.

View Linux Plans

What Do You Have to Harden Before Production?

One encryption key, the public URL, and TLS. Arcane creates a default admin account on first run and forces a password change at first sign-in, which is a sensible default. Two settings need to be right before production. The first is ENCRYPTION_KEY; the second is APP_URL.

The environment-variable reference still lists ENCRYPTION_KEY with a default of arcane-dev-key-32-characters!!!, while the installation docs tell you to supply a unique 32-byte value. Change it before production. One more thing has changed: the installation docs now say JWT_SECRET is no longer used. Arcane generates the session-signing key itself; leaving JWT_SECRET configured only produces a startup warning, so remove it from the environment. The installation docs specify that ENCRYPTION_KEY "must be 32 bytes long (raw, base64, or hex)."

Version hygiene belongs in that checklist too. Arcane published several security advisories in 2026; one high-severity advisory, published July 29, 2026, lists releases before v2.5.0 as affected and let a delegated users:update permission reset an administrator's password. It names v2.6.0 as the patched release, so v2.10.0 is not affected, but it is a concrete reason not to park a production deployment on an old tag.

APP_URL defaults to http://localhost:3552, and this one has a functional consequence beyond hygiene. Passkey sign-in and passkey MFA both run on WebAuthn, and Arcane's passkey documentation is explicit: "Browsers only expose the WebAuthn API in a secure context, so passkeys need HTTPS (or localhost)." The relying-party ID is derived from APP_URL, passkeys are bound to that hostname, and if APP_URL carries no hostname the passkey service does not initialize. On plain HTTP, Arcane hides the passkey controls entirely. Deploy on a bare IP and port and the headline v2 authentication feature is not there. The docs put it plainly: "Set APP_URL to the URL your users actually browse to, over HTTPS, before anyone registers a passkey."

Remote agents decide what you open. Arcane's environments documentation says that in direct mode "the Manager connects to the Agent on TCP 3553," so that port has to be reachable inbound on the remote host. In edge mode "the Agent connects outbound to the Manager" and needs no inbound port at all.

Past that I would rather point than pretend. Arcane publishes a socket proxy setup guide whose premise is that a direct socket mount "gives Arcane full access to Docker," and a proxy narrows that to the API calls it needs. Same exposure that makes the Docker socket worth isolating anywhere, and worth doing here. I am reading these docs the way a deployer reads them, not auditing the token scheme.

What Does Arcane Still Not Do?

Two gaps still hold up against Arcane's current documentation: no LDAP and no general browser for a container's own filesystem. Several other gaps that held before v2 have since closed.

LDAP is absent. Arcane's single sign-on docs cover OIDC and only OIDC, and neither they nor the access-control page mention LDAP or Active Directory anywhere. Portainer's Business Edition, by contrast, integrates with "Active Directory, LDAP, and OIDC-compatible identity providers." If your organization authenticates against a directory with no OIDC layer in front of it, this is a hard stop, not a workaround.

No general file browser inside containers. Arcane's container view exposes configuration, mounts, logs, and Compose source, but not a browser for the container's own filesystem. It does now have a Volume Workspace that can browse and edit files inside Docker volumes, so the remaining gap is narrower than the old "no file browser" description.

The corrections are worth stating outright, because the "no RBAC, no vulnerability scanning" description of Arcane no longer holds. RBAC arrived with v2.0.0 on June 7, 2026, and Trivy scanning is documented and running on a schedule. Activity logging has moved too: Arcane's activity documentation describes an Activity Center covering pulls, builds, lifecycle actions, scans, and prunes, alongside an event log carrying severity, type, timestamp, and the user who triggered each action where Arcane can attribute it. Whether it exports to Syslog the way Portainer's Business tier does is not something the docs settle.

What release velocity does not fix is age. The Arcane repository was created in April 2025. Portainer has years of accumulated Stack Overflow answers, third-party guides, and integrations behind it, and when you hit something strange at 11pm that difference is what you feel.

Who Should Switch to Arcane, and Who Shouldn't?

Switch to Arcane if you are past three nodes on Portainer and want scoped multi-user access with git-tracked Compose, without a licensing conversation. Stay put if you are at three nodes or fewer. Counting hosts settles most of this faster than any feature list.

Three profiles where Arcane is a clear yes:

• Operators past Portainer's three-node ceiling who need scoped access. Above three nodes those capabilities carry a price at Portainer and none at Arcane, and the roles are granular enough to hand someone Deployer on one environment and Viewer everywhere else.
• Operators who want Compose files as the source of truth. If what is driving the move is that stack definitions live in a database instead of a repo, that is a structural fit, not a preference. The migration weekend is mostly spent writing down what you already run, which is work you owed anyway.
• Operators consolidating multiple hosts, including ones behind NAT. Edge-mode agents need no inbound port on the remote side, Swarm clusters are managed from the manager node, and remote environments cost nothing.

Two profiles where it isn't:

• Anyone on three nodes or fewer. Business Edition is free at that size with the full feature set, so switching spends a downtime window and a weekend to obtain capabilities you already have. As a Portainer alternative Arcane is capable; that is still not a reason to move.
• Anyone who needs LDAP, or who cannot take the stacks down. Directory authentication is not available and the migration still requires a planned cutover. Neither has a clever workaround.

One conditional rides along with that verdict. If GitOps redeployment is specifically why you are moving, use v2.10.0 or newer. The disk-exhaustion bug reported against v2.8.0 and v2.9.0 is fixed there.

READ

How to Get Docker on VPS: A Comprehensive Guide to Use VPS for Containerization🗂️

Frequently Asked Questions