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 separately (see Secrets), then link it to your container. When linked, the secret is injected into the container as an environment variable using the secret's handle as the variable name.
For example, a secret with the handle database-password is injected as:
DATABASE_PASSWORD=<decrypted value>
The handle is uppercased and hyphens are converted to underscores to form the environment variable name.
Order of precedence
If both a plain environment variable and a linked secret use the same key name, the secret takes precedence.
Updating environment variables
Changes to plain environment variables or linked secrets trigger a new deployment. The rolling update replaces running instances with new ones carrying the updated environment, with no downtime.
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.
