nebula deploy
Build and deploy the mesh to Nebula Cloud or your own Hetzner project
To build and deploy the mesh to Nebula Cloud or your own Hetzner project, run:
nebula deploy [--target hetzner|cloud] [--workers N] [--min N] [--max N] [--npcs N] [--open-ui] [--reset-persistence]Two targets, chosen with --target or deploy.target in nebula.json.
--target cloud deploys to Nebula Cloud (log in first with nebula cloud login). The first run picks or creates the organization, project and deployment (interactively, or from --org, --cloud-project, --deployment; --yes takes the defaults) and records them in the cloud section of nebula.json. Every run then builds the Linux dedicated server, uploads Builds/nebula-linux.tar.gz as a content-addressed artifact, creates an immutable release from it with the service manifest, the Nebula and protocol versions and the git commit, and rolls the release out, printing the operation's steps until it finishes. Ctrl-C leaves the rollout running; the next nebula deploy reattaches to it. --release rolls out an existing release without building. --min/--max change the deployment's worker band first. The release records the protocol window its gateways admit (HelloMsg.ProtocolVersion and MinProtocolVersion) and the game content version from Assets/Resources/NebulaConfig.asset. A gateway admits clients at its own protocol and one older, so a rollout that moves the protocol one version forward keeps every connected player. A rollout is refused when it moves the protocol more than one version, moves it backwards, or the release's MinProtocolVersion excludes the clients of the current release; --allow-protocol-change accepts disconnecting them. A content version bump that would refuse the current release's clients is reported as a warning at the start of the rollout.
--target hetzner deploys to your own Hetzner Cloud project (nebula config hetzner first):
Build the Linux dedicated server at Builds/nebula-linux.tar.gz. Create any missing SSH key, private network, firewall, and orchestrator VM. Upload the build and restart the orchestrator service. The orchestrator hosts the control plane, creates one VM per worker, and keeps the control plane and every saved entity in its database.
--workers N alone runs a fixed mesh of N VMs. --min/--max open an autoscaling band: the orchestrator starts at --min, adds VMs while workers are busy and retires them into an idle pool when they are not (see deploy.idlePoolSeconds in nebula.json; the default keeps a retired VM for the hour Hetzner bills). --min 0 allows scaling to zero; the first player then waits for a VM to boot.
The database is a SQLite file on the orchestrator VM (/opt/nebula/data/nebula.db) unless you point the mesh at a PostgreSQL server with nebula config database, deploy.database in nebula.json, or NEBULA_DATABASE_URL. Saved entities stay across deployments unless you pass --reset-persistence. Every deployment generates a new mesh token that workers and the gateway present to the orchestrator.
Run this command again after you change game code. A deployment restarts the orchestrator and recreates its workers.
A deploy target must be configured (nebula cloud login or nebula config hetzner).
Options
| Option | Description |
|---|---|
--target <name> | Deploy target: hetzner or cloud (default from nebula.json deploy.target). |
--workers <N> | Worker VMs to start with; on its own it fixes the count (min = max = N). Default from nebula.json, 4. |
--min <N> | Autoscaling floor; the mesh starts here when --workers is not given, and 0 allows scaling to zero (default: --workers). |
--max <N> | Autoscaling ceiling; autoscaling grows into the band from --min (default: --workers). |
--release <rel_id> | Cloud: roll out this existing release instead of building a new one. |
--label <text> | Cloud: a label for the new release, e.g. v12. |
--allow-protocol-change | Cloud: roll out even when the protocol change would refuse the current release's players (they are disconnected). |
--region <id> | Cloud: region of a deployment created by this run. |
--worker-size <size> | Cloud: worker machine size (small, medium, large). |
--org <slug> | Cloud: organization slug (default from nebula.json). |
--cloud-project <slug> | Cloud: project slug inside the organization (default from nebula.json). |
--deployment <name> | Cloud: deployment name inside the project (default from nebula.json). |
--npcs <N> | Set the game-defined 'npcs' mesh setting at startup (default from nebula.json). |
--open-ui | Open the Nebula Dashboard once it answers. |
--skip-build | Use the existing Builds/nebula-linux.tar.gz. |
--release-build | Build the Linux server as a release (not development) build, whatever NebulaConfig says. |
--development-build | Build the Linux server as a development build, whatever NebulaConfig says. |
--il2cpp | Build the Linux server with IL2CPP (needs the Linux IL2CPP module in the Unity install). |
--mono | Build the Linux server with Mono. |
--skip-publish | Do not publish the control-plane and persistence modules. |
--skip-upload | Only rewrite the service and restart (no build, no upload). |
--reset-persistence | Delete every saved entity when the orchestrator starts. |
Global options
These work with every command and may appear before or after it.
| Option | Description |
|---|---|
--project <path> | Run against another Nebula project instead of the current folder. |
-v, --verbose | Print stack traces and the commands the CLI runs. |
-y, --yes | Answer every confirmation with yes. |
Examples
nebula deploy --target cloud
nebula deploy --min 1 --max 8 --open-ui
nebula deploy --release rel_01h
nebula deploy --target hetzner --workers 4
nebula deploy --skip-build
nebula deploy --release-build --il2cpp