# Work with environments

Keep development, test, acceptance, and production apart within one project.

An environment is an isolated context inside a project. Jobs, runs, and usage are tracked per environment, so building something in development cannot disturb what production is doing.

![The project Settings page showing the project name, time zone and Environments, with Development checked as current and Test, Acceptance and Production unchecked.](demos/guides/projects-work-with-environments-light.png)
{mode="true" class="guide-image"}

## Bind the ones you need

Add the environments the project actually uses, and remove the ones it does not. A project always keeps at least one, because the last environment cannot be removed.

Removing an environment affects the jobs configured for it, so read the confirmation before you agree to it rather than after.

## Switching

Switching environments in the app changes which sources and jobs you are looking at. The Monitor page does not follow the switch yet: it shows the development environment's runs. It is a lens over the same project, not a different project. The membership is shared. The Git binding is not: each environment has its own, a repository and a branch.

## A realistic shape

Start with development for building and production for the real thing. Add test or acceptance when there is actually someone doing the testing or the accepting; an empty environment is a place for configuration to rot.

## Moving configuration between environments

Today this goes through your Git repository: commit the configuration you are happy with, and apply it where you want it. There is no one-click promotion in the app yet, and treating Git as the promotion path has the side benefit that every promotion is reviewable.

See [Review and commit changes](/docs/guides/version-control/review-and-commit-changes/).

## Next

[Manage project members](/docs/guides/projects/manage-project-access/).