Environment variables

Set runtime env vars per project at /tools/deploy/ → Variables.

Adding a variable

1. Add variable → key + value.
2. Secret toggle — masks the value in the UI (still readable to the running container, just not visible in the dashboard once saved).
3. Save. Container restarts to pick it up.

Scope: runtime vs build

By default, variables are runtime — available in the container process, not during build.

For build-time vars (used by webpack/vite/next configs at compile time), check Available at build. These leak into the build container too.

Auto-injected variables

We inject some automatically — don't set these yourself:

• PORT — the port your app should listen on (we route Traefik there)
• SUZKO_DEPLOY_PROJECT_ID
• SUZKO_DEPLOY_REGION
• DATABASE_URL, REDIS_URL, etc. — auto-set when you attach a managed service (see Attached services)

Importing from a .env

Variables → Import .env → paste the file contents → submit. Each KEY=VALUE becomes a variable. Existing keys aren't overwritten unless you tick Overwrite existing.

Bulk export

Export .env dumps current variables. Secrets show as SECRET_NAME=<hidden> — actual values aren't exposed in the export, by design.

Multi-environment

Right now there's one set of vars per project. Production-only? That's the assumption. If you want a staging copy, clone the project and point it at a different branch.

Common gotchas

• PORT — your app must listen on process.env.PORT (or equivalent). Hardcoding e.g. 3000 works because that's also the default, but 8080 or 5000 apps without listening on PORT get 502s.
• CORS — set your allow list to include the auto subdomain AND your custom domain.
• Build-time secrets — only enable Available at build if needed. The build container is short-lived but env vars there can end up in build artifacts if you're not careful.