Environments
An environment is a named deployment target where a team runs its processes in Camunda Hub. For example, a payments environment gives the payments team its own isolated deployment target to run production processes.
Clusters are the infrastructure underneath. Organization admins manage clusters, and teams work with the environments assigned to their workspace.
Environments and clusters
Camunda Hub separates the infrastructure you operate from the place your teams work:
| Cluster | Environment | |
|---|---|---|
| Purpose | Administrative unit. The infrastructure that runs Camunda 8. | Operational unit. The deployment target where a team tests, runs, and operates processes. |
| Managed by | Organization admins and DevOps | Assigned to workspaces by organization admins |
| Typical tasks | Create, size, update, back up, and secure the cluster. | Deploy a project, test a process, and open Operate, Tasklist, or Admin. |
Teams deploy to an environment, not to a cluster. A cluster can host more than one environment, and every environment belongs to exactly one cluster. Learn more about clusters.
How an environment maps to infrastructure
An environment is backed by an isolated unit of a cluster. The cluster version determines which unit backs it, and you don't choose it:
| Cluster | Backed by | Environments on the cluster |
|---|---|---|
| Self-Managed, version 8.10 or later | Physical Tenant | One for each Physical Tenant. The default Physical Tenant always exists. |
| SaaS | Cluster | One environment |
| Any cluster before version 8.10 | Cluster | One environment |
Camunda Hub derives the name of an environment. An environment backed by a Physical Tenant other than default uses the Physical Tenant ID. Any other environment uses the cluster name.
Camunda Hub also supports Logical Tenants for an environment. If the target of a deployment has multi-tenancy enabled, you choose a Logical Tenant during the deployment.
Environment tags
An environment carries the tags of the cluster that backs it, for example dev, test, stage, or prod. Use tags to filter environments and to see which stage of your development lifecycle an environment serves.
The prod tag also marks an environment as a production environment. Your organization can require an approved project snapshot before anyone deploys to it. See project deployment settings.
Who can see and use environments
Organization owners and admins assign environments to workspaces. DevOps users can also assign environments to workspaces where they are an editor or workspace admin. An environment can be assigned to more than one workspace, and a workspace can have any number of environments, including none.
Organization level
On the Environments page and in the navigation:
- SaaS: Every user in the organization sees every environment and can open its applications. Only organization owners, admins, DevOps users, and legacy Developers can resume a paused environment.
- Self-Managed: Organization admins and DevOps users see every environment. Other users see only the environments assigned to workspaces where they are a workspace admin or editor.
Workspace level
Within a workspace, users see only the environments assigned to that workspace, whatever their organization role:
| Workspace role | What the role sees |
|---|---|
| Workspace admin or editor | The environments assigned to the workspace |
| Workspace viewer or commenter | No environments |
Every project in a workspace can use all the environments assigned to the workspace. A project can't reach an environment that its workspace doesn't have.
Users can open the applications of every environment they see, but the Orchestration Cluster decides who can deploy to an environment and what they can see and do in its applications. See access control.
What an environment contains
Each environment has its own applications and its own health status:
- Operate, Tasklist, and Admin for the processes that run in the environment.
- Optimize, where it's configured.
- Job workers and their job statistics.
Cluster-level settings, such as the cluster size, version, backups, and IP allowlists, stay with the cluster.
Next steps
- Learn how to deploy a project.
- Read about clusters, workspaces, and projects.
- Read about Physical Tenants and Logical Tenants.
- Look up the term in the glossary.