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

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

Limits

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 during the build

In projects whose source is a GitHub repository, the project variables are also available to the Pre-build Command and the Build Command. This is how frameworks that embed configuration into the code sent to the browser get their values, such as VITE_* in Vite and NEXT_PUBLIC_* in Next.js.

• Values used in the build are written into the build output. Saving a change restarts the instances but does not rebuild the application: to apply the new value, choose New build in Build logs or push a new commit.
• Anything the build embeds into browser code is visible to whoever opens the application. Use VITE_*, NEXT_PUBLIC_* and similar prefixes only for public values, such as an API URL, and never for passwords or private keys.
• Variables are only used in builds from the repository connected to the project.

Variables set by the platform

Zenifra automatically injects:

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

• Project configuration
• Persistent storage
• Security
• Limits and quotas

FAQ

Do I need a new deployment after changing a variable?

For variables read at runtime, no: when you save, the instances restart and read the new values. For variables used in the build, such as VITE_* and NEXT_PUBLIC_*, yes: choose New build in Build logs to build the application with the new value. See Variables during the build.

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.