20 Platform Engineering Tools to Use in 2026

Platform engineering is the practice of building internal tools so developers don’t have to file a ticket for routine infrastructure work. The platform team designs self-service actions, paves the road for common requests, and keeps security and compliance enforced in the background.

The deliverable is an internal developer platform (IDP). A portal-fronted layer that unifies the software delivery lifecycle and gives developers a clear way to find and use the services available to them. Behind that portal sit the tools that do the actual work, including CI/CD, IaC, observability, secret management, policy, and the control plane that ties them together.

Most teams build their IDP by combining several tools rather than buying one finished product. In this article, we cover 20 of the ones that show up most often in modern platform-engineering stacks, along with what each is genuinely good for and where it falls short.

What we will cover:

1. What problem does platform engineering actually solve?
2. How to evaluate a platform engineering tool
3. Top 20 platform engineering tools

Platform engineering is an emerging discipline that focuses on the use of centralized tooling to implement DevOps best practices. It promotes developer autonomy by creating self-service actions maintained by the platform team that developers use to simplify their workflows.

Platform engineering teams need to integrate various tools to build an effective platform. They’re responsible for evaluating the DevOps landscape, identifying facilities that the platform should provide to developers, and then implementing solutions that deliver the required functionality. 

The platform’s scope should span the entire DevOps lifecycle, from infrastructure provisioning and configuration through to app deployment, monitoring, and infrastructure management.

Platform engineering is a rapidly growing space, and there are plenty of powerful tools to choose from. This can make it challenging to decide which options best fit your workflows, but a good way to get started is to assess the following key characteristics:

• Integrates with the tools you already run: An IDP only works if it can talk to your VCS, CI, cloud accounts, secret store, and ticketing system. Stable APIs, webhooks, and a credible plugin ecosystem matter more than the marketing surface area.
• Simple user experience: Internal developer platforms are designed to simplify and accelerate DevOps workflows and enable developer self-service. To achieve this, tools need to offer a clear UX that’s approachable for developers and straightforward for the platform team to manage.
• Easily extensible by platform teams: Tools that can be extended with new capabilities add flexibility to your workflows and can help prevent the risks of vendor lock-in and data siloing.
• Clear security and compliance controls: Choosing tools with built-in security and compliance management features helps you protect your infrastructure and reduce your risk exposure.

It’s also important to check that your chosen tools will actually contribute to your platform engineering aims. Set clear success criteria so you know whether your investment is paying off, such as by measuring changes to deployment frequency, change lead times, and developer satisfaction or retention rates. Tools that aren’t specifically designed to form part of an IDP may not produce the positive effects you expected.

Here’s our guide to 20 of the top platform engineering tools to know right now. This list is a selection of our favorites and popular or influential choices from around the web, but remember, there are many more options out there if you don’t find what you’re looking for.

The best platform engineering tools include:

1. Backstage
2. Kubernetes
3. Crossplane
4. Terraform/OpenTofu
5. Spacelift
6. Humanitec
7. Port
8. Kubiya
9. Qovery
10. Ona
11. Kratix
12. OpsLevel
13. ArgoCD
14. BunnyShell
15. Jenkins
16. Rancher
17. Cortex
18. Prometheus
19. Logstash
20. Argo Workflows

Where do these tools fit in an IDP stack?

Most platform engineering articles hand you 20 tools and let you figure out which one solves which problem. The reality is that an IDP is a layered stack, and each tool slots into one of about six layers. Knowing the layer tells you what the tool replaces, what it complements, and whether you actually need it yet.

Layer	What it does	Tools in this article
Developer portal and interfaces	The interfaces developers use to find and request platform services	Backstage, Port, OpsLevel, Cortex, Kubiya
Platform orchestration	Provisions and governs cloud resources behind the portal	Spacelift, Crossplane, Kratix, Humanitec
Infrastructure as code	Describes infrastructure as code	Terraform / OpenTofu
Container orchestration	Runs the workloads	Kubernetes, Rancher
CI/CD, GitOps, and environments	Runs the pipelines, ships changes, and spins up environments	Jenkins, Argo Workflows, ArgoCD, Qovery, BunnyShell, Ona (ex-Gitpod)
Observability	Tells you what just broke	Prometheus, Logstash

