Secrets

Nuxfire doesn't use a .env file in production — secrets live only in SST's own vault. Today's deploy path is 100% Cloudflare/SST; automated deploy via GitHub Actions (or any other CI) is future work, not an alternate path that exists today.

Not sure where a specific value comes from? Environment Variables has a direct link for every provider — Cloudflare, your Postgres host, each email/OAuth/payment provider, and how to generate the two platform-admin secrets yourself. This page only covers the loading mechanics.

1. Export the Cloudflare credentials as real environment variables

CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID can't just be stored as an SST secret — SST requires both as a real environment variable on every command (secret load, secret set, deploy, dev...), because that's the credential that authenticates SST to Cloudflare before it can even read the vault.

PowerShell (default on Windows):

$env:CLOUDFLARE_API_TOKEN = "your_token"
$env:CLOUDFLARE_ACCOUNT_ID = "your_account_id"

To persist across terminals: [Environment]::SetEnvironmentVariable("CLOUDFLARE_API_TOKEN", "your_token", "User") (and the same for the account ID) — open a new terminal afterward.

bash/zsh:

export CLOUDFLARE_API_TOKEN=your_token
export CLOUDFLARE_ACCOUNT_ID=your_account_id

To persist, add both lines to .bashrc/.zshrc.

2. Load the rest into SST's vault

One file per stage, never a single reused .env. .env.example is the template (every key, values blank):

cp .env.example .env.stage
# fill in .env.stage with your dev environment's values
bunx sst secret load .env.stage --fallback

Fill in the Branding section first — BRAND_NAME, BRAND_DOMAIN and BRAND_EMAIL (the full sender address, e.g. contact@acme.io). It's the only place your domain and sender email are set, and unlike the credentials below these aren't secrets: the deploy reads them straight from this file, and stops with the name of the variable to fix if one is missing or malformed. Each stage reads its own file, so .env.production needs its own Branding section too.

.env.stage/.env.production are excluded from commits automatically (.gitignore covers .env*) — keep them locally, don't delete them after loading. You'll need them again whenever a secret changes.

Prompt for AI agents:

Ask the user to export CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID in
their own shell first — never request, type, or store these values
yourself. Then: cp .env.example .env.stage, ask the user to fill it in
themselves (never fill in a credential on their behalf), then run
bunx sst secret load .env.stage --fallback.

Next

Deploy — ship your stage.