Skip to main content
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 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, SQL Review policies, and rollout permissions for configuration.