Platform Engineering Tools: A Buyer's Guide to the Internal Developer Platform Stack

No single tool builds an internal developer platform. A real platform engineering stack brings together tools across five categories: a developer portal, platform orchestration and automation, infrastructure as code, CI/CD, and observability. Most "best platform engineering tools" lists skip that structure and publish a flat ranking instead, which answers a different question than the one platform teams actually have.

The question that matters is which category needs a decision right now, and which ones your team already has covered. For many platform teams, observability is already in place: monitoring and telemetry often predate a formal internal developer platform. That makes observability a useful connective layer as you add automation, developer self-service, and other platform capabilities. This guide breaks down all five categories and how they fit together.

The platform engineering toolchain, by category

Each category of platform engineering tools below solves a different job. The tools inside it compete on how well they solve that specific job, not on which one is "best" overall.

Developer portals and service catalogs

The job: give developers one place to find services, ownership, docs, and self-service actions instead of asking around in Slack. A developer portal becomes the front door to the internal developer platform (IDP). Get this wrong and the platform becomes one more tab nobody opens.

• Backstage: An open-source framework Spotify built and donated to the CNCF, it's best for teams with a dedicated platform team willing to build and maintain their own internal developer portal. The tradeoff is maintenance: catalogs can depend on manually maintained YAML, while plugin quality varies across the ecosystem.

• Port: Built as a commercial alternative to building on Backstage, it's best for teams that want a developer portal and service catalog without building it themselves. Port is increasingly focused on AI-agent governance, so confirm that direction fits if a straightforward service catalog is what you need.
• OpsLevel: With maturity scorecards and a broad integration library, this commercial catalog is best for teams that want service standards enforced automatically. Confirm how pricing scales as your team grows.
• Cortex: Built around a "Context Graph," scorecards, and golden paths, the commercial portal is best for organizations enforcing production-readiness standards across many teams. Its published productivity numbers are vendor-reported rather than independently audited, so treat them accordingly.

Platform orchestration

The job: turn infrastructure decisions into governed, self-service actions instead of one-off tickets to the platform team. A platform orchestrator sits behind the developer portal, connecting those actions to infrastructure provisioning, policies, and automation. This is the layer that decides whether "self-service" actually means developers can provision what they need, or just means a slightly nicer ticketing form.

• Spacelift: Designed to orchestrate Terraform, OpenTofu, Pulumi, and more inside one governed pipeline, it's best for teams that want policy-as-code across multiple IaC tools without building custom CI/CD for it. Watch out for the added subscription layer on top of tools you may already run.
• Crossplane: An open-source, Kubernetes-native framework now at CNCF Graduated status, it's best for Kubernetes-standardized teams that want to build their own self-service infrastructure API. It uses the Kubernetes control plane to manage infrastructure and other external resources. Plan for the Kubernetes fluency it demands, plus migration work where its 2.0 release changed core concepts.
• Humanitec: As a purpose-built orchestrator from one of the companies that helped define the term "platform engineering," it's best for teams that want an opinionated orchestration layer decoupled from any single IaC tool. The tradeoff: adoption can require re-architecting around its orchestration model.

Infrastructure as code

The job: define infrastructure in code instead of clicking through cloud consoles. Infrastructure as code (IaC) makes infrastructure provisioning repeatable, version-controlled, and easier to automate across environments. This category also comes with a licensing decision most of the others don't.

• Terraform: Now developed under HashiCorp, an IBM company since IBM's $6.4 billion acquisition closed in February 2025, the IaC tool remains the option with the largest provider and module ecosystem in the category. HashiCorp moved it off open-source licensing in 2023 in favor of the Business Source License, which restricts running Terraform as a competing hosted service without a commercial agreement. It's still the safer default for teams that want official HashiCorp enterprise support.
• OpenTofu: Created in direct response to that license change, the fork is now a CNCF Sandbox project and stays under the original open-source license. It fits teams that want a fully open-source, Terraform-compatible alternative without the same licensing restriction.

CI/CD and GitOps

The job: get code changes into production safely and repeatably. CI/CD pipelines automate the path from version control through build, test, and deployment, while GitOps uses Git as the source of truth for the desired state of an environment. This is usually the most mature category on the list, and the one teams are least likely to rip out, so the honest limitations matter more here than the feature lists.

• Argo CD: A CNCF Graduated GitOps tool for Kubernetes, it continuously syncs deployed state back to Git. Best for Kubernetes-native teams standardizing on GitOps. Its scope is Kubernetes-only, and large multi-cluster fleets often need additional tooling to manage at scale.

• Jenkins: As a long-standing open-source CI server with the largest plugin ecosystem in the category, it's best for teams with existing Jenkins investment or complex, fully self-hosted pipeline needs. Watch out for plugin security debt: a single September 2026 security advisory covered Jenkins core and 18 plugins, with one listed plugin still lacking a fix at publication.
• Qovery: A newer multi-cloud deployment platform layered over raw cloud infrastructure, it's best for smaller teams that want a managed deployment layer without building one themselves. The company and community are smaller than Jenkins or Argo CD, which matters if ecosystem depth is a priority.

If your team already runs GitHub Actions, GitLab CI, or another established CI/CD system, platform engineering doesn't automatically justify replacing a pipeline that already works. The question is whether it integrates cleanly with the developer self-service workflows and golden paths you're building around it.

Observability

The job: give the platform team and every developer on the paved road one standardized way to see what's happening across every service, instead of each team bringing its own monitoring tool. That becomes increasingly important as Kubernetes, microservices, and other distributed architectures increase the number of components developers need to understand.

• New Relic: A unified observability platform, it's best for platform teams that want one standardized view of every service on the paved road. It isn't a portal or orchestration replacement, so it runs alongside the tools above rather than in place of them. Sportradar used New Relic to cover the health of 200 services, while increasing release frequency 15% and maintaining a 99.9% availability SLO.

New Relic's approach to observability in a platform engineering practice centers on giving every team the same day-one coverage, including alerting, centralized logs, APM, distributed tracing, and infrastructure monitoring, so a service on the paved road is visible the same way no matter which team built it. Support for open standards such as OpenTelemetry also lets platform teams standardize telemetry collection without tying instrumentation to a single observability tool.

What actually separates a good platform engineering stack from a bad one

Feature checklists don't tell you whether a platform engineering stack will actually work. What matters is whether it reduces cognitive load for developers, limits tool sprawl, and makes the preferred way of working easy enough that teams actually adopt it.

Standardization vs. developer autonomy

A good stack makes the easy path the standard path without forcing every team into an identical workflow. A bad one enforces uniformity so rigid that teams route around it, or hands out so much flexibility that no paved road exists at all. 

The real test is whether a team under deadline pressure still chooses the golden path. Developer self-service only reduces cognitive load if it's easier than working around the platform.

Tool sprawl and siloed data

Developers already lose real time to fragmented tooling. Atlassian's 2025 State of Developer Experience report, based on 3,500 developers and engineering managers, found developers spend just 16% of their time actually coding, and 90% lose six or more hours a week to organizational inefficiencies like finding information, adapting to new tools, and switching context between systems. A platform engineering stack that adds another siloed dashboard makes that worse, not better.

Look for tools that consolidate workflows or connect cleanly through APIs, automation, and shared data rather than creating another place developers have to check. The goal of an internal developer platform should be to hide unnecessary complexity, not move it into a new interface.

Time to value for the platform team

Platform investments don't pay off immediately, and the data backs that up. Google Cloud's 2024 DORA report found teams using an internal developer platform saw 8% higher individual productivity and 10% higher team performance, alongside 8% lower delivery throughput and 14% lower change stability.

Budget for that dip. Evaluate the implementation work alongside the end-state capabilities: a platform engineering tool that eventually removes manual work can still add significant work for the platform team while it's being integrated, standardized, and adopted.

Where observability fits in the platform engineering conversation

Most teams don't build a platform engineering stack in one purchase cycle. The observability tool is usually already running before anyone formalizes a portal, an orchestrator, or a golden path. That order matters more than it looks: self-service is much more useful when developers can immediately see what happened after they provision infrastructure, deploy a service, or make a change.

A paved road only holds up if developers can see, in one place, whether the service they're deploying through it is actually healthy. That takes:

• Consistent telemetry across every service on the platform, not five different dashboards depending on which team owns which stack.
• Traces and logs that connect the same way regardless of which portal or orchestrator triggered the deployment.
• Alerting consistent enough that a developer new to the platform trusts it the same way a five-year veteran does.

That creates a feedback loop for developer self-service: provision, deploy through CI/CD, then use consistent telemetry to verify service health and troubleshoot changes.

If this decision is already in motion for your team, it's usually not a single-tool purchase. It's a line item inside a broader platform engineering evaluation, so evaluate observability tools on how well they can support the rest of the internal developer platform as it evolves. Consolidating observability instead of running it per team can reduce the monitoring sprawl the platform is supposed to eliminate, while building that layer on open standards like OpenTelemetry gives teams more flexibility as the surrounding toolchain changes.

Getting started

Start with the category causing the most pain today, not the one at the top of a listicle. A short way to find it:

1. Which category do you not have at all? A missing piece often causes more damage than an imperfect one you already run.
2. Which category is generating the most manual tickets to the platform team right now? That's your most urgent gap, regardless of what a vendor comparison ranks first.
3. Which category do you already own, and is it actually connecting the others? If observability is already in place, check whether it gives developers consistent visibility across the services and workflows your internal developer platform will bring together.

None of this has to happen in the order a vendor roadmap suggests. It has to happen in the order your platform team is actually bleeding time, and that's usually visible in your ticket queue before it shows up in any tool comparison.

Whatever you choose first, New Relic's DevOps solutions give the platform team and every developer on the paved road the same visibility into deployments, incidents, and service health, helping standardize observability across the platform engineering tools you build around it. Start for free to see how New Relic fits into your existing DevOps and platform engineering stack.