Environment Variables

Bahriya provides two ways to pass configuration into your container at runtime: plain environment variables and secrets.

Plain environment variables

Plain environment variables are for non-sensitive configuration — feature flags, log levels, API endpoint URLs, and similar values that don't need to be encrypted.

You define them as key-value pairs on the container.

LOG_LEVEL=info
APP_ENV=production
API_BASE_URL=https://api.example.com

These are visible in the Bahriya console — do not use them for passwords, tokens, or any sensitive values.

Secrets as environment variables

Secrets are for sensitive values — database passwords, API keys, private tokens. They are encrypted at rest and decrypted only at deployment time.

You create a secret at the organisation level, attach it to the project, then wire it into your container by mapping it to a specific environment-variable name. The mapping is explicit — you choose the variable name, the platform supplies the decrypted value. See Secrets for the full lifecycle.

A container's secrets list looks like this:

workload:
  secrets:
    - envvar: DATABASE_PASSWORD
      secret: db-password
    - envvar: STRIPE_KEY
      secret: stripe-live-key

The container reads DATABASE_PASSWORD and STRIPE_KEY as normal environment variables; the platform decrypts the named secrets at deploy time and injects their plaintext values.

Order of precedence

If both a plain environment variable and a wired secret target the same variable name, the secret takes precedence.

Updating environment variables

Changes to plain environment variables or to the secrets a container wires trigger a new deployment. The rolling update replaces running instances with new ones carrying the updated environment, with no downtime. To pick up a rotated secret value without changing the wiring itself, redeploy the container from its detail page.

What your application sees

From inside the container, both types appear as standard environment variables — there is no difference in how your application reads them. Use process.env, os.environ, getenv(), or your language's equivalent as you normally would.