Guides
Environment variables
Project vs service env, build-time vs runtime injection, and when changes redeploy.
Scopes
| Scope | Where | Use for |
|---|---|---|
| Project | Project → Environment | Shared defaults inherited by services |
| Service | Service → Environment | Overrides and service-only secrets |
Sensitive values are encrypted at rest. Prefer service scope for credentials that must not leak across services.
Build-time vs runtime
| Service type | When vars are applied |
|---|---|
| Static | Build time — baked into the asset bundle. Changing env triggers a rebuild. |
| Web / worker / cron | Runtime injection (and during image build when a build step runs) |
Saving env that requires a new process or build typically queues an env_change redeploy.
Public / client prefixes
Values that must ship to the browser (Next.js NEXT_PUBLIC_*, Vite VITE_*, etc.) are available at build time for frameworks that inline them. Treat public prefixes as non-secret.
Platform-injected vars
Bytstack also injects platform metadata into workloads (do not set these yourself unless you know why):
| Variable | Meaning |
|---|---|
PORT | HTTP listen port for web services |
NODE_ENV | Typically production |
DATABASE_URL | Internal DB URL when a database is attached |
BYTSTACK_SERVICE_ID | Current service id |
BYTSTACK_DEPLOYMENT_ID | Current deployment id |
BYTSTACK_APEX_HOST | Apex host for path-based SaaS routing |
BYTSTACK_API_PATH | API path prefix when using path split |
BYTSTACK_EDGE_TARGET | Edge routing target metadata |
See Platform reference for more.
CLI
bytstack env set KEY=valueListing and deleting vars is done in the dashboard today.
Naming tips
- Use conventional names (
DATABASE_URL,REDIS_URL) so frameworks pick them up. - Never commit secrets to git — store them in Bytstack env.