Getting Started
Set up environment variables
Environment variables let you configure your service without hardcoding values in source code. On StackBlaze, every variable you set is stored as a Kubernetes Secret or ConfigMap and injected into your container at runtime via the pod spec, the same mechanism Kubernetes uses natively.
Secrets are encrypted at rest in etcd and never sent to the browser after initial save. When you attach a managed database or cache, StackBlaze automatically injects the connection string so you never need to copy-paste credentials.
Environment variable editor
| Key | Value | Type |
|---|---|---|
| NODE_ENV | production | plain |
| PORT | 3000 | plain |
| API_KEY | •••••••••••••••• | secret |
| DATABASE_URL | •••••••••••••••• | auto-injected |
| REDIS_URL | •••••••••••••••• | auto-injected |
Click the eye icon to reveal a secret value. Auto-injected variables (DATABASE_URL, REDIS_URL) are read-only, they update automatically when you change the attached database configuration.
Variable types
Plain variables
Non-sensitive configuration like NODE_ENV, feature flags, or region identifiers. Stored as a Kubernetes ConfigMap and visible in plain text in the dashboard.
Secrets
Sensitive values like API keys, tokens, and passwords. Stored as a Kubernetes Secret object, base64-encoded at rest and never shown in the dashboard after saving. Values are injected as container environment variables at runtime.
Shared variables
Variables scoped to an environment (e.g. "production") that are automatically available to every service in that environment. Useful for a shared SENTRY_DSN or internal API base URL.
Auto-injected from attachments
When you attach a database or cache to a service, StackBlaze automatically adds the connection string as a secret. DATABASE_URL for PostgreSQL, REDIS_URL for Redis. You cannot override these, they are managed by StackBlaze.
Auto-injected DATABASE_URL
# Automatically set when you attach a PostgreSQL database
DATABASE_URL=postgresql://sb_user:••••••••@postgres.internal:5432/mydb
# Access it in your application exactly like any other env var
const db = new Pool({
connectionString: process.env.DATABASE_URL,
})
# The hostname “postgres.internal” resolves inside your project network
# via Kubernetes Service DNS — no public internet exposure
How secrets are stored
- Kubernetes Secrets are used for all values you mark as secret. They are base64-encoded in etcd (and encrypted at rest if the cluster has encryption providers configured).
- ConfigMaps hold plain (non-secret) variables. They are mounted into the pod as environment variables via
envFromin the pod spec. - RBAC ensures only pods in your project namespace can read those Secrets. Other tenants' namespaces have no access.
- Redeploy required: environment variable changes are applied by triggering a rolling update. In-flight requests complete on old pods before they terminate.
Step by step
Go to Service → Environment
In the StackBlaze dashboard, open your service and click the "Environment" tab. You'll see all variables currently set for the service, including any auto-injected ones from database or cache attachments.
Add key/value pairs
Click "Add variable" and type the key and value. Keys must be valid POSIX environment variable names: uppercase letters, digits, and underscores only. You can add multiple variables at once, changes are batched until you click Save.
Mark sensitive values as Secret
Toggle the lock icon next to any variable that contains a secret. Once saved, the value is stored in a Kubernetes Secret and masked in the dashboard UI. It is never sent to the browser again, you can only replace it, not read it back.
Redeploy to apply
Environment changes take effect on the next deployment. Click "Save & Redeploy" to trigger an immediate rolling update with the new variables, or save without deploying to apply them on the next push-triggered build.