# What is a deployment environment?

> A deployment environment is one place your app runs, such as development, staging or production, with its own settings. Why access should follow it.

URL: https://crunu.com/learn/deployment-environment
Language: en
Updated: 2026-10-30

A deployment environment is one named place where a copy of an application runs for a specific purpose, such as `development` for building, `staging` for testing a release and `production` for real users, each with its own infrastructure, data and settings.

## Environment is not "environment variables"

The word does double duty, and it causes real confusion. A deployment environment is a stage in your release process. The process environment is the set of [environment variables](https://crunu.com/learn/environment-variable) a running program receives. One deployment environment typically supplies one set of environment variables to the programs running in it. Crunu's own documentation keeps the two apart for this reason: "environment" means the unit you deploy to, and "environment variables" means what a process gets.

## Why the separation matters

Environments exist to contain mistakes. You break staging so you don't break production. That only works if what is in staging can't touch production:

- **Separate credentials.** Staging should have its own database password and its own test-mode API keys. A shared value makes staging a door into production.
- **Separate access.** Most people need development and staging every day and production rarely. Access that follows the environment is [least privilege](https://crunu.com/learn/least-privilege) in practice.
- **Separate approvals.** CI systems put gates on environments. In GitHub Actions, environment secrets "are only available to workflow jobs that use the environment", and only after protection rules such as required reviewers pass ([GitHub Docs](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)).

## Common mistakes

- **Production values in development "to test against real data".** It puts production credentials on every laptop.
- **One secret for several environments.** Then the most exposed environment sets the protection level for all of them.
- **Environments that differ by accident.** Purposeful differences are the point; unplanned ones are [configuration drift](https://crunu.com/learn/configuration-drift).
- **Too many environments.** Every extra environment is another set of values to keep correct. Add one when it has a clear purpose.

## Environments in Crunu

In Crunu, an environment is the unit of encryption and of access. A project such as `payments-api` holds environments such as `development`, `staging` and `production`, and new projects start with `dev` and `prod`. Each environment has its own encryption key, its own access list, its own history and, optionally, its own network rule.

*Figure: Each environment of payments-api at Kiteline, a fictional company, has its own key, sealed only to those on its access list. Jonas Lindqvist is an editor on development and staging through the Developers access profile, so those two keys are sealed to his key. The production list has Amara Okafor as a reader and the machine api-prod-1, but not Jonas, so nothing he holds opens production.*

The separate key is what makes the boundary hold. A developer granted `payments-api / development` receives the key to that environment only, so their session, their machine or a tool running as them can't decrypt production: there is nothing to decrypt it with. The same applies to machines and CI service tokens, which are granted environments the same way. When access changes, for example when someone leaves, the key of each environment they could read is rotated.

To start an environment from another one without copying secrets, create it with **Variable names only, no values**. The [guide to sharing .env files with a team](https://crunu.com/guides/share-env-files-with-a-team) shows a full setup with one environment per stage.

## Sources

- [GitHub Docs: Managing environments for deployment](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments), checked October 30, 2026.