Arcane: a self-hosted Docker management panel in Go, and what its env file reveals

What Arcane is for, and who ends up using it

Arcane is described in its own README as "Modern Docker Management, Designed for Everyone." The repository is a monorepo: backend/ holds Go code, cli/ holds a command line client, frontend/ holds a web interface, and types/ and email-templates/ sit alongside them. A single Go module path appears in the README badge, github.com/getarcaneapp/arcane/backend/v2, which tells you the backend is versioned as a v2 Go module.

The audience implied by this layout is someone running Docker on a host they control and wanting a management surface on top of it. That is a different job from running containers locally on a laptop. The presence of TRUSTED_PROXIES, TLS_ENABLED, PUID and PGID in .env.example points at a deployment behind a reverse proxy on a Linux server, where file ownership inside the container matters. If you only ever run docker compose on a desktop, most of those settings are noise.

The configuration surface visible in .env.example

The most concrete artifact in the repository is .env.example, and it doubles as a map of how Arcane is assembled. Application settings come first: GIN_MODE, ENVIRONMENT, PORT (3552), and APP_URL. Gin is a Go HTTP framework, so the backend is a Go HTTP service listening on 3552 by default.

Security is handled with two secrets the file insists you generate: ENCRYPTION_KEY and JWT_SECRET. The header comment suggests openssl rand -base64 32 for generating secure values. There is also an optional ADMIN_STATIC_API_KEY, described as bootstrapping "a deterministic admin API key for IaC workflows", which supports _FILE and __FILE variants. That is a deliberate affordance for infrastructure-as-code: instead of creating an admin key through the UI and copying it, you can seed one from the environment.

The database is SQLite by default. DATABASE_URL in the example is a file: URL pointing at data/arcane.db with WAL journal mode and a busy timeout pragma. TLS can be terminated by Arcane itself (TLS_ENABLED, TLS_CERT_FILE, TLS_KEY_FILE), but the comment says to leave it disabled behind a reverse proxy. TRUSTED_PROXIES takes a comma-separated CIDR list and auto-defaults to loopback when LISTEN is bound to 127.0.0.1 or ::1.

One detail worth flagging: the example sets FILE_PERM to 0644 and DIR_PERM to 0755 as defaults. Those are conventional, but if you run Arcane as a non-root PUID/PGID pair, the interaction between those modes and the mounted volume is something you have to reason about yourself. The file does not explain it.

Installing Arcane and getting to a first container

The README does not contain installation steps. It says: "For setup instructions, configuration details, and development guides, visit the official documentation site" at getarcane.app. So the honest answer to "how do I install this" is that the repository points you elsewhere, and the repository documents an environment file rather than a run command.

What the repository does give you is the shape of the configuration. The recommended starting move, per the file itself, is to copy the example and edit it:

cp .env.example .env
openssl rand -base64 32

The second command is the one the file's header comment recommends for generating secure values. You need two of them, one for ENCRYPTION_KEY and one for JWT_SECRET.

A minimal .env for a first run, using only keys that appear in .env.example, looks like this:

ENVIRONMENT=production
PORT=3552
APP_URL=https://your-domain.com
ENCRYPTION_KEY=<output of openssl rand -base64 32>
JWT_SECRET=<a second, different value>
DATABASE_URL=file:data/arcane.db?_pragma=journal_mode(WAL)

What you should see after starting it is an HTTP service on port 3552, with a SQLite database created under data/. The README does not state the container image name, so take that from getarcane.app rather than guessing. The repository does include a docker/ directory and a .goreleaser.yaml, which indicates published images and release binaries exist, but the exact tags are not in the README.

For automation, the ADMIN_STATIC_API_KEY line is the one to reach for:

ADMIN_STATIC_API_KEY=arc_your_deterministic_admin_api_key

The example shows the arc_ prefix. The comment notes _FILE and __FILE variants, which is the usual pattern for reading a secret from a mounted file instead of inlining it.

Building from source pins you to Node 26 and pnpm 12

If you want to build the frontend rather than consume a release artifact, package.json sets hard constraints. The engines field requires node >=26, and packageManager is pinned to [email protected] with an integrity hash. A preinstall script runs npx only-allow pnpm, so npm install and yarn install are rejected outright.

