Everyday Workflows

Learn more about the capabilities of an Internal Developer Platform during a typical day-to-day developer workflow using the free trial.

Overview - What you will do

In this tutorial, we will show what working with an Internal Developer Platform looks like for an application developer. You will learn how to trigger a deployment, how to create a new environment, and how to roll back to an older deployment (in case things do not work as expected).

To get started with Humanitec, head over to our website to request a free trial. We will send you instructions on how to start your free trial as quickly as possible. There is no need to speak with us before testing out Humanitec yourself.

We recommend creating an application first before going through this tutorial. Head over to this section to set up the pre-loaded sample app:


On a typical workday, application developers will code in their IDE, merge their changes through git, and then let their Internal Developer Platform take care of the deployment. The Internal Developer Platform will receive all newly built images and update the environments depending on automation rules set using the Deployment Automation functionality.

Using an Internal Developer Platform in 95% of cases

Beyond supporting this typical workflow, an Internal Developer Platform can do so much more. Typical additional tasks an application developer can handle in an Internal Developer Platform are:

  • Create and deploy to new environments as needed (e.g., for a new feature branch, for QA, to test a hotfix before shipping it)

  • Rollback to a previous deployment (in case things went wrong with the latest code changes)

  • Understand why a deployment failed or why an application does not work as expected (e.g., by inspecting the logs, by diffing with another deployment that worked)

  • Manage deployment automation rules

  • Change configurations for a workload (e.g., environment variables)

  • Add new workloads to an application (e.g., the new service you started to work on)

  • Add external resources to workloads (e.g., databases, file storage)

These are all elements we will explain in this section.

Note that while we show all of these elements in our UI in this section, you can also use our CLI or API to get these things done.


As you first hit the free trial you will see the screen below. It's called the App Overview Screen showing all your apps and the environments per app. In the screenshot below we are calling the sample app we created following this tutorial Trivial App.

1st Deployment

You can now see that the app consists of two workloads, sample-service (a backend service written in Python) and sample-app (written in React). You can click into those workloads to change the configurations and (once the app is up and running) see the logs. On the left hand, you can see the deployments. Each deployment is versioned and saved so that you can redeploy or rollback any time. On the upper left side, you can see the environments. We'll show you how to create new environments later. Let's first hit Deploy to Development.

The Internal Developer Platform will now take all the required steps to deploy your application to the connected Kubernetes cluster and provision the required database for sample-service. If you're wondering what exactly happens under the hood at this point, we're explaining this in detail in this section:

Create a new Environment

Your app is now up and running! An URL should appear below the sample-app card. This URL will take you to your running app. Your next step might be to create a new environment. There might be many good reasons why you want to do that. Maybe, you want to run an integration test for a new service you just created, or you want to test a new feature branch you just started, or you want to test a hotfix that is urgently needed in production, or something else. You can create a new environment following these simple steps:

  • Click on the three dots next to the running deployment.

  • Select clone deployment to and then create new environment next.

  • In the next screen give your environment a name and choose the type of environment (the Environment Type determines which infrastructure to use for your new environment; we will get to that later).

  • Hit Create.

Humanitec will now take the deployment you selected and deploy it to a new environment. This will create a new namespace in Kubernetes, a new database for sample-service, and a new URL. It's important to understand that the new environment you just created is completely separated from the Development environment you created it from.

Change Configurations

Humanitec allows you to update your application configuration without ever touching YML files. We do this by letting your DevOps team define a baseline configuration to which we apply the changes you make to your application configuration through the UI, CLI, or API. This is done through a concept called App Configuration Management. Let's try to change some configurations by adding a new environment variable to one of the workloads.

  • Switch to your Draft on the left-hand side.

  • Click on Edit workload (i.e., the banner) in the sample-app tile.

  • Under Variables add the key NEW-CONFIG and the value Hello World.

  • Hit Done to return to the previous screen and deploy again.

Humanitec will show you in detail the changes you just made and you can add a comment before deploying the changes.

Add a Resource

Another important feature of an Internal Developer Platform is adding dynamic or static resources to your application. These resources are typically things like databases, file storage, or DNS which are all running outside of your Kubernetes cluster. The DevOps team connects these resources to Humanitec and defines which resources to use in which type of environment This is done through a concept called Infrastructure Orchestration. To add a resource - such as a CloudSQL database - you just need to follow these simple steps:

  • Switch to your Draft on the left-hand side.

  • Click on Edit workload (i.e., the banner) in the sample-service tile.

  • Under External resources click on + Add external resources and select postgres from the dropdown.

  • Hit Done to return to the previous screen and deploy again.

A new CloudSQL database will now be created for you and connected with the sample-service.

Diff Deployments

An Internal Developer Platform has many parallels to a version control system. But while a version control system (such as git) handles code, an Internal Developer Platform handles deployments. An Internal Developer Platform saves every deployment in every application and environment. If you need to understand what changed between two deployments you can simply create a diff between them. This will surface the material changes. To create a diff in Humanitec you can follow these simple steps:

  • Click on the three dots next to the deployment you want to diff and select Diff deployment.

  • In the overlay select the deployment you want to diff against.

  • The diff will be directly shown.

  • From here you can create a new draft from the diff.

See Manage Environments for more details.

A diff between two deployments during which we added postgres as a resource.

Rollback to a previous Deployment

There are situations in which you need to roll back to a previous deployment. Humanitec supports moving back to previous deployments easily by following these steps:

  • Click on the three dots next to the deployment you want to roll back to and select Redeploy to Development (where Development is the name of your current environment).

  • Enter a comment and hit Deploy.

Note, that there are obvious limitations of rollbacks and that you should be very careful using this functionality for your production environment. The main limitation is - as always with rollbacks - data migration. If you try to roll back to a deployment that took place before any data migration, the rollback of the application will work but the database schema will be wrong.

Export Manifests

Humanitec allows you to export the manifests for each deployment. You can use the exported manifests in other processes - for example, if you are following a GitOps approach. Exporting manifests is simple:

  • Click on the three dots next to the deployment you want to export and select Export manifests.

  • From the overlay select Generate manifests. It might take a few minutes to generate the download. You can close the overlay in the meantime and come back at a later point in time.

  • Once the export is finished click on Download to download the manifests for this deployment.

A new manifest is generated and ready for download

Add Automation

Going to your Internal Developer Platform just to update an image in your development environment after a successful build process is a repetitive and little value-adding task. That's where automation becomes important. In Humanitec, you can define automation rules to automatically deploy new images from specific branches into any environment. These are the simple steps you need to follow.

  • Click on the three dots next to the environment you want to add an automaton rule for and select Automation.

  • In the overlay click on + Add rule and start defining your first automation rule for the environment.

  • Once you are done hit Done.

Define the rules your environment will use to update images

Each automatic deployment results in a new entry in the deployment history of your environment. You can even go one step further and use the webhook feature in the App Settings to trigger a webhook after each successful deployment. You can use these webhooks to trigger your automated test suite or to inform you and your teammates about a new deployment in your messenger app (such as Slack or MS Teams).

Congratulations. You learned the basics about the most important day-to-day workflows in an Internal Developer Platform. If you want to understand the related features in more detail, then continue reading in the section How-to Guides for Developers.