Environment variables
Configuration for your application, held encrypted and injected into the process at start. Nothing is written to a file on the server.
Where they live
Variables are set per environment on the project’s Environment variables pane. Development and Live hold separate sets, which is the point — a staging database URL should not follow a build into production.
They are encrypted at rest alongside your build and delivered into the process environment in memory. There is no
.env on the host to read, and no plaintext configuration anywhere on that machine.
Reading them in your application
Ordinarily — process.env.DATABASE_URL on Node,
Environment.GetEnvironmentVariable or the standard configuration providers on .NET.
Nothing LockFlare-specific.
dotenv still works. The runtime parses your uploaded
.env and injects it before your code runs, then shims
dotenv so config().parsed returns those values without
touching the filesystem. You do not have to remove it.
Two sources, one environment
| Source | Behaviour |
|---|---|
The .env inside your pushed artifact |
Travels with the build. Same values in every environment you deploy it to. |
| Variables set in Cipher | Per environment. What you want for anything that differs between staging and production. |
Applications also receive a small OS baseline — PATH,
HOME, TZ, LANG,
TMPDIR and NODE_ENV, which defaults to
production.
.env returns
ENOENT — so a compromised application cannot lift the credential that
identifies the server.
Applying a change
Variables are read when the application starts, so a change needs a reload of that environment to take effect. Save them, then reload — there is no need to push again if the code has not changed.
What belongs here
- Database connection strings and credentials.
- Third-party API keys.
- Feature flags that differ between environments.
- Anything you would otherwise have put in a
.envon the server.
Changes are recorded in the activity log with the actor and the time — the fact of the change, not the value.