Questions people ask about NebulaCtrl

Yes. NebulaCtrl is free to run on your own servers, with no hosted version, no paid tier and no licence key. The source is coming soon, under the AGPL-3.0: if you modify it and let others use it over a network, you will offer them your source. The licence page has the details.

One Linux machine with systemd and root access: Debian 12 or 13, Ubuntu 22.04, 24.04 or 26.04 LTS, or RHEL, Rocky or AlmaLinux 9, on amd64 or arm64, with 1 GB of RAM for the control plane. The installer adds Docker 24 or newer if it is missing. Ports 80 and 443 should be free. A domain is optional: without one the dashboard is plain HTTP on port 8000 until you add one. Requirements

It installs Docker if needed, applies safe daemon defaults (log rotation, live restore), starts Postgres on a private network and the control plane, sets up ufw, fail2ban and unattended security updates, and schedules a daily backup. Every step has a flag to skip it, it keeps your existing Docker settings, and it never changes SSH settings. To upgrade, run it again, with --version to pin a release; to go back, run it with the previous version. The uninstaller keeps your apps and data unless you ask otherwise. Read the script before you run it, or see what each step does and how to upgrade and roll back.

The control plane runs from a Compose file that the installer writes, so the host needs Docker and the Compose plugin, version 2.24 or newer. The installer adds both when they are missing. Your own apps do not need Compose: a service is an image or a Git repository. If you already have a Compose file, you can run it as one stack, which needs the same plugin on the server that runs it, or split it into separate services. Requirements, Compose stacks

The three are close cousins. NebulaCtrl puts your services on a canvas with staged changes, checks health from outside the container, verifies through the proxy and puts the old route back if that fails, and isolates environments from each other on a host. Coolify and Dokploy are ahead on Nixpacks, host bind mounts, a raw proxy config editor, community size and years in production. The comparison lists both directions.

It is young, so start with something you can afford to move. The control plane is a single instance without high availability, the Cloudflare and Tailscale paths have been tested against simulated APIs and not a live account, and the limitations page lists everything it does not do. Your apps keep running if the control plane goes down. The agent runs as root, because the Docker socket is root equivalent, and NebulaCtrl assumes a trusted team: roles limit what people can do in the product, not what a compromised host can do. The threat model has the rest.

No. The MCP server is off until you enable it and create a scoped token. It goes through the same checks as the dashboard, edits stage until applied, a person approves any change to production, and every call is audited. The docs are also published as llms.txt and as markdown per page for the agents that read them. MCP reference

Databases back up on a schedule to S3 compatible storage or a directory, and restore into a new or the same database. Volumes of ordinary services back up with restic. The control plane database is dumped daily. There is no point in time recovery and no database failover, and a directory on the same server is not an off site backup; the dashboard says so wherever you choose it. Backups, control plane backup and restore

Yes, in two ways. To move apps, change a service's placement and deploy, or drain a whole server and let NebulaCtrl move every service to the others. Volumes are not copied, so move the data of databases and other stateful services yourself first. To move the control plane, install the same version on the new machine, restore the latest control plane backup with your original secret key, and point your address at it; agents dial that address. Draining servers, backup and restore

Your apps keep running and the proxy on each server keeps serving traffic: the control plane never stops remote containers while it is down, and that includes restarts and upgrades. What you lose until it is back is the dashboard, deploys, logs and metrics in the interface. When it returns, each agent reconnects, reports what is running and the control plane reconciles it against what you asked for. A backup slot that came due while it was down runs as soon as it is up. The control plane, servers and the reconciler

You do. It lives in a Postgres database on your control plane host and in Docker volumes on your servers. Variables are encrypted with AES-256-GCM under a key that exists only on your host and is never part of a backup. Backups go to a directory or an S3 bucket you choose. The threat model lists what is protected and what is not.

No. NebulaCtrl sends no telemetry and no usage reports, and it does not check for updates. It contacts only what you configure: your Git host, container registries, Let's Encrypt, your DNS provider and the services you connect. The installer downloads Docker from Docker's repository and looks up the machine's public address from an IP lookup service; --public-ip skips that. If you turn on the request origins map, it downloads DB-IP's free location database. This site sets no cookies and runs no analytics.

The installer generates one key and keeps it in /opt/nebulactrl/.env as NEBULACTRL_SECRET_KEY. Copy it into a password manager or vault, apart from your database backups, because a backup never contains it. Without the key a restored database opens, but every stored secret is unreadable: variables, Git and registry credentials, SSH keys and backup passwords. You enter them again. The dashboard keeps a reminder card until an administrator confirms the key is stored. To change the key, use nebulactrl-server rekey; never replace it by hand. The control plane, secrets at rest