The workspace list is frontend, tests and email-templates. That is a small surface, but it means the test suite is a workspace rather than a directory of loose scripts. The root devDependencies reference vite and vite-plus through a catalog, which points at pnpm-workspace.yaml managing shared versions.

Node 26 is a recent major, so this is not a project you build on an older CI runner without upgrading it first. That is a real adoption cost, and it is stated plainly in package.json rather than buried in documentation. The Go side is more forgiving: go.work and go.work.sum indicate a Go workspace, so the backend and CLI are developed together.

Where the README leaves you on your own

The README is roughly a page of badges, a documentation link, a sponsor, an SBOM link and a Crowdin link. It does not document installation, upgrade, rollback, backup, or what happens to data/arcane.db across versions. The CHANGELOG.md exists at the repository root, so release notes are tracked there, but the README does not point at them for upgrade guidance.

This is the main practical limitation. Configuration keys are visible in .env.example, but their semantics are not fully explained. What happens if you change ENCRYPTION_KEY after data has been written with the old one? The example file does not say. What is the migration path for the SQLite schema between v2.8.0 and v2.9.0? Not stated in the README. The release cadence, three releases in August 2026 with the last push on 2026-08-25, suggests active work, but frequent releases also mean you should test upgrades on a copy of data/arcane.db before touching production.

A second limitation is scope. Arcane is a Docker management front end. If your problem is Kubernetes orchestration, image building at scale, or multi-host cluster scheduling, this is not the category of tool you want. The environment file's vocabulary (single PORT, single DATABASE_URL, PUID/PGID) describes one process against one Docker host.

Portainer is the comparison that matters

Portainer is the obvious alternative, and the difference is architectural rather than cosmetic. Portainer is distributed primarily as a container you run, with its own documented install command and a long-standing upgrade path. Arcane ships as a Go backend, a separate CLI, and a frontend workspace, with the setup instructions living on getarcane.app rather than in the repository.

The second difference is the configuration model. Arcane exposes a flat environment file with named keys like TRUSTED_PROXIES, PUID, PGID, FILE_PERM and DIR_PERM, plus a deterministic admin API key for IaC. That is a configuration-as-environment approach, which suits GitOps workflows where the whole deployment is a checked-in .env and a compose file. Portainer's model leans more on its own UI and its own API for setup.

The third difference is the stack. Arcane's backend is Go with Gin; its frontend workspace demands Node 26 and pnpm 12. If your team is Go-oriented and wants a backend they can read and extend, that is a point in Arcane's favour. If you want a tool you never build, it is a point against.

Licence, upgrades and the cost of staying current

Arcane is BSD-3-Clause, which is a permissive licence: you can use it commercially, modify it, and redistribute it, provided the copyright notice and licence text are retained. The README links to LICENSE at the repository root. Nothing in the repository suggests a copyleft obligation or a source-availability requirement. This is not legal advice; if you are embedding Arcane in a product, have your own counsel read LICENSE.

The upgrade cost is harder to estimate from the repository alone. Three releases landed in August 2026, so the project moves quickly. The CLI living in its own directory means the CLI and backend can drift if you pin one and not the other. The SBOM link at getarcane.app/sbom is the place to check what is actually inside a given image before you promote it.

One practical note: because the database defaults to SQLite in a file, backups are a file copy plus a WAL checkpoint. The example URL enables journal_mode(WAL), so copying arcane.db alone while the service is running can miss recent writes. Stop the service or checkpoint first. The repository does not document a backup procedure, so that reasoning is yours to apply.

Editorial conclusion

Arcane suits operators who already run Docker on their own hardware and want a web panel plus a CLI they can configure through environment variables, and who are willing to read getarcane.app because the README does not carry setup steps. It is the wrong tool for anyone who wants a fully documented, zero-configuration install, for Windows-native Docker users, or for teams that cannot run a Node 26 build toolchain if they intend to build the frontend from source. Before adopting it, verify three things: the exact image name and tag published for v2.9.0, whether the ADMIN_STATIC_API_KEY bootstrap is present in that release, and how DATABASE_URL and ENCRYPTION_KEY must be generated for a fresh deployment.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes