Find quick answers to the most common questions, gathered from our users.

How do I sell Humanitec to my boss?

That’s an easy sell. Building Humanitec’s functionality yourself takes a minimum of four times our license cost. It has a proven impact on the productivity of your team and measurable savings in workflow effectiveness between devs and Ops. Our ROI is tested against over 1,850 teams by now. As we are approaching the final step of the POC phase we are happy to assist with an individual ROI assessment.

How do I sell Humanitec to my colleagues in application development?

Humanitec is usually introduced and POC’ed by the platform or cloud operations team. That’s intuitive because they’re shouldering most of the pain with ticket-ops. But IDPs are a game-changer for developers too. It frees them from waiting times, enables them to spin up new environments, resources, and services dynamically, and allows them to experiment. It helps them operate the deployment setup in a fraction of the time that was required previously.

We recommend always taking developers along on your journey. Explain to them how Humanitec works, that it’s 100% customizable, that everything is represented as code. For larger POCs we recommend including at least one developer. On our learning hub, you can find a dedicated set of videos geared towards helping developers understand the ins and outs of this. If helpful, our team is happy to give demos to your wider team.

How do I POC/test Humanitec?

We offer a free community version that you can test with no limitations. Testing an IDP is like testing an APM, you will need to set it up for one of your apps, on your own infrastructure to really get the hang of it. We offer a free, guided POC. You and your team will get a dedicated Slack support channel with at least one member of our core engineering team in it (we rotate duty). We will set up a mutual POC execution plan and will work alongside you to get this done. As an estimate, we are probably looking at 4-6 hours to invest from your end (assuming the containers are ready). We run dozens of these POCs at any point in time and you can rely on this as being a standard procedure.

For what type of companies/teams is Humanitec?

Humanitec is running IDPs on four continents. Platforms like these make sense if you are running at least several teams in parallel that depend on a central operations function. We usually see teams starting with 20 developers on the lower end. The median is at roughly 150 developers. Large enterprises with over 1000 developers run Humanitec too.

Can we map roles in Humanitec to SAML or other enterprise authentication providers?

Yes, that is possible. Contact us and we are happy to help you set this up.

Can we run Humanitec ourselves?

Yes, but only in the enterprise tier and exclusively on GKE, EKS, or AKS clusters.

Is Humanitec a black box? How much can I customize it?

Far from it. The only restriction in Humanitec is that the workload orchestrator has to be Kubernetes (on-prem or in the cloud). Everything else can be customized. Application Configurations can be customized by setting workload profiles (baseline YAML file) that help you specify exactly what defaults should be contained in your manifests. Open Source Drivers help you to extend Humanitec to your existing infrastructure or existing IaC setups in the exact way your application requires. Webhooks, our API, RBAC, and other methods help you model the specific workflow your team requires.

How do I wire up my infrastructure? (is my stack supported?)

Through Open Source Drivers. Drivers are services that can manipulate cloud APIs directly or wrap your existing IaC setup and execute it. We are currently covering the ecosystems of Azure, Google, and AWS with SLA-backed drivers. Drivers can help you get the right resource in the exact networking/general setup your application requires. You can customize existing drivers, build your own, ask our network of consultancies to build them for you, or request our team to do so. This section provides more information.

How do I integrate my existing application configurations?

Application configuration management with Humanitec is still strictly YAML-based. The way these YAML files are created changes. While today you probably touch a file and apply manual changes, with an IDP you work against workload profiles (also referred to as Baseline YAML files). The profiles are YAML files themselves and can be set by the operations team to contain all necessary default configurations. This might include certain CPU allocation, annotations, or side-cars. Developers apply diffs to the profiles through the CLI or UI. At deployment time the diffs are applied to the profile, plain manifests are created that you can save to your repo and are executed against the Kubernetes API.

This method makes it easy to diff, debug and maintain your application configurations. It’s also significantly easier for developers to consume and understand. You can easily port current helm charts by simply porting the environment variables and container configs. Migrating a helm chart should take roughly ten minutes (depending on complexity).

I have a CI/CD setup, how is this different and how does it integrate? (static vs. dynamic)

Humanitec is focused on the post-commit phase of your application lifecycle. It receives a build notification from any CI pipeline. In response to a new image build, it can deploy this image to a cluster of choice and update application configurations accordingly. Scripted, pipeline-based CD setups are static. They do a good job if you just push a new version of your code. In reality, there are a lot more things that need to get done when you run a production scale application. Examples include: adding environment variables, changing configurations, spinning up fresh environments, debugging, logging, rolling back, adding services and resources, dealing with RBAC, and more. In today’s static setups this requires developers to understand a wide range of consoles, IaC scripts, and tools, significantly slowing them down. If they are incapable of performing these tasks themselves they bother operations, who end up doing ticket-ops. Statistically, you require a new environment every 300 deployments, but changes like this add up to an average of 53 hours that an engineering team of 7 developers wastes every week. It’s time you save with Humanitec.

Humanitec gets you from a static to a dynamic setup. Platform teams set building blocks for in-cluster and out-of-cluster resources. Developers use them to model deployments, applications, and environments on-demand. The platform auto-generates plain manifests and executes them with every deployment. This enables self-service for developers, letting them move fast while keeping maintenance and governance overhead for operations to a minimum.

What does Humanitec do for me?

For me as a Platform/operations engineer

Humanitec follows the philosophy that developers should be self-serving and have as few transactional conversations with operations as possible. Today you likely have dozens of requests from developers asking for databases, help with deployments, debugging, and maintenance. This changes radically. You now codify against the platform API what infrastructure, config, or automation should start up at what request of a developer. Developers self-serve while automating workflows. All output is security vetted and easy to maintain. With Humanitec you can serve roughly two times the amount of developers you could previously.

For me as a developer

Humanitec frees developers from waiting times, it enables you to spin up new environments, resources, and services dynamically and allows you to experiment rapidly. It helps you operate the deployment setup in a fraction of the time that was required previously. Onboarding a new developer to a delivery setup with Humanitec takes below 30 minutes. We’ve not seen one developer ever wanting to work without such a platform after trying it for a week.

For me as a manager

Humanitec will make your team significantly more productive while saving resources. This includes an average 400% increase in deployment frequency or 50% less overhead in operations. For a team of 7 developers, Humanitec saves on average 53 hours a week of waiting times, manual tasks, and toil. We’re happy to run you through an ROI calculation tailored to your organization.

What are Humanitec’s key components (architecture)?

Humanitec consists of three key components.

  1. The self-service UI and CLI - enable developers to run applications in self-service. They let them deploy, spin up fully-provisioned environments, change configs, add services and resources, and much more.
  2. The Platform API - is connected to your CI pipelines and receives build notifications. The Platform API deals with Roles & Permissions (RBAC), Infrastructure Orchestration (creating/wiring up to the right infrastructure components in the right way at the right time), Application Configuration Management (creating the right manifests for every deployment), and automations (updating images following a set of rules, creating PR environments, etc.).
  3. Open-Source Resource Drivers - enable the Platform API to put resources (such as Cluster, DBs, File Storage, or DNS) into the desired state and wire existing resources to applications. They return credentials back to the Platform API, which injects them as secrets into the containers at run-time. Drivers work on their own or execute existing IaC setups such as Terraform, Terragrunt, Cloud Formation, or Pulumi. Humanitec offers drivers that cover the major ecosystems, you can customize drivers and build your own.