Which Platform Engineering Tools Belong in Your Stack?

Platform engineering has emerged as a necessary response to the complexity of modern cloud-native development. While DevOps culture encouraged developers to “you build it, you run it,” the reality often resulted in cognitive overload, with application developers struggling to manage Kubernetes manifests, Terraform state files, and security policies alongside their actual code.

The goal of a platform team is not simply to hoard tools but to curate an Internal Developer Platform (IDP) that binds these technologies into cohesive “golden paths.” These paths enable self-service, standardization, and speed. However, with hundreds of tools available, distinguishing between a portal, an orchestrator, and a control plane is critical for building a stack that actually works.

TL;DR

• Tools must serve a golden path: Do not select tools in isolation; choose them based on their ability to automate specific developer journeys like “create a service” or “deploy to production.”
• The portal is not the platform: An Internal Developer Portal (like Backstage) is the interface, but you need an orchestrator (like Humanitec or Crossplane) to do the heavy lifting.
• Feature management is a platform capability: Decoupling deployment from release using feature flags is essential for safe self-service delivery.
• Open source allows flexibility: Leveraging open standards prevents vendor lock-in and allows the platform to evolve as organizational maturity grows.
• Measure with DORA: Instrument your toolchain to track lead time, deployment frequency, and change failure rates to prove the platform’s value.

The Anatomy of a Platform Stack

A common misconception is that “platform engineering tools” refers to a single vendor suite that solves every problem. In reality, an IDP is an assembly of distinct capability layers. According to research from the CNCF, the platform is the sum of the technologies that a platform team binds together to pave the road for developers.

When evaluating your stack, categorize tools by the function they serve in the developer experience (DevEx):

1. The Interface: How developers interact with the platform (Portals).
2. The Orchestrator: How requests are translated into infrastructure (Platform Orchestrators).
3. The Foundation: The underlying infrastructure engines (IaC, Kubernetes).
4. The Delivery Layer: How code moves safely to production (CI/CD, Feature Management).
5. The Feedback Loop: How developers know what is happening (Observability).

Internal Developer Portals (The Interface)

The internal developer portal is the “glass” through which developers view the platform. It creates a unified catalog of software, documentation, and operational data. Its primary job is discoverability and triggering actions, not necessarily executing them.

Backstage

Originally open-sourced by Spotify, Backstage has become the de facto standard framework for building developer portals. It is highly extensible, allowing platform teams to build a software catalog that tracks ownership and metadata for every microservice in the organization.

Backstage requires significant engineering effort to set up and maintain. It is a framework, not a ready-to-use product. However, its plugin ecosystem allows you to integrate virtually every other tool in your stack, from CI/CD status to cloud cost estimates, into a single pane of glass.

Port

For teams that want a portal without the overhead of managing a Backstage instance, Port offers a SaaS alternative. It focuses on the same outcomes—providing a catalog and self-service actions—but creates the internal graph of your infrastructure with less configuration. This can be a faster route for teams establishing platform engineering best practices who want to prove value quickly before investing in a custom build.

Platform Orchestrators (The Engine)

If the portal is the frontend, the platform orchestrator is the backend. This layer receives a high-level request from a developer (e.g., “I need a Postgres database”) and translates it into the specific infrastructure configurations required to provision it.

Crossplane

Crossplane allows you to build a control plane using Kubernetes. It extends the Kubernetes API to manage external resources, such as AWS S3 buckets or GCP Cloud SQL instances.

Platform engineers define “Composite Resource Definitions” (XRs) that bundle complex infrastructure into simple, abstract claims. Developers claim a “database,” and Crossplane handles the complexity of provisioning it securely. This prevents the “ticket-ops” trap where developers must wait for ops teams to manually run scripts.

Humanitec

Humanitec focuses specifically on the “Platform Orchestrator” category. It uses a workload specification (Score) to define how an application should run, independent of the environment. The orchestrator then dynamically generates the necessary configuration files (manifests) at deployment time. This keeps developer-facing configs simple while allowing platform teams to enforce standards in the background.

Infrastructure and Configuration Management

Beneath the orchestration layer, you still need robust engines to apply changes to your cloud providers. These tools are often abstracted away from the average application developer but are the daily drivers for the platform team.

Terraform and OpenTofu

Terraform remains the industry standard for Infrastructure as Code (IaC). However, in a platform context, developers should rarely write raw Terraform. Instead, platform teams write reusable Terraform modules that are called by the orchestrator or CI pipeline.

Following the licensing changes to Terraform, OpenTofu emerged as an open-source fork, ensuring that the core definition of infrastructure remains accessible and community-driven.

Kubernetes

