> ## Documentation Index > Fetch the complete documentation index at: https://docs.bytebase.com/llms.txt > Use this file to discover all available pages before exploring further. # Environment > Group databases by purpose to apply policies and organize deployment stages. An **Environment** is a named workspace resource that groups databases by their purpose, such as development, testing, or production. Bytebase uses a database's environment to select environment policies and group its deployment tasks into a Rollout stage. For example, an application's Test database can allow developers to deploy changes, while its Prod database requires a designated operator. The databases can belong to the same project and use different environment policies. An environment can apply to databases across multiple projects and instances. ## Environment versus Rollout stage An **Environment** exists independently of any change. A **Stage** belongs to one [Rollout](/concepts/rollout) and groups that Rollout's tasks for an environment. For example, two Rollouts targeting Test each have their own Test stage, both referring to the same Test environment. A Rollout targeting Test and Prod has a stage for each; a Test-only Rollout has no Prod stage. The Plan selects the targets before the Rollout and its stages are created. Bytebase groups tasks by environment and presents stages in the workspace's environment order. Whether tasks run automatically or wait for an operator depends on rollout policy. ## Create environments Workspace Admins, Workspace DBAs, and authorized custom roles manage environments under **Environments**. Create environments for the purposes your databases serve, and use **Reorder** to set their order, such as Dev, Test, then Prod. Creating an environment adds a resource in Bytebase for organizing databases and policies. It does not provision or clone databases. ## Assign an environment Set an instance's environment when registering or editing it. Its databases inherit that environment unless a database has an explicit assignment of its own. Bytebase calls the resulting value the database's **effective environment** and displays it on the database page. An instance is assigned to Test; hr_test inherits Test, while hr_prod explicitly overrides the environment to Prod In this example, `hr_test` inherits Test and `hr_prod` is explicitly assigned to Prod. Changing an assignment changes the policies and deployment grouping Bytebase uses. Database names do not determine their environment. If neither the database nor its instance has an environment, the database's environment appears as **Unassigned**. This describes its environment assignment, independently of which project owns it. Set the intended environment to apply its policies and include the database's tasks in the corresponding Rollout stage. ## Configure environment policies * **SQL Review:** apply rules and severity levels to SQL targeting databases in the environment. * **Rollout:** choose who can run deployment tasks and whether eligible tasks run automatically. * **Direct SQL access:** scope DDL and DML permissions to the environments where members may run those statements directly in SQL Editor. Configure these controls explicitly. An environment named Prod does not by itself require approval or restrict deployment. See [environment policies](/change-database/environment-policy/overview), [SQL Review policies](/sql-review/review-policy), and [rollout permissions](/change-database/environment-policy/rollout-policy) for configuration.