A workable starter IDP usually needs at least one tool from platform orchestration, IaC, container orchestration, and a delivery layer. Everything else is additive. If you’re not sure where to start, pick the portal layer last. A great portal in front of a half-built stack is mostly an advertising surface for tickets you can’t yet automate.

Backstage is a popular framework for building self-service portals that form the basis of your IDP. It lets you create a service catalog that developers can independently discover and use via a single centralized interface.

Originally developed by Spotify, Backstage is an open-source solution with deep extensibility. You can easily write new components, include them in your service catalog, and add community plugins to integrate Backstage with other systems. However, the initial setup is relatively complex as you need to deploy and configure the framework yourself.

Most teams underestimate the staffing cost of running Backstage in production. A dedicated owner is usually the deciding factor between Backstage and a managed portal like Port or Cortex.

• License: Open-source
• Website: https://backstage.io 

• Adoption signals:  ~34k GitHub stars, ~105 releases in the last 12 months. Donated by Spotify to the CNCF in 2020; now an Incubation project.

When Backstage makes sense

• You have at least one engineer to dedicate to running the framework full-time, and a 6–12 month horizon to build out plugins.
• Your service catalog and tooling are heterogeneous enough that off-the-shelf portals don’t cover the integrations you need.
• You want full control of the UX and are willing to write TypeScript to get it.

When Backstage is not a great fit

• You have fewer than 50 engineers. The engineering cost of running Backstage will exceed what Port or Cortex would charge.
• Your platform team doesn’t have frontend or Node.js skills on hand.
• You need a working portal in weeks, not quarters.

Kubernetes is the most popular container orchestration platform. It allows you to deploy, scale, and operate containerized apps in production with dependable fault tolerance.

Kubernetes is the ideal platform for hosting an IDP. It lets you individually scale your platform’s components and manage service discovery and load balancing for the entire fleet. A Kubernetes cluster can also be used to operate your app environments with features including RBAC, multi-tenant namespaces, and policy-driven security controls making it possible to safely enable developer access.

Inside an IDP, Kubernetes rarely shows up to developers directly. It’s the substrate the platform team builds on. Backstage, Crossplane, or Argo Workflows are usually what developers actually interact with.

• License: Open-source
• Website: https://kubernetes.io 
• Use case example: How to deploy Kubernetes resources with Terraform
• Kubernetes G2 ratings and reviews: 4.6/5 (157 reviews)
• Adoption signals:  ~122k GitHub stars, ~60 releases in the last 12 months

When Kubernetes makes sense

• You’re running enough containerized workloads that scheduling, scaling, and self-healing pay back the operational cost.
• You want a substrate that the rest of your IDP (Crossplane, ArgoCD, Backstage) can build on top of.
• Your platform team has, or is willing to invest in, real Kubernetes operational expertise.

When Kubernetes is not a great fit

• You have a small number of services and a managed PaaS would cover you.
• Most of your workloads are stateful databases or long-running VMs where the orchestration benefit is limited.
• You don’t have the headcount to run it safely in production. A misconfigured cluster is worse than no cluster.

Crossplane is an open-source CNCF Graduated framework for creating cloud-native platform control planes. It allows you to orchestrate your apps and their infrastructure using a declarative API and configurable frontend without having to write complex custom code.

Once installed in a Kubernetes cluster, Crossplane provides a set of custom resource definitions for managing infrastructure resources in your other cloud accounts and services. This means you can use the familiar Kubernetes experience to control components outside your cluster, simplifying the platform management experience.

Crossplane suits teams who already think in Kubernetes resources and want one control plane for applications and infrastructure. Teams further from Kubernetes usually find Terraform or OpenTofu a gentler path.

• License: Open-source
• Website: https://www.crossplane.io 
• Adoption signals: ~3,000 contributors from 450+ orgs, CNCF Graduated (October 2025). v2.0 added support for application control planes.
• Use case example: Crossplane vs Terraform – IaC tools comparison

When Crossplane makes sense

• Your team already thinks in Kubernetes resources and wants one declarative model for both apps and infrastructure.
• You want to expose cloud resources to developers as Kubernetes CRDs they can request through kubectl or the API.
• You’re building a control plane and want CNCF-graduated tooling underneath it.

When Crossplane is not a great fit

• Your team is not Kubernetes-native. The learning curve is steep and Terraform or OpenTofu will be a gentler path.
• You need broad provider coverage for niche or legacy systems. Terraform’s provider ecosystem is still larger.
• You don’t want the cluster itself to become a single point of failure for infrastructure provisioning.

HashiCorp Terraform and open-source fork OpenTofu represent the leading approach to Infrastructure-as-Code (IaC). Using a simple declarative config language, you can provision and manage infrastructure resources across all major cloud providers, hosting platforms, and container orchestration solutions. 

Core HCL syntax is still cross-compatible and providers work on both, but the feature sets are diverging. OpenTofu has added native state encryption and early variable evaluation that Terraform does not. 

HashiCorp completed its $6.4B acquisition by IBM in February 2025, so Terraform’s roadmap is now set inside IBM, while OpenTofu is governed by the Linux Foundation.

• License: Terraform BUSL 1.1 / OpenTofu MPL 2.0
• Website: https://www.terraform.io 
• Use case example: Terraform on AWS – deploying AWS resources & Getting started with OpenTofu
• Terraform G2 ratings and reviews: 4.7/5 (96 reviews)
• OpenTofu adoption signals: ~30k GitHub stars, ~36 releases in the last 12 months, CNCF Sandbox project since April 2025.

When Terraform / OpenTofu makes sense

• You want declarative infrastructure with the largest provider ecosystem available (3,000+ providers).
• You need a tool the broader market knows. Hiring for Terraform skills is easier than for any alternative.
• You want a clear path between experimentation and production through the same configuration language.

When Terraform / OpenTofu is not a great fit

• Your team would rather express infrastructure in a general-purpose language (Python, TypeScript, Go). Pulumi or CDK is a better fit there.
• You’re a small team that only manages one or two cloud accounts and the workflow overhead doesn’t pay back.
• You’re a vendor offering Terraform-as-a-service and the BSL terms create commercial risk. Evaluate OpenTofu instead.

Spacelift is an infrastructure orchestration platform that gives platform teams a single control plane for Terraform, OpenTofu, Pulumi, Terragrunt, CloudFormation, Kubernetes, and Ansible, with policy as code, drift detection, state management, and an audit trail built in.

If you’re building an IDP, the infrastructure layer is where most projects stall. Too many IaC tools, no shared workflow, no way to give developers self-service without giving up governance. Spacelift addresses that directly.

Developers self-serve through Blueprints, Templates, or your existing portal. Spacelift Intent lets them describe infrastructure in natural language, governed by your policies. Spacelift Intelligence helps the platform team design stacks, troubleshoot runs, and answer infrastructure questions directly inside the product.

• Pricing: Free tier for individuals and small teams. Starter from $399/month, Business and Enterprise via quote.
• Website: https://spacelift.io
• Use case example: How to improve your infrastructure orchestration with Spacelift
• Spacelift G2 ratings and reviews: 4.9/5 (11 reviews)

When Spacelift makes sense

• You run more than one IaC tool and want one control plane for all of them.
• You need developer self-service backed by policy as code, not just guardrails on paper.
• You want drift detection, governed AI-driven provisioning (Intent), and an Infrastructure Assistant (Intelligence) in the same product.

When Spacelift is not a great fit

• You run a single IaC tool on a single cloud and a managed offering from that vendor already covers you.
• You want a pure Kubernetes-native control plane where every piece of infrastructure is a Kubernetes CRD reconciled in-cluster. Crossplane fits that pattern more directly than a SaaS or self-hosted orchestrator.
• You haven’t yet decided on an IaC strategy. Pick one (or two) first, then evaluate orchestration.

Humanitec is a SaaS platform orchestrator widely used to build internal developer platforms at enterprise scale. The service includes a full set of capabilities for operating IDPs, including a graph-based backend that connects your tools and an approachable developer-facing portal interface that enables access to your service catalog. 

Humanitec also includes a strong suite of security, governance, cost control, and reporting features, ensuring platform engineers can maintain tight control of developer activity.

• Pricing: Three tiers (small teams, growing teams, large enterprise); contact sales for current pricing. Free 2-week MVP Program available.
• Website: https://humanitec.com 

When Humanitec makes sense

• You want a platform orchestrator that’s already opinionated, with Score as the workload spec and Portal as the UI, rather than building those layers yourself.
• You’re a large enterprise with multiple application teams and need standardization across them without writing a custom abstraction.
• You’re committed to the Score open-source workload spec as your developer-facing contract.

When Humanitec is not a great fit

• You’re a smaller team. The product is priced and shaped for mid-to-large engineering organizations.
• You want maximum flexibility in how developers interact with the platform. Humanitec’s opinions about Score and the deployment workflow are the point of the product.
• You already have a custom orchestration layer you’re happy with.

Port is an internal developer portal service that provides a simple interface for hosting self-service actions, automations, dashboards, and forms. Platform teams can use Port to grant developers easy access to prebuilt automated workflows with everything available in one place.

Port is an extensible platform that includes a wide selection of integrations with other DevOps solutions. It also features built-in reporting and analysis capabilities that provide visibility into service adoption and utilization, allowing platform engineers to understand which services are benefiting developers the most.

• Pricing: Free tier for up to 15 seats. Basic starts at $30/seat/month (up to 50 seats), Standard at $40/seat/month (up to 200 seats), Enterprise via quote.
• Website: https://www.getport.io 
• Port G2 ratings and reviews: 4.4/5 (40 reviews)

When Port makes sense

• You want a portal that’s working in days, not months, with a generous free tier for small teams.
• Your platform team wants a no-code or low-code path to building self-service actions and dashboards.
• You want managed software with a strong integration catalog rather than something you have to host and patch.

When Port is not a great fit

• You need on-premises hosting with no SaaS dependency.
• You want unlimited custom frontend control. Backstage’s React surface gives you more freedom.
• Your services and ownership data live in tools Port doesn’t yet integrate with and you don’t want to build the integrations yourself.

Kubiya is an agentic engineering platform that lets developers and platform teams delegate routine and complex engineering tasks to AI agents via natural language. Agents plan, build, and execute work across your existing tech stack — turning business objectives into engineering outcomes inside policy boundaries.

Kubiya includes built-in audit logs and security policies that help ensure continual compliance. It can be deployed to your own Kubernetes cluster, giving you full control over your platform and environments.

• Pricing: Yearly AEH (Agentic Engineering Hours) retainer; Professional and Enterprise tiers, no public pricing. 2-month pilot available.
• Website: https://www.kubiya.ai 

When Kubiya makes sense

• You want developers to interact with infrastructure and platform services through chat and natural language rather than a portal.
• You’re building agentic workflows where an AI teammate handles routine tasks (provisioning, runbook execution) inside policy boundaries.
• You’re willing to bet on AI-first platform interfaces becoming the dominant pattern.

When Kubiya is not a great fit

• You haven’t yet automated the underlying workflows. A natural-language layer over manual processes is mostly marketing.
• Your security model can’t tolerate an agent taking action on your infrastructure without a human in the loop for every step.
• Your team is small and the yearly-retainer commitment is hard to justify before you’ve validated the workflows you’d hand to an agent. The 2-month pilot is the right entry point for that case, but you’ll still need a budget conversation.

Qovery is a DevOps automation platform designed to facilitate self-service developer access to environments. Devs can easily start deployments, create clones of existing environments, and interact with resources such as databases and API gateways.

Qovery supports a full range of interface types, including a web UI, CLI, API, and programming language client libraries, plus over 100 native integrations. It’s a good choice when you’re Kubernetes-centric and want to manage all developer tasks using one platform.

• Pricing: Free Starter tier. Team from $899/month, Business from $1,999/month (flat-rate per org). Enterprise custom.
• Website: https://www.qovery.com 
• Qovery G2 ratings and reviews: 4.7/5 (70 reviews)

When Qovery makes sense

• You’re Kubernetes-centric and want developers to self-serve environments, databases, and deployments without learning kubectl.
• You want preview environments tied to pull requests as a first-class workflow.
• You want one platform that covers deployment, environment cloning, and resource provisioning.

When Qovery is not a great fit

• You’re not running on Kubernetes and don’t plan to.
• You have a mature in-house platform and Qovery’s opinions about how deployments work will conflict with yours.
• You’re a small team or solo developer. The flat-rate Team plan starts at $899/month, which is a hard fit until you have a handful of services and developers to amortize it across.

Ona is the rebrand of Gitpod, which shipped in September 2025 alongside a pivot from cloud development environments to AI engineering agents. If you remember Gitpod as the one-click in-browser dev environment, the product still exists in that shape, but it’s now one of three components under a broader “AI mission control” pitch rather than the main thing the company sells.

For an IDP, Ona’s relevance is twofold: the underlying environments (API-first, declarative via devcontainer.json and automations.yml) still solve the original Gitpod problem of new-joiner setup time, and the agent layer can be plugged into your portal as a self-service option for routine engineering tasks.

The trade-off worth knowing about: the managed pay-as-you-go SaaS that many Gitpod users relied on shut down on 15 October 2025. Gitpod Flex, the self-hosted replacement, runs in your own cloud account and was AWS-first at launch.

• License: Commercial; the original Gitpod open-source components remain under the gitpod-io GitHub org
• Website: https://ona.com
• Pricing: Free tier (40 OCUs, one-time); Core from $10 per 40 OCUs (80–2,200 OCUs/month); Enterprise custom. OCUs (Ona Compute Units) cover both environment runtime and agent usage.

When Ona makes sense

• New-joiner setup time is your bottleneck and you want cloud development environments defined in devcontainer.json.
• You want to plug AI engineering agents into your portal as a self-service option for routine tasks.
• You can run Ona Flex in your own AWS account and prefer that over multi-tenant SaaS.

When Ona is not a great fit

• You relied on the Gitpod Classic PAYG SaaS that shut down on October 15, 2025, and you don’t want to migrate.
• Your team works mostly offline or on latency-sensitive local development.
• You don’t yet need an AI agent layer and just want plain cloud IDEs. The product is now optimized around agents.

Kratix is an open-source framework specifically designed to fulfill the requirements of platform engineers creating IDPs. It has a composable architecture that simplifies the process of exposing self-service access to developer resources. Kratix also automates lifecycle management tasks for platform components and includes a pipeline-driven workflow system.

Kratix forms the foundation of your IDP by letting you easily implement the internal processes that developers interact with. Because it’s a framework, it requires significant customization to get started, but offers a flexible foundation for building custom platforms. You can connect popular developer portal solutions such as Backstage and Port to expose your Kratix services to developers.

• License: Open-source
• Website: https://www.kratix.io 

• Adoption signals: ~750 GitHub stars, multiple releases in the last 12 months. Maintained by Syntasso

When Kratix makes sense

• You want to expose platform capabilities as Kubernetes APIs (“Promises”) that developers consume the same way they consume any other CRD.
• You’re comfortable customizing a framework rather than buying a finished product.
• You want a clear separation of concerns between application teams, platform teams, and infrastructure teams.

When Kratix is not a great fit

• You don’t have the engineering bandwidth to build and maintain the Promises themselves.
• You’re not running on Kubernetes.
• You want something with broad market recognition. Kratix is real and growing but the community is smaller than Backstage or Port.

OpsLevel is an internal developer portal solution that allows you to connect your other tools to form a cohesive service catalog. It enables self-service access to standardized resources based on templates and one-click action buttons. 

OpsLevel minimizes setup time by automatically detecting the components used in your existing tech stack, minimizing the amount of manual work needed to publish your services.

• Pricing: Custom pricing plans
• Website: https://www.opslevel.com 
• OpsLevel G2 ratings and reviews: 4.3/5 (10 reviews)

When OpsLevel makes sense

• You want a portal that auto-detects services from your existing stack and gets you to a working catalog quickly.
• Service ownership, maturity scorecards, and standards enforcement are higher priorities than custom self-service actions.
• You want a managed product and don’t want to host or maintain it.

When OpsLevel is not a great fit

• You need extensive custom UI. The product is opinionated about catalog and scorecard structure.
• You want public, transparent pricing. OpsLevel is custom-quote only.
• Your platform team already has a working internal catalog and the migration cost won’t pay back.

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. It treats a Git repository as the source of truth for cluster state and continuously reconciles what’s running against what’s declared. 

Most platform teams pair it with Argo Workflows for CI and use ArgoCD itself for the CD half. What developers actually see is the web UI: application topology, the diff between Git and the live cluster, sync status, and a one-click rollback. 

Inside an IDP, ArgoCD is what turns “merge a pull request” into “this is now running in staging” without anyone touching kubectl. ApplicationSets make it practical to roll the same workload across many clusters from one definition.

• License: Open-source (Apache 2.0)
• Website: https://argo-cd.readthedocs.io
• Use case example: How to Deploy ArgoCD with Terraform on EKS: A GitOps Tutorial
• Adoption signals: ~18k GitHub stars, quarterly minor releases. CNCF Graduated since  December 2022 alongside Argo Workflows, Rollouts, and Events.

When ArgoCD makes sense

• You’re on Kubernetes and want Git to be the source of truth for what’s in the cluster.
• You want a visual UI for developers to inspect deployments, diffs, and sync status without giving them kubectl access.
• You want CNCF Graduated tooling with a large ecosystem (Rollouts, Image Updater, ApplicationSets) and a clear governance model.

When ArgoCD is not a great fit

• You’re not on Kubernetes.
• You’d rather treat each controller as a separate piece. FluxCD’s modular toolkit fits that better than ArgoCD’s centralized model.
• You don’t want to run and upgrade another stateful controller in every cluster.

Bunnyshell is a platform for automating the development process by allowing devs to spin up new preconfigured cloud environments on-demand. It also simplifies the process of creating ephemeral test environments, including integration with Git providers to preview changes before they’re merged in a pull request.

Bunnyshell tracks the costs associated with your environments and produces metrics, audit logs, and reports that reveal engineering performance. The platform is available in both cloud-hosted and on-premises flavors.

• Pricing: Free Developer plan; Pay-as-you-go and Enterprise plans starting at $0.007 per minute per environment
• Website: https://www.bunnyshell.com 
• Bunnyshell G2 ratings and reviews: 4.5/5 (2 reviews)

When Bunnyshell makes sense

• Preview environments per pull request are a workflow your team would actually use.
• You want per-environment cost tracking and per-minute pricing rather than seat-based.
• You need both cloud-hosted and on-premises deployment options.

When Bunnyshell is not a great fit

• You don’t need ephemeral environments. Static dev/staging covers you.
• You want a large community and many third-party reviews to lean on. Public review volume is still thin.
• Your environments are large and long-running, where per-minute pricing becomes expensive.

Jenkins is the long-standing automation server most CI/CD pipelines were built on. Its distributed controller-agent model and ~1,800 community plugins still cover almost any integration a platform team needs.