While technically a container orchestrator, Kubernetes serves as the operating system for modern platforms. It provides the API surface area that other tools plug into. Whether you use EKS, GKE, or self-hosted clusters, Kubernetes is the convergence point for deployment logic.

The Delivery Layer: CI/CD and GitOps

Automating the path from git push to running software is the most visible “golden path” a platform team provides.

ArgoCD

ArgoCD is the standard for GitOps on Kubernetes. It ensures that the state of the cluster matches the state defined in Git. By using ArgoCD, platform teams provide a transparent deployment mechanism. Developers can see exactly which version of their application is running in which environment without needing direct kubectl access.

GitHub Actions and GitLab CI

The pipeline runner is the workhorse of automation. Whether you use GitHub Actions or GitLab CI, the platform engineering approach involves creating standardized pipeline templates. Rather than every team writing their own build scripts, the platform provides “vetted” pipelines that automatically include security scanning, testing, and Docker builds.

Safety and Feature Management

Speed without safety is just chaos. A mature platform stack includes tools that decouple deployment (moving code to servers) from release (exposing code to users). This allows developers to merge to the main branch frequently without breaking production, a core tenet of trunk-based development.

Unleash

Unleash fits into the platform stack as a feature management layer. While CI/CD tools move artifacts to servers, Unleash controls the runtime behavior of those artifacts. By wrapping code in feature flags, platform teams enable progressive delivery patterns like canary releases and gradual rollouts.

For platform engineers, incorporating a feature flag system is a governance requirement. It provides a kill switch mechanism that mitigates the blast radius of bad deployments. Unleash supports change request workflows, allowing teams to enforce the “four-eyes principle” (approval requirements) for sensitive environments, ensuring compliance without slowing down the initial deployment.

Observability and Feedback Loops

According to DORA research, high-performing platforms provide fast feedback to developers. If a deployment fails or performance degrades, the toolchain must alert the owner immediately.

Prometheus and Grafana

Prometheus (metrics collection) and Grafana (visualization) are the open-source standards for observability. Platform teams should provide “monitoring as code,” where standard dashboards are automatically generated for every new service deployed. This ensures that no service runs in the dark.

Building the Stack: A Strategy

Selecting tools is not a shopping spree; it is an architectural decision. Sprawl creates technical debt. When adding a tool to your platform stack, verify it meets three criteria:

1. API-First: Can it be automated and orchestrated by other tools?
2. Self-Service Ready: Does it allow developers to perform actions without opening a ticket?
3. Measurable: Can you extract data from it to track adoption and DORA metrics?

Start with the capabilities that solve the most painful friction points—usually deployment automation or environment provisioning—and expand the stack as the platform matures.

Conclusion

The platform engineering landscape is vast, but a successful stack is defined by how well the components integrate to lower cognitive load. You do not need every tool listed above. You need a portal to organize, an orchestrator to execute, and a safety layer to manage releases.

By combining infrastructure automation with progressive delivery controls like feature flags, you transform your platform from a ticket-based bottleneck into a product that developers actually want to use. Focus on the golden paths, enforce safety guardrails invisible to the user, and treat your platform as a product that evolves with your team’s needs.

FAQs about platform engineering tools

What is the difference between an IDP and a developer portal?

An Internal Developer Platform (IDP) is the total sum of tools, infrastructure, and workflows that enable self-service for developers. A developer portal (like Backstage) is simply the user interface or “front door” of the IDP. The portal allows developers to interact with the underlying platform capabilities without needing to understand the complexity of the backend tools.

Why are feature flags considered platform engineering tools?

Feature flags allow platform teams to decouple deployment from release, which is essential for stable, high-velocity delivery. They act as a control plane for runtime configuration, enabling progressive delivery (canary releases) and providing operational kill switches. This reduces the risk of allowing developers to self-deploy code to production.

How do I measure the success of my platform tools?

Success should be measured using DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service) and developer experience metrics (like satisfaction or cognitive load). If your tools are effective, you should see deployment frequency increase while lead times and ticket volume decrease.

Should I build my own portal or buy a SaaS solution?

This depends on your engineering resources. Building a custom portal using a framework like Backstage offers maximum flexibility but requires a dedicated team to maintain and update it. SaaS solutions offer faster time-to-value and lower maintenance overhead but may offer less customization for unique legacy workflows.

What is the role of GitOps in platform engineering?

GitOps serves as the source of truth for the platform. By storing infrastructure and application definitions in Git, platform teams ensure version control, auditability, and automated drift detection. Tools like ArgoCD use these Git repositories to synchronize the actual state of the infrastructure, making the platform self-healing and consistent.