# Environment variables Configuration and secrets for your application: where they apply, how they are kept, and when a change arrives. 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 choose**Add 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 `export`are 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, on`0.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 as`DATABASE_URL` — Laravel's `DB_*`, .NET's `ConnectionStrings__Default`. See[addons](/docs/addons/). The database names are one family. Set one of them yourself — your own`DB_HOST`, say — and the platform stops adding the rest, rather than mixing your host with its password. `nesly env set` and`nesly 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

nesly env set KEY=value	Set one or more variables. Several pairs may follow one another.
nesly env set KEY < file	Take the value from standard input — the way to set a secret without it reaching your shell history.
nesly env set --from-file .env	Set every KEY=value line in a file.
nesly env ls [--reveal]	List the variables. Values are hidden unless you ask and your role may read secrets.
nesly env get KEY	Print one value and nothing else, for a script.
nesly env rm KEY	Remove a variable from every environment; with --env, from that one only.
nesly env pull [file]	Write a .env with what the deployed container sees, platform-added names included.
nesly env run -- command	Run a local command with the project's variables, writing nothing to disk.
nesly env share KEY --with preview	Copy a production value into the preview environment, on the server.
nesly env clone --from other-project	Copy every variable you stored on another project. Addon connections stay behind.

Every command takes `--json` and `--project`; the full reference is the [CLI page](/docs/cli/). --- Canonical: https://nesly.net/docs/environment-variables/ Markdown: Accept: text/markdown on the HTML URL, or replace the trailing slash with .md