Introduction

Welcome to Humanitec’s documentation. This section explains what Humanitec is, how to set it up and integrate it into your existing CI/CD landscape.

• If your organization already has a platform built with Humanitec consider the section Introduction to using your platform.
• If you want to get started building and integrating hands-on go to the next steps section.

Why Humanitec #

Humanitec’s products help you turn your existing tools into an Internal Developer Platform that is capable of the dynamic configuration and creation of cloud-native applications and infrastructure configurations with every git push.

This drives consistency and standardization across your teams, as the executable configurations are using the latest version of organization wide baseline configurations.

This approach, known as Dynamic Configuration Management makes it easy for platform engineers to design highly scalable infrastructure for developers. Developers have to handle significantly less complexity when building and operating their applications. The resulting degree of standardization decreases change-failure rate and maintenance overhead, drives developer self-service, and ultimately reduces lead time.

It makes sense for you to investigate Humanitec if:

• You experience a lack of standardization in application and infrastructure configurations that drives operational maintenance overhead
• Your developers wait or are overwhelmed using and or onboarding to your setup and require a better developer experience and or self-service
• Your organization’s productivity and lead time is low
• You are tasked to build an internal developer platform
• You are undergoing a cloud transformation

Humanitec’s products #

Humanitec provides three tools to turn your static CI/CD landscape into a modern Internal Developer Platform capable of dynamically creating configurations:

Score #

A workload specification that allows application developers to describe their workloads and dependencies in an environment agnostic way. There is one Score file per workload, and it’s stored next to the workload source code. There is dedicated documentation if you are using Score as the primary interaction method with the platform.

apiVersion: score.dev/v1b1

metadata:
  name: hello-world

containers:
  hello:
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo Hello World!; sleep 5; done"]

For more information, see the Score documentation.

The Platform Orchestrator #

Sits post-CI and is integrated with adjacent tools such as image registries or secrets managers directly and to resources and compute through drivers. It reads the workload specification (the environment-agnostic request) and generates app- and infrastructure configurations with every deployment. It can also execute the deployments and manage the lifecycle of resources. The Orchestrator can interpret Score files but can also be used via an API, CLI or UI.

For more information, see the Platform Orchestrator documentation.

Drivers #

Extension points to your platform. Drivers are services that implement the Orchestrator API. They can manage the lifecycle of resources, work in tandem with Infrastructure as Code modules, or simply wire a workload to an existing resource managed outside the platform.

For more information, see the Drivers documentation.