Environment variables

Variables are how your application gets its configuration and its secrets — a database address, an API key, a feature switch. You set them on the project; nesly hands them to your build and to every instance it starts.

A change arrives with the next deployment. Running instances are never changed in place, so saving a value and reloading the site shows the old value until you deploy again. The console offers a Redeploy right after you save.

Setting variables

nesly env set API_URL=https://api.example.com LOG_LEVEL=info
nesly env set DATABASE_URL < connection.txt      # the value never touches your shell history
nesly env set --from-file .env                    # every line of a file
nesly env ls

A value typed as an argument is visible to anyone who can list processes on your machine, and your shell records it. For anything secret, pipe it in or read it from a file.

In the console, open the project's Variables tab and chooseAdd variable. To move a whole file, choose Paste .env — or paste the file straight into the name field — and every variable in it is saved together.

Names use A–Z, 0–9 and_, and may not start with a digit. A file is read the simple way every platform exports it: comments, blank lines and exportare skipped, one pair of quotes is removed, and nothing is expanded — a$OTHER in a value stays exactly that.

Production and preview

A variable applies to every environment unless you scope it. A scoped value wins over the unscoped one of the same name, so giving previews a sandbox key is one command and changes nothing in production:

nesly env set STRIPE_KEY=sk_live_… --env production
nesly env set STRIPE_KEY=sk_test_… --env preview
nesly env ls --env preview      # what a preview deployment will see

A preview gets a database of its own, not production's. A preview address is public, so instead of production's connection each managed Postgres, MySQL, MS SQL, MongoDB, Valkey or bucket on the project gets a second, empty one the first time a preview needs it, shared by all of the project's previews. Nothing to set up. To point previews somewhere else, scope your own value to preview — it wins. To give them production's on purpose, nesly env share DATABASE_URL --with preview copies it on the server without printing it.

Variables the platform adds

Some names arrive in the container without you storing them:

• PORT — the port your application must listen on, on0.0.0.0.
• APP_URL — the project's public address, unless you set one yourself.
• A managed database's connection, spelled the way your framework reads it as well asDATABASE_URL — Laravel's DB_*, .NET's ConnectionStrings__Default. Seeaddons.

The database names are one family. Set one of them yourself — your ownDB_HOST, say — and the platform stops adding the rest, rather than mixing your host with its password. nesly env set andnesly env ls name what is being left out.

How values are kept

Values are encrypted before they are written down (AES-256-GCM) and decrypted only to hand to your build and your running application. Listings hide values by default; showing them needs a role that may read secrets, and a viewer on your team sees that a variable exists, never what is in it.

.env files in your project are never uploaded with a deployment, and neither is anything your .gitignore excludes.nesly env pull writes one for local development — it holds real secrets, so keep it out of version control. Setting that file back with--from-file stores the same values it was pulled with.

Commands

Every command takes --json and --project; the full reference is the CLI page.