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
| Channel | How | Permission |
|---|---|---|
| Console | During project creation (Environment variables step) or in Edit project | project.env.update on the project |
| CLI | zenifra project env add, update, and remove in the Zenifra CLI | API key with project.env.update |
| API | GET and PATCH /project/:id/envs, described in Environment variables — API | project.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
| Item | Limit |
|---|---|
| Variables per project | 50 |
| Name length | up to 120 characters |
| Value length | up 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:
| Variable | Content |
|---|---|
ZENIFRA_INSTANCE_VERSION | Deployed 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/0When 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_SECRETorFEATURE_NEW_CHECKOUT. - Keep local development values (a
.envfile 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.
Project configuration
Understand how to configure Zenifra projects with GitHub or OCI images, environment variables, domains, network rules, instances, and storage.
Persistent storage
Learn when to use persistent storage in Zenifra HTTP projects, how to choose capacity and directory, and what can change after creation.