Environments

How environment variables reach your application #

Depfloy writes your environment variables to shared/.env on the server. The active release symlinks this file in as current/.env, so when your application reads .env, it picks up whatever you set here. Changes apply on the next request without a full deploy — but for variables that are read at startup (queue workers, schedulers, Node.js processes), you’ll need to restart the relevant process for the new value to take effect.

When a deploy fails #

Depfloy writes shared/.env partway through a deploy, before the new release takes over — which means that one step reaches the release that is serving right now. So if the deploy then fails, is cancelled, or is rolled back after going live, the file goes back to what it held before the deploy started. Your running application keeps the values it was already serving with, and a new set of values becomes permanent only when a deploy completes.

NODE_ENV on Node.js projects #

Depfloy starts a Node.js process with NODE_ENV=production. Frameworks like Next.js and React Router pick their build from that variable, and an undefined NODE_ENV makes them load the development build.

To run a project as something else, set NODE_ENV here as a normal variable — your value is the one used, and it takes effect on the next deploy.

Add a variable #

Click Add Variable, enter a name (uppercase by convention — DATABASE_URL, API_KEY), enter the value, and save.

For multi-line values (private keys, certificates), the editor supports newlines — paste the whole block in one go.

Plain vs. encrypted #

Each variable can be marked encrypted when you create or edit it. Encrypted values are stored encrypted in Depfloy’s database and are only shown to members with permission to view them — the rest of your team sees them as ••••••••. The value on the server itself is still written as plaintext in shared/.env; the encryption is about who can read the value in the UI, not who can read it after SSH’ing to the box.

Mark API keys, database passwords, third-party tokens, and any other secret as encrypted. Leave configuration that isn’t sensitive (APP_ENV, APP_URL, LOG_CHANNEL) as plain so the team can see what’s set without revealing what isn’t.

Edit, copy, and delete #

Click any variable to edit it. Click the copy button next to a value to copy it to your clipboard.

To delete, click the three-dot menu on the variable row and pick Delete. The deletion takes effect immediately; to get the variable back, restore an earlier version of the file — see below.

History #

Every saved change to the file is kept, under History below the editor. Each entry shows when it was saved, who saved it, and how many variables it held — never the values themselves. Reading an old value means restoring it, and that is recorded.

Restore puts an entry back. Before it does, it tells you what the restore removes: a version saved before you added STRIPE_KEY does not merely lack it, it takes it out of the file. That is the half worth reading twice, so the dialog leads with it and names the variables.

Restoring is itself saved as a new version, so a restore can be undone the same way. The file is written to the server straight away, and your running application keeps its current values until the next deploy.

Depfloy keeps the last 50 versions per project and branch, dropping the oldest past that. An assistant connected over MCP can read this list and restore from it too, which is how a bad automated edit gets undone.

Bulk paste #

The fastest way to set up a new project is to paste the whole .env content at once. Click Bulk Paste, paste your file content, and Depfloy parses it line by line. You can review what it picked up before saving.

APP_NAME=Laravel
APP_ENV=production
APP_KEY=base64:9aG+...
DATABASE_URL=postgres://...

Search #

If you have a lot of variables, the search box at the top of the list filters by name as you type. Useful for tracking down “where exactly is STRIPE_WEBHOOK_SECRET defined”.

Editing the file manually via SSH #

If you SSH into the server and edit shared/.env directly, your changes do persist — but the next time someone edits a variable through the Console, the entire shared/.env is rewritten from Depfloy’s view of the world. Use the Console as the source of truth; direct SSH edits are for emergency fixes only.