Jenkins gives platform teams the ability to build complex pipelines using a simple configuration language. Your IDP could use Jenkins to implement the workflows that devs access through your portal, such as an action that starts a Jenkins pipeline to test, build, and release code changes.

For a brand new IDP, most teams now reach for GitHub Actions, GitLab CI, or Argo Workflows first. Jenkins still earns its place when you’re modernizing a platform that already runs on it.

• License: Open-source
• Website: https://www.jenkins.io 
• Use case example: How to Manage Terraform Workflows with Jenkins
• Jenkins G2 ratings and reviews: 4.4/5 (546 reviews)
• Adoption signals: ~25k GitHub stars, ~79 releases in the last 12 months

When Jenkins makes sense

• You already run Jenkins and the modernization cost of migrating away exceeds the cost of keeping it.
• Your CI/CD needs are unusual and the ~1,800 plugin ecosystem still covers an integration nothing else does.
• You need full self-hosted control with no SaaS dependency.

When Jenkins is not a great fit

• You’re starting fresh. GitHub Actions, GitLab CI, or Argo Workflows give you most of what Jenkins does without the maintenance burden.
• Your team doesn’t have the operational appetite to keep a Jenkins controller and its plugins patched.
• You’re trying to move toward GitOps-native pipelines. Jenkins predates that pattern and fits it awkwardly.

Rancher is a Kubernetes management platform for interacting with your clusters and their workloads. It helps you implement a Kubernetes-centric IDP with fewer administration overheads.

You can use Rancher to manage your cluster fleet and grant developers safe access to deploy apps, test changes, and access production environments. Rancher supports full multi-cluster management with centralized user identities and security policies, making it much easier to ensure all clusters are configured correctly.

• License: Open-source with Prime and Prime Hosted paid plans
• Website: https://www.rancher.com 
• Adoption signals: ~26k GitHub stars, ~280 releases in the last 12 months

When Rancher makes sense

• You run more than a couple of Kubernetes clusters and want one place to manage RBAC, policies, and upgrades across all of them.
• You want a centralized UI for developers that doesn’t require giving them direct cluster access.
• You need on-premises or hybrid Kubernetes management, not just one cloud provider’s managed Kubernetes.

When Rancher is not a great fit

• You run a single managed cluster (EKS, GKE, AKS) and the cloud provider’s tooling covers you.
• You don’t want another SUSE/Rancher-shaped layer between your team and the cluster.
• Your platform is already standardized on a different multi-cluster management approach (Argo CD ApplicationSets, Cluster API, fleet management in your own tooling).

Cortex is an internal developer portal that gives developers a complete view of all the resources relevant to them. The Cortex dashboard includes a service catalog, one-click action items, and visibility into work assigned to each developer, such as GitHub issues and pull requests.

Cortex provides platform engineers with comprehensive visibility into platform utilization and developer performance. You can configure visual scorecards to track alignment with your KPIs and identify potential risks. Detailed reports let you aggregate data from different sources, then track trends and drill down to investigate root causes.

• Pricing: Custom pricing; no public tier
• Website: https://www.cortex.io

When Cortex makes sense

• You want a managed internal developer portal with strong AI-driven analytics and scorecards out of the box.
• Service ownership, production readiness, and standards enforcement matter more to you than building custom self-service actions.
• Your engineering leadership wants visibility into platform metrics and KPIs.

When Cortex is not a great fit

• You want public pricing before talking to sales.
• You need extensive custom UI or self-hosted deployment.
• You’re a small team where the operational metrics Cortex surfaces don’t yet have enough data to be useful.

Prometheus is one of the most popular observability platforms. It’s a distributed time-series database for storing and analyzing metrics data. It includes a built-in query language (PromQL) and supports Grafana integration so you can visualize your data on graphical dashboards.

Prometheus metrics exports are supported by many popular platform engineering tools and services. Integrating Prometheus with your IDP allows you to easily collect data from your stack so you can monitor operations more effectively. You could also use Prometheus to instrument the services you create within your IDP, providing insights into developer adoption and utilization rates.

