What is a deployment environment?

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 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 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).

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.
• 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.

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 shows a full setup with one environment per stage.

Sources

• GitHub Docs: Managing environments for deployment, checked October 30, 2026.