Working with Environments

In this section you will learn how to work with Environments in Humanitec.


Environments are one of the core elements in an Internal Developer Platform. Internal Developer Platforms allow developers to create new Environments and change (development) Environments on their own without support from the DevOps team. This section explains how Environments are managed in Humanitec.

Your App in Humanitec consists of Workloads, External Resources, and Application Configurations. Refer to the section Configure an App to learn more about how to set up an App in Humanitec. Each App can have as many Environments as you like. There are different ways to create a new Environment. You can create a new Environment...

  • ... by cloning an existing Environment or

  • ... by cloning a specific Deployment into a new Environment.

Which infrastructure is used for each new Environment depends on the Environment Type which can be configured by the DevOps team. Want to learn more?

Internal Developer Platforms enable you to spin up new Environments dynamically. This allows teams to move beyond the traditional setup of a limited number of shared Environments (e.g., development, staging, production). This new freedom can be used to implement state-of-the-art delivery processes including (automated) QA Environments, ephemeral Environments, or new Environments for each feature branch.


An Environment of the Environment Type testfeaturebranch might dynamically spin up a PostgreSQL database (if added needed in a Workload), provision DNS dynamically per Environment, and create a namespace in a GKE cluster.

For the same App, an Environment of the Environment Type production might not spin up anything dynamically but just pass the information to which static production database to connect to, which Kubernetes cluster to use, and which static DNS to wire up.

Important Concepts

Table of Contents