• License: Open-source
• Website: https://prometheus.io 
• Use case example: Prometheus Monitoring for Kubernetes Cluster
• Prometheus G2 ratings and reviews: 4.5/5 (61 reviews)
• Adoption signals: ~64k GitHub stars, ~32 releases in the last 12 months. Graduated CNCF project since 2018.

When Prometheus makes sense

• You want the de facto open-source metrics standard, with broad exporter and integration coverage across the cloud native ecosystem.
• You’re already on Kubernetes and want PromQL-based alerting.
• You want a graduated, vendor-neutral CNCF project that won’t change ownership.

When Prometheus is not a great fit

• You need long-term metric retention without operating Thanos, Cortex, or Mimir on top.
• You want logs and traces in the same product. Prometheus is metrics-only.
• You don’t have the operational capacity to run a Prometheus stack and a managed observability vendor is cheaper than the engineering time.

Logstash, part of the Elastic Stack alongside Elasticsearch and Kibana, is a data ingest and transformation pipeline that’s commonly used to process log files. It’s another component that’s worth including in your IDP so developers and platform teams can efficiently work with the logs that are written by your apps, services, and infrastructure components, enabling more efficient debugging of reported problems.

• License: Open-source
• Website: https://www.elastic.co/logstash 
• Adoption signals: ~15k GitHub stars, ~62 releases in the last 12 months

When Logstash makes sense

• You’re already on the Elastic Stack and need a flexible ingest and transformation layer in front of Elasticsearch.
• Your log shapes are messy and you need filtering, parsing, and enrichment before storage.
• You want a self-hosted pipeline rather than handing logs to a SaaS vendor.

When Logstash is not a great fit

• You’re starting fresh in 2026. Vector, Fluent Bit, and the OpenTelemetry Collector are lighter and have better Kubernetes ergonomics.
• You don’t need transformation. A direct shipper into your log backend is simpler.
• You’re trying to consolidate metrics, logs, and traces. Logstash is logs-only.

Argo Workflows is a workflow execution engine that lets you run parallel jobs and processes inside a Kubernetes cluster. You can use it to implement complex IDP workflows that consist of multiple steps, where the output of one job becomes the input to the next. Workflows also support dependency modeling as a directed acyclic dependency (DAG) to optimize when jobs start.

Using Argo Workflows makes it easier to automate development processes such as batch data processing, machine learning model training, and multi-step infrastructure provisioning sequences. You can run workflows on a schedule or integrate Argo with a developer portal solution to let engineers trigger workflows on-demand.

• License: Open-source
• Website: https://argoproj.github.io/workflows 
• Use case example: Argo Workflows Tutorial

• Adoption signals: ~17k GitHub stars, ~42 releases in the last 12 months. CNCF Graduated alongside Argo CD, Rollouts, and Events.

When Argo Workflows makes sense

• You’re already running Kubernetes and want a workflow engine that lives natively in the cluster.
• Your workflows are DAGs with parallel steps (data pipelines, ML training, multi-step infrastructure provisioning).
• You want a CNCF-graduated project with a clear governance model.

When Argo Workflows is not a great fit

• You’re not on Kubernetes.
• Your workflows are short, stateless, and don’t need DAG modeling. A simpler CI tool covers you.
• You want a managed product. Argo Workflows is self-hosted and you’ll need to operate it.

Platform engineering is rarely about picking the single best tool. It’s about combining a small number of them into a coherent IDP that fits your team’s existing skills and your organization’s compliance reality.

A typical stack settles on four to six tools covering a developer portal, an IaC tool plus an orchestration layer behind it, a CI/CD engine, environment provisioning, and observability. The names you choose matter less than how cleanly they integrate and how cheaply they’re maintained over five years.

Looking for the orchestration layer? Spacelift gives you a single control plane for Terraform, OpenTofu, Pulumi, Kubernetes, and Ansible, with policy as code, drift detection, and self-service Blueprints built in. Try it for free, or book a demo with one of our engineers.