Project configuration

Environment variables

Environment variables keep configuration and secrets out of your code: database URLs, third-party API keys, behavior flags, and any value that changes between environments. Your application reads them at runtime, for example with process.env.DATABASE_URL in Node.js or os.environ["DATABASE_URL"] in Python.

Where to configure

ChannelHowPermission
ConsoleDuring project creation (Environment variables step) or in Edit projectproject.env.update on the project
CLIzenifra project env add, update, and remove in the Zenifra CLIAPI key with project.env.update
APIGET and PATCH /project/:id/envs, described in Environment variables — APIproject.env.read / project.env.update

To only view values, use project.env.read. Values can be sensitive: grant read access only to people who really need it.

Limits

ItemLimit
Variables per project50
Name lengthup to 120 characters
Value lengthup to 32,760 characters

Large files, long certificates, or bulky lists should not be stored in variables. Generate that data during the build, keep it in persistent storage, or fetch it from your own service.

What happens when you change them

  • Saving variable changes restarts the project instances so the new values are loaded.
  • On projects with more than one instance, plan the change for a low-traffic window and check the logs right after saving.
  • Preview environments inherit the main project variables on every preview creation or update. Review variables that point to shared databases or services; see Preview environments.

Variables set by the platform

Zenifra automatically injects:

VariableContent
ZENIFRA_INSTANCE_VERSIONDeployed version serving the instance

Use it to identify the version in logs, diagnostic responses, or monitoring tools. Do not set ZENIFRA_INSTANCE_VERSION manually: the platform always replaces its value.

Connecting to databases and managed services

DATABASE_URL is not injected automatically into HTTP projects. Copy the connection details of the database or managed service from the console and add the variable to the application project:

DATABASE_URL=postgres://app:PASSWORD@HOST:PORT/app
VALKEY_URL=valkeys://default:PASSWORD@HOST:PORT/0

When you rotate a database password, update the variables of every application that uses it.

Best practices

  • Never commit secrets to the repository or bake them into OCI images.
  • Use descriptive upper-case names, such as STRIPE_WEBHOOK_SECRET or FEATURE_NEW_CHECKOUT.
  • Keep local development values (a .env file outside Git) separate from production values stored in the console.
  • Review who has project.env.read: that permission allows reading secrets in plain text.
  • If you suspect a leak, generate a new credential at the source service, update the variable, and revoke the old one.

Next steps

FAQ

Do I need a new deployment after changing a variable?

No. When you save, the instances restart and read the new values.

Can I set the port through a variable?

The application port is configured on the project itself. If your code reads PORT, add the variable with the same value as the project port.

Do variables show up in logs?

No, unless your application prints them. Avoid logging secret values.

On this page