The questions that actually get asked

Neither. State lives in an embedded SQLite file (pure Go, no CGO) inside the data directory, and remote hosts are reached over the Docker Engine API via TCP+TLS or SSH — there is nothing to install on them. Redis is optional, and only to keep metric history across restarts; without it history sits in an in-memory ring.

Treat it as you would any panel that can control your host. It binds to 127.0.0.1:8470 by default; TOTP 2FA or a passkey is enforced unless an admin turns on the localhost exemption. That exemption ignores any loopback request carrying a proxy’s forwarding header, but a local reverse proxy that adds none cannot be told apart from a direct connection — so behind a proxy, list it in DC_TRUSTED_PROXIES or keep the exemption off. There are named roles that can be scoped to specific hosts, read-only accounts, rate limiting, an audit log, and your own live sessions are visible and revocable from your profile. If you publish it, use the built-in Let’s Encrypt HTTPS or terminate TLS at a reverse proxy.

Host-root-equivalent access. Anyone who reaches the UI — or escapes the app — controls the daemon, and therefore the machine. That is true of every Docker management tool, so the honest advice is: keep it on localhost or behind HTTPS with strong auth, and never expose it unauthenticated.

No. It is an independent open-source project with no affiliation, sponsorship or endorsement from Docker, Inc. It talks to the Docker Engine API like any other client. "Docker" is a trademark of Docker, Inc.

'Roughly 95% — code, tests and docs — using Claude Code, under human direction and review. Every release goes through CI on top of roughly 1,200 Go unit tests, 420 frontend tests and 150 adversarial "pentest" cases that assert attacks are rejected (token forgery, CSRF, IDOR, path traversal, per-host scope bypass), plus integration and multi-daemon tests against real Docker hosts, and every change is scanned by GitHub CodeQL before it ships. The tree is also periodically swept by an independent adversarial review on Claude Fable 5 — not an independent third-party audit or penetration test.

For managed Projects, yes. Every successful deploy is recorded as a revision — the compose and sidecar files, profiles, target host and the image digest actually running per service. History shows them, Diff compares any two (or one against what runs now), and Restore validates the old revision in a staging copy before swapping it in atomically; if anything fails, what was there before is put back. A restore is itself a new revision, so history only grows. Named volumes are never touched — data is not rolled back.

No telemetry, no analytics. The only automatic outbound request is the update check against GitHub Releases, which is what puts the "update available" banner in front of an admin; and otherwise only talks to whatever you configure yourself — your Docker hosts, your SMTP server, your webhooks, your registries.

No. It reads and writes through the Docker API like the CLI does, so containers and stacks you created elsewhere show up and stay manageable — compose stacks are discovered by label whether they came from this UI or from docker compose in a terminal. Stop using it and nothing needs unwinding.

Everything is in one data directory: the SQLite database plus the signing and at-rest encryption keys, generated on first run. It defaults to the OS config dir and moves with -data-dir / DC_DATA_DIR; under Docker it is the /data volume. dockercmd --backup <file> writes a complete, portable snapshot — the database plus your projects, templates and deploy revisions — through a read-only connection, so it is safe to run while the server is up; --restore <file> puts it back, and --passphrase encrypts the archive. To move to another server instead, export a recovery bundle from Settings and import it there. The data inside your volumes is a separate matter: backup jobs run your own restic, borg or script against them. Treat a backup as secret: it holds the key that decrypts your registry, SMTP and LDAP credentials, and losing an unencrypted copy makes them recoverable by whoever has it.

An admin sees an "update available" banner and can apply it in place — one tap to update and restart — or opt in to applying patch (or patch and minor) releases automatically. From a shell it is dockercmd --self-upgrade, which verifies the SHA-256 and swaps the binary atomically. Running the container image, pull the new tag instead; installed from a .deb or .rpm, use your package manager. The data directory is untouched either way, so an upgrade is not a migration.

Release binaries cover linux/amd64, linux/arm64, darwin/amd64, darwin/arm64, windows/amd64 and windows/arm64, plus .deb and .rpm packages and a multi-arch container image. The binary installs itself as a native service: a systemd unit on Linux, a launchd agent on macOS, a Service Control Manager service on Windows.

Engine API 1.43 or newer — that is Docker Engine 24 and up — and the docker compose CLI plugin v2 or newer (the legacy docker-compose v1 is not supported). The client SDK negotiates down to whatever your daemon speaks, so a newer build talks to an older engine without any configuration. This is not a guess: a nightly workflow runs the full Docker integration suite against Engine 24 through 29 and reports the result, so the floor is measured rather than remembered.

MIT. Use it commercially, fork it, ship it inside something else — no feature is held back for a paid tier, because there is no paid tier.