nebula env
Manage the environment variables your workers get
To manage the environment variables your workers get, run:
nebula env <ls|set|rm|pull|push> [KEY[=VALUE]|file] [--secret] [--deployment <name>] [--target hetzner|cloud]Environment variables pass your game's own settings and secrets to its workers: service URLs, API keys, feature flags. Every worker process gets them as ordinary environment variables, and NebulaEnv.Get reads them in code. Changes apply when workers next start: the next nebula deploy, rollout or restart. On Nebula Cloud, nebula restart-workers applies them now, one worker at a time.
ls: list the variables with the deployments they apply to. Secret values are never shown.
set KEY=VALUE: create or replace a variable. set KEY without a value reads it from standard input, or asks for it when you run the command in a terminal, so a secret stays out of your shell history: nebula env set GAME\_API\_KEY --secret \< key.txt.
rm KEY: remove a variable.
pull: print the non-secret variables as a dotenv file, or write them to --out. Secret values never leave Nebula Cloud; each one appears as a comment. nebula env pull --out .env.nebula gives local runs the deployment's settings.
push FILE: upload every variable in a dotenv file at once. --secret-keys marks which of them are secret.
On Nebula Cloud (deploy.target cloud) the variables belong to the project in nebula.json's cloud section. Without --deployment a variable applies to every deployment of the project; --deployment staging,production limits it to those. The Cloud Dashboard edits the same variables.
On a self-hosted Hetzner deployment (deploy.target hetzner) the variables are kept in deploy.env in nebula.json. That file is committed with the project, so secrets are refused there. nebula deploy writes them into the service manifest on the orchestrator VM, which hands them to every worker VM it starts.
Local runs read a .env.nebula file at the project root instead (nebula start and the Editor). Keep it out of version control; nebula init adds it to your .gitignore.
Names use letters, digits and _, and do not start with a digit. PORT and names starting with NEBULA_ are Nebula's own and are refused. A value can be up to 32 KiB.
Options
| Option | Description |
|---|---|
--secret | Set: the value is secret. It is never shown or downloaded again (cloud only). |
--deployment <name> | Cloud: the deployments a variable applies to, comma-separated (default: every deployment of the project); ls and pull show what one deployment gets. |
--out <file> | Pull: write to this file instead of standard output. |
--secret-keys <K1,K2> | Push: the keys in the file whose values are secret, comma-separated. |
--json | Ls: print the variables as JSON. |
--target <name> | Deploy target: hetzner or cloud (default from nebula.json deploy.target). |
--org <slug> | Cloud: organization slug (default from nebula.json). |
--cloud-project <slug> | Cloud: project slug inside the organization (default from nebula.json). |
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 env ls
nebula env set GAME_API_URL=https://api.example.com
nebula env set GAME_API_KEY --secret < key.txt
nebula env set FEATURE_TRADING=on --deployment staging
nebula env rm FEATURE_TRADING --deployment staging
nebula env pull --out .env.nebula
nebula env push .env.production --deployment production --secret-keys GAME_API_KEY