Environment variables

Every deployment on Ownkube has its own environment variables. Plain-text values are stored as-is; values marked Secret are stored securely and masked in the UI. Both types are injected into your container at runtime.

Manage them on the deployment Settings tab in your dashboard.

Adding variables

Open the deployment Settings tab

Go to your deployment and scroll to Environment variables.
Add a KEY=value pair

Click Add variable. Each entry has a Key, a Value, and a Secret toggle.
Mark sensitive values Secret

Flip the Secret toggle on any value that shouldn’t be visible in the UI. Secret values are encrypted in Ownkube’s database and masked in the dashboard after you save.
Save

Saving triggers a rolling update. New containers start with the updated environment; old ones drain once the new ones pass health checks.

Variable types

Type	What it’s for	Example
Plain text	Non-sensitive configuration	`NODE_ENV=production`
Secret	Sensitive values (API keys, tokens, credentials)	`STRIPE_API_KEY=sk_live_...`
Auto-injected	Database credentials populated when you attach a database	`DATABASE_URL=postgresql://...`

Auto-injected database credentials

Attach a database deployment to a web or worker deployment, and Ownkube automatically injects its connection string and individual credentials as environment variables:

DATABASE_URL=postgresql://user:pass@host:5432/dbname
PGHOST=...
PGPORT=5432
PGUSER=...
PGPASSWORD=...
PGDATABASE=...

You don’t manage these manually. Credential rotation happens automatically and the new values are picked up on the next rollout. See Databases for details.

How secrets are stored

At rest: encrypted in Ownkube’s database, and stored in your cluster’s secret store
In transit: only ever travel over TLS
In the UI: masked after save; a short prefix is shown so you can identify which value is which
In logs: the structured logger redacts any env var with the Secret flag

Ownkube never prints a secret value back to you in plain text after it’s saved. If you lose it, you’ll need to re-enter it.

Scope

Variables are deployment-scoped. Each deployment keeps its own set, so api @ Development and api @ Production have independent environment blocks.

Best practices

Never commit secrets to your repo. Put them in Ownkube and reference them at runtime.
Pin versions. Use NODE_ENV=production literal values instead of relying on implicit defaults.
Keep development and production separate. Use different environments so accidentally editing the wrong one isn’t possible.
Rotate periodically. For third-party API keys, rotate in the provider first, then paste the new value into Ownkube. Saving triggers a rolling update, so old containers drain on the old credentials and new ones come up with the new values.

Limits and constraints

Key names must be valid shell identifiers (A-Z, 0-9, _, not starting with a number)
Value size is capped at a few KB per variable. If you need a larger blob, store a reference (e.g. an S3 path) and fetch it at runtime
No environment-level variables yet. Deployment-scoped only

Databases How database credentials are auto-injected.

Deploy your first app End-to-end walkthrough that covers setting variables on a new deployment.