Platform Engineering Tools in 2026
The tool categories a platform team assembles, what each one does, and where the lines fall between them
Spotify open-sourced Backstage in 2020 as the internal portal a few thousand of its services already ran through, and within a few years most large engineering orgs had either adopted it or built something like it. The pattern spread faster than the clarity did, so a team searching for "platform engineering tools" in 2026 gets back developer portals, service catalogs, maturity scorecards, workload orchestrators, and full backend platforms, all described in overlapping language and all claiming to solve the internal developer platform problem. The products differ less than the categories do, and picking the wrong category costs more than picking the wrong product inside the right one.
A platform team does not buy one tool, it assembles a set of them across a few layers: something to define infrastructure, something to ship it, something to give developers a way in, and in some cases something to run the backend itself. The categories below are those layers, with the tools that occupy each and where the boundaries blur.
The layers of a platform engineering stack: infrastructure-as-code defines resources, CI/CD ships them, orchestrators standardize provisioning, portals give developers a way in, and code-first backend platforms collapse several of these layers.
Developer portals and service catalogs
A developer portal answers "what services do we have, who owns them, and how do I get one." It reads from the systems you already run and puts a catalog, docs, and self-service actions in front of developers. It does not provision infrastructure and does not deploy; a self-service action is a button that triggers a workflow in your CI/CD.
Backstage is Spotify's open-source portal, now a CNCF project. The core ships a service catalog, a docs system (TechDocs), and software templates, and everything past that (Kubernetes status, cost dashboards, CI/CD views) comes through plugins. The plugin ecosystem is the largest of any portal, and with React developers and time you can build almost anything into it. The cost is that Backstage ships as a framework you assemble rather than a finished product you switch on. A production deployment runs to weeks of configuration, upgrades break plugin compatibility, and most orgs running it in production keep one to three engineers on it. Roadie sells managed Backstage at roughly $22 per developer per month for teams that want to skip that operational load.
Port takes the same idea and ships it as SaaS. Instead of writing plugins you configure a data model through a UI, connect integrations, and build self-service actions that fire GitHub Actions, Jenkins, or whatever pipeline you run. Time to a working portal is days rather than weeks, and its scorecards track engineering standards across services. It is free to about 15 users, then starts around $30 per seat per month. Like Backstage it sits on top of your stack, so its self-service actions are wrappers around CI/CD you already have to own, and the per-seat cost adds up at scale.
Cortex and OpsLevel are narrower on purpose. Both center on the service catalog, ownership, and maturity scorecards rather than general-purpose portal building. Cortex is strong at standards enforcement and initiatives, defining a campaign like "migrate every service to Node 22" and tracking adoption across teams, on enterprise pricing that is not public. OpsLevel leans on ownership and dependency mapping plus checks that gate CI/CD, so a service cannot reach production until it meets defined criteria; it prices per user. Neither provisions infrastructure or runs deploys, which is the shared trait of this whole category.
If you are specifically weighing portal options against each other or planning a migration off Backstage, the Backstage alternatives comparison goes deeper on that decision than this landscape does.
Platform orchestrators
An orchestrator sits deeper than a portal, in the provisioning path itself. Instead of showing information about infrastructure, it decides how a developer's request for a resource turns into real cloud resources, so developers describe what they need and platform engineers control how that need is met.
Humanitec is the best-known one. Developers declare requirements in a Score file (the open-source workload spec Humanitec authored), naming a database, a DNS record, a Redis cache, and Humanitec resolves those against resource definitions that platform engineers write. The separation lets you give developers self-service without giving them direct cloud access. It also adds an abstraction layer: the resource definitions are a new configuration surface to write and maintain, Humanitec orchestrates your existing Terraform or Helm rather than replacing it, and a failed deploy can be harder to debug because the abstraction hides what ran underneath.
Kratix approaches the same job as an open-source, Kubernetes-native framework. Platform teams publish "Promises" that package a capability (a Postgres instance, a full app scaffold) and its provisioning logic, and developers request them through the Kubernetes API. It suits teams that already run everything through Kubernetes and want their platform API to live there too, at the cost of the Kubernetes fluency the whole model assumes.
The orchestrator category earns its place when provisioning already works but every team does it differently, and the goal is one standard path rather than more visibility.
Infrastructure-as-code
Underneath the portals and orchestrators, something has to declare the cloud resources. That is infrastructure-as-code, and for most platform teams it is Terraform or its fork OpenTofu, with Pulumi as the main alternative for teams that would rather write resource definitions in TypeScript, Go, or Python than in HCL, a choice broken down in Terraform vs Pulumi. Cloud-specific options like AWS CDK cover the same ground within one provider.
This layer is where the real provisioning logic lives, and where most of the platform team's ongoing work accumulates. Portals trigger it, orchestrators wrap it, and neither removes it. A team that adopts Port or Humanitec still writes and maintains the Terraform those tools drive, which is worth keeping in view when the portal demo makes provisioning look solved. The cloud infrastructure automation tools landscape breaks down the IaC options in more depth.
CI/CD
The layer that turns a commit into a running deploy is CI/CD, and it is usually already in place before a platform team forms: GitHub Actions, GitLab CI, Jenkins, or a Kubernetes-native tool like Argo CD or Flux for GitOps delivery. Platform engineering tooling mostly plugs into CI/CD rather than replacing it. A portal's self-service action ends in a pipeline run, an OpsLevel check gates one, and an orchestrator's provisioning happens through one. When a portal or orchestrator promises "self-service deploys," the deploys still run here, which is why an evaluation of any tool in the layers above has to account for the CI/CD it assumes you already own.
Code-first backend platforms
The categories above share an assumption: the application and the infrastructure are separate things, connected by config that someone writes and maintains. A code-first backend platform drops that assumption. You declare infrastructure as typed objects inside the application code, and the platform derives the provisioning, the service catalog, and the wiring from what you wrote, so several of the layers above collapse into one.
Encore is the main open-source example. You write the backend in TypeScript or Go and declare a database, a Pub/Sub topic, a cron job, or a secret as an object in the code. Encore reads those declarations, provisions the resources into your own AWS or GCP account, and generates the CI/CD, preview environments, service catalog, architecture diagram, and distributed tracing from the same source. Services call each other as type-checked function calls through generated clients, so a multi-service backend reads like one codebase.
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
// Declaring the database provisions it: Postgres locally,
// RDS or Cloud SQL in your own AWS or GCP account.
const db = new SQLDatabase("orders", { migrations: "./migrations" });
export const get = api(
{ method: "GET", path: "/orders/:id", expose: true },
async ({ id }: { id: string }): Promise<Order> => {
return await db.queryRow`SELECT * FROM orders WHERE id = ${id}`;
},
);
The category is a different bet from portals and orchestrators. Backstage or Port sits on top of whatever stack you have and stays framework-agnostic; a code-first platform asks you to write the backend its way, which is real commitment on an existing Express or Fastify codebase, and it is opinionated about how services and infrastructure are structured. In return there is no separate portal to run, no Terraform for the common cases, and no observability stack to assemble, because those come from the code. The tradeoff between this and a plain PaaS is covered in internal developer platform vs PaaS.
Where Encore fits
Encore is a code-first backend platform built around infrastructure automation, which is a different category from the portals and orchestrators most "platform engineering tools" lists lead with. A developer portal like Backstage, Port, or Cortex reads from your existing infrastructure and gives developers a catalog and self-service on top of it, and it stays agnostic about how that infrastructure is built. An orchestrator like Humanitec or Kratix standardizes the provisioning path without replacing the underlying IaC. Encore instead derives the infrastructure from the application code: you declare a database or a queue as a typed object, and Encore provisions it into your own AWS or GCP account, wires service-to-service calls, and generates the CI/CD, environments, service catalog, and tracing from the same source.
That makes it a fit for a team that would otherwise assemble the IaC, CI/CD, and observability layers by hand, and less of a fit where the requirement is a catalog over a large existing estate of services in many languages, which is what the portal tools are built for. Because the infrastructure is declared in application code rather than in Terraform and Helm, an AI coding agent working in an Encore codebase writes ordinary typed code instead of infrastructure config a human has to review before it reaches production. For teams that already have Terraform they want to keep, Encore exposes its provisioned resources to existing state through a Terraform provider.
Related reading
Frequently asked questions
What are platform engineering tools?
Platform engineering tools are the software a platform team assembles to give developers a paved path to production. They fall into a few categories that do different jobs: developer portals and service catalogs that give visibility into an existing stack, orchestrators that standardize how infrastructure gets provisioned, infrastructure-as-code for defining the resources themselves, CI/CD for shipping, and code-first backend platforms that generate much of the plumbing from the application code.
Is Backstage a platform engineering tool?
Yes, Backstage is one of the most widely adopted platform engineering tools, but it sits in a specific category. It is a developer portal framework: a service catalog, docs, and software templates with a plugin system for wiring in the rest of your stack. It shows information about your infrastructure and gives developers a place to find things, and it does not provision infrastructure or run deployments on its own.
What is the difference between a developer portal and a platform orchestrator?
A developer portal is a read-and-launch layer: a catalog of services, docs, and self-service actions that trigger workflows in tools you already run. An orchestrator sits deeper in the provisioning path and decides how a developer's request for a database or cache maps to real cloud resources. Portals like Backstage and Port make an existing stack navigable; orchestrators like Humanitec and Kratix standardize how that stack gets built.
Do I need Terraform if I have a developer portal?
Usually yes. Portals such as Backstage, Port, and Cortex give visibility and self-service on top of infrastructure, and they do not create that infrastructure themselves. A self-service action in a portal is a wrapper that triggers your existing CI/CD, which in turn runs Terraform, Pulumi, or a similar tool. If those pipelines do not exist, the portal has nothing to trigger.
How do platform engineering tools work with AI coding agents?
It depends on what the agent has to produce. Portals and orchestrators still expect someone to write Terraform, Helm, and pipeline config, so an agent working there generates infrastructure code that a human has to review carefully before it touches production. Code-first backend platforms move the infrastructure declarations into the application code, so an agent writes ordinary typed code and the platform derives the provisioning from it.
How do I choose between a portal, an orchestrator, and a platform?
Start from what you are missing. If your infrastructure and deploys work but developers cannot find anything, you need a portal. If provisioning works but every team does it differently, you need an orchestrator. If you do not have a mature toolchain and do not want to build one, a code-first backend platform gives you provisioning, CI/CD, environments, and a catalog together, at the cost of adopting its framework.
Ship without waiting on Terraform
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.
