Environment variables

Plain-text config and secrets, injected at runtime. Auto-generated database credentials handled for you.

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 at app.ownkube.io/dashboard/deployment/:deploymentId.

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.

Environment-level inheritance (set a variable once at the environment level and have every deployment pick it up) is on the roadmap. For now, set variables per deployment.

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.

Don't see a feature you need? Email support@ownkube.io. Ownkube is shaped by the teams using it and we ship what our users ask for.