Set environment variables

Environment variables are encrypted at rest with AES-256-GCM and reach two places: your builds, where the install and build commands read them, and your production functions, which read them as context.env. Each variable reaches one of them or both.

A Build variable is not automatically a secret

Most frameworks deliberately inline some variables into the JavaScript they ship, chosen by prefix: PUBLIC_ in Astro, Vite and SvelteKit, NEXT_PUBLIC_ in Next.js. Those values are published the moment you deploy, and no amount of encryption on our side changes that.

Encryption here protects the value in transit and in our database. Whether a variable the build sees reaches your visitors is decided by your framework’s naming rules. A secret that only your functions use belongs in Runtime only, where no build ever sees it.

Set one

curl -X POST "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/env" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "PUBLIC_ANALYTICS_ID",
    "value": "0123456789",
    "environment": "production"
  }'

Setting the same key in the same environment again replaces the value. A new variable reaches both builds and functions unless you choose otherwise.

Scope it to production or previews

Every variable targets one environment:

environment	Applies to
production	Builds of the default branch, and your functions
preview	Builds of every other branch
all	Both

Which one a build gets is decided by comparing its branch to the project’s default branch. A build with no branch at all, an upload rather than a Git build, counts as production. A build sees the variables for its own environment plus everything scoped to all, and the production and preview values of the same key never mix.

This is what keeps a preview from writing into your production analytics, or a pull request from spending against your live API quota. Set the real credential as production, a sandbox credential as preview, and anything harmless as all. Functions run in production only, so they get the production and all variables and never a preview one.

Choose where a variable is available

Target	Reaches	From when
Build	The install and build commands of every build in the variable’s scope	The next build
Runtime	Your production functions, as context.env	Right away, without a redeploy

In the dashboard, open the project’s Environment page. Every variable has a Build and a Runtime checkbox; ticking or unticking one saves at once. The same pair appears when you add or import variables, both ticked to start with. One of the two always stays ticked.

Over the API, send targets. A payment key only your functions use:

curl -X POST "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/env" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "STRIPE_SECRET_KEY",
    "value": "sk_test_0123456789abcdef",
    "environment": "production",
    "targets": ["runtime"]
  }'

Leave targets out and a new variable gets both, while an existing one (same key and environment) keeps the targets it has. The bulk import below takes the same field for every variable it writes.

To change the targets of an existing variable without entering its value again, patch it by the id that reading them back returns:

curl -X PATCH "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/env/$ENV_VAR_ID" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"targets": ["runtime"]}'

The same call takes value to replace the value. The key and the environment cannot change; delete the variable and set a new one instead.

When a Runtime change reaches each function, and the limit on everything functions receive, are in the functions reference.

Import a whole .env file

curl -X POST "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/env/bulk" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "PUBLIC_SITE_NAME=\"My Blog\"\nAPI_TOKEN=0123456789abcdef # staging\n",
    "environment": "preview"
  }'

The parser takes the usual .env shape: # comments and blank lines are skipped, the value starts at the first =, single and double quotes are stripped, inline comments are removed from unquoted values, and when a key appears twice the last one wins.

Every key is validated before anything is written, so a file with a bad key is rejected whole rather than imported halfway. That check is on key names only: if a later write fails, the variables written before it stay.

One thing to strip first: lines beginning export . export API_KEY=… reads the key as export API_KEY, which is not a valid name, and rejects the entire import.

Read them back

curl "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/env" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY"

You get each variable’s id, key, environment, targets and timestamps. Values are never returned, not by this endpoint, not by the dashboard, not to support. There is no read path at all: a value is decrypted only to hand it to a build or to your functions. If you have lost a value, set a new one.

Delete one

curl -X DELETE "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/env/$ENV_VAR_ID" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY"

A variable with Runtime ticked leaves your functions right away, the same way a change reaches them. For builds, deleting takes effect on the next build. The deployment currently serving traffic was built with the old value baked in and keeps serving it until you deploy again. Removing a leaked credential from here does not remove it from your live site. Rotate it at its source, then redeploy.

Rules

Key format	Starts with a letter or _, then letters, digits and _
Key length	Up to 255 characters
Value size	Up to 32 KB
Per project	Up to 256 variables
Everything functions receive	A total limit, in the functions reference
Reserved	Keys beginning DEPLOYBASE_, FN_ or KUBERNETES_, in any casing, and the exact names PATH, HOME and HOSTNAME, are rejected

The reserved names belong to the platform: builds, functions and the container runtime set their own.

Notes

Variables are never written to build logs. A variable with Build ticked is visible to anything your build runs, though, dependencies included, which is the ordinary trust model of a build and worth remembering when you add a new one. A Runtime-only variable never reaches a build.

A few names are set by the build container itself, NODE_OPTIONS among them, which keeps the JavaScript heap inside the memory limit. Setting one of those yourself has no effect on builds: the container’s value wins. NODE_OPTIONS is the one the API warns about, in a warnings field on the response, because with Runtime ticked it does reach your functions.

If you need a value that changes per deployment, a commit SHA for a version string being the usual case, read it from the Git metadata in the build workspace rather than keeping a variable in step by hand.