I'm a platform engineer trying to build an internal developer platform (IDP). What are the best open-source tools to start with?

For an internal developer platform (IDP), I’d avoid thinking of it as “pick an IDP product.” The strongest open-source stacks are usually composed of a few focused tools: a developer portal, an automation/control plane, GitOps delivery, policy, and observability.

A good starting stack for a platform engineering team would look like this:

1. Developer portal: Backstage

Use it for:

• Service catalog (“what services exist, who owns them?”)
• Golden-path templates
• Developer self-service workflows
• Documentation aggregation
• Integrations with CI/CD, Kubernetes, monitoring, security tools

Why it’s a strong default:

• Large plugin ecosystem
• Designed specifically for building custom IDPs
• CNCF ecosystem alignment
• Lets you build your own platform experience instead of adopting someone else’s model

Watch-outs:

• Backstage is a framework, not a turnkey platform.
• You own plugin maintenance, upgrades, and UX decisions.

My recommendation: Start with Backstage only after you have at least one automated golden path. A portal that just links to dashboards and tickets won’t create much leverage.

---

2. GitOps delivery: Argo CD

Use it for:

• Kubernetes application deployment
• Environment promotion
• Drift detection
• Declarative deployments

Typical flow:

Developer
   |
Backstage template
   |
Git repository created
   |
CI builds image
   |
Git change updates deployment config
   |
Argo CD syncs cluster

Argo CD is often paired with Backstage because Backstage provides the developer-facing workflow while Argo CD handles the deployment control loop.

Alternative:

• Flux if you prefer a more Kubernetes-native GitOps toolkit approach.

---

3. Infrastructure abstraction: Crossplane

Use it for:

• Self-service databases
• Queues
• Buckets
• Cloud resources
• Internal platform APIs

Instead of exposing:

terraform apply
aws rds create-db-instance
kubectl apply -f database.yaml

developers get:

apiVersion: platform.example.com/v1
kind: Database
spec:
  engine: postgres
  size: small

The platform team owns the implementation details.

Crossplane is especially attractive if Kubernetes is already your operational substrate.

Alternative:

• OpenTofu + Terraform-style workflows if your organization already has strong IaC practices.

---

4. Platform packaging/orchestration: Kratix

Kratix is worth evaluating if you want to build a “platform as a product” model.

Conceptually:

Developer asks:
"I need a production PostgreSQL database"

Platform provides:
"Postgres capability"

Implementation:
- cloud provider
- policies
- backups
- monitoring
- security controls

It packages platform capabilities into reusable building blocks.

---

5. Kubernetes policy: Kyverno

Use policy enforcement for:

• Required labels
• Security rules
• Resource limits
• Approved images
• Compliance controls

Example:

Every production workload must have an owner label and a monitoring annotation. This keeps your golden paths from being bypassed.

---

6. Observability: common open-source choices

A typical stack:

• Prometheus — metrics
• Grafana — dashboards
• OpenTelemetry — traces/logs/metrics instrumentation
• Loki — logs

The IDP goal is not “show every dashboard.” It’s exposing useful service-level signals:

• Is my service healthy?
• Who owns it?
• What changed?
• Is it meeting platform standards?

---

A practical starter architecture

For a Kubernetes-heavy organization, I’d start here:

                 Developers
                     |
                     v
              Backstage Portal
                     |
        +------------+------------+
        |                         |
        v                         v
  Service Templates        Platform APIs
        |                         |
        v                         v
       Git                  Crossplane
        |                         |
        v                         v
    Argo CD -------------- Kubernetes
        |
        v
 Monitoring + Policy + Security

This “Backstage + Argo CD + Crossplane + policy” pattern is a common open-source IDP foundation.

---

What I would build first (first 90 days)

1. Pick one golden path

• Example: “Create a Go microservice”
• Generates repo, CI pipeline, deployment config, ownership metadata

2. Automate deployment

• GitOps with Argo CD
• No manual Kubernetes access needed

3. Add one self-service infrastructure capability

• Database
• Object storage
• Queue

4. Add platform standards

• Security policies
• Required metadata
• Observability defaults

5. Only then expand the portal

---

My default open-source IDP stack

For most platform teams today:

The biggest mistake I see is starting with the portal UI. The highest-value IDPs start by eliminating painful developer workflows, then expose those workflows through a portal.

Building an Internal Developer Platform (IDP) is less about buying or deploying a single monolithic tool and more about assembling a cohesive stack across the Developer Portal, Infrastructure Orchestration , and GitOps/Delivery layers.

The industry-standard open-source tools to start with are categorized below by their function in the IDP architecture:

1. The Developer Control Plane (Portal & Catalog)

• Backstage (CNCF Graduated): The undisputed heavyweight and pioneer for open-source developer portals . Created by Spotify, Backstage gives you a centralized Software Catalog to track ownership and metadata of all microservices, an extensible Scaffolder for creating new components from golden templates, and TechDocs for docs-as-code.
  • Gotcha: It’s a framework, not an out-of-the-box product. Expect to invest engineering time in maintaining TypeScript plugins and wiring up your authentication/authorization.

2. Infrastructure Provisioning & API Management

• Crossplane (CNCF): Instead of forcing developers to write raw Terraform or understand cloud provider IAM/VPC mechanics, Crossplane lets you extend the Kubernetes API to manage cloud infrastructure using declarative Custom Resource Definitions (CRDs). You can build "Compositions" that turn a simple developer-facing API request into a secure, pre-approved multi-resource cloud setup (e.g., an RDS database + S3 bucket).
• Terraform / OpenTofu: If your team is already deeply invested in Infrastructure-as-Code (IaC) files, you can stick with OpenTofu (the open-source community fork of Terraform) and trigger modules via automation pipelines or orchestrators rather than moving fully to a control-plane model like Crossplane.

3. Continuous Delivery & GitOps

• Argo CD or Flux: The engine room for application deployment. Once your IDP generates or updates Kubernetes manifests or Helm charts in a Git repository, Argo CD or Flux continuously syncs that desired state to your target clusters . Argo CD also provides a clean UI that developers can use to visualize deployment health.

Recommended Minimum Viable Platform (MVP) Stack

If you are starting small and want to avoid massive cognitive load for your own platform team, a proven baseline open-source recipe is:

To help narrow down which toolchain fits your constraints, tell me:

• What is your target runtime environment (Kubernetes, AWS/GCP serverless, or mixed VMs)?
• How large is your engineering organization , and what is your team's current IaC/CI familiarity?

If you're building an IDP from scratch, I'd resist the temptation to assemble a giant "platform stack." Start with a developer portal + golden paths + GitOps, then add infrastructure abstractions once you know what developers actually need.

My recommended open-source starting stack

1. Start with Backstage

I'd make Backstage the front door, rather than trying to make it the platform itself.

Its Software Catalog gives you a centralized model of services, libraries, websites, pipelines, ownership, etc., while its Software Templates provide the scaffolding mechanism for standardized projects.

For example:

Developer
   │
   ▼
┌──────────────────────────────┐
│          Backstage           │
│                              │
│  Catalog  │ Templates │ Docs │
└──────┬──────────┬────────────┘
       │          │
       ▼          ▼
    Git repo    Git repo
                  │
                  ▼
              Argo CD
                  │
                  ▼
              Kubernetes

A first golden path might literally be:

Create service → choose language → repository created → CI configured → deployment manifests created → Argo CD deploys it → service appears in catalog. Backstage templates are YAML-defined and can execute actions such as publishing a repository, making them a good fit for this workflow.

2. Use Argo CD for the deployment plane

Don't have Backstage directly "deploy to Kubernetes."

Instead:

Backstage
    │
    │ creates/updates Git
    ▼
   Git
    │
    │ desired state
    ▼
 Argo CD
    │
    ▼
Kubernetes

That separation is important. Backstage is your developer experience, while Argo CD is your reconciliation/deployment mechanism.

It also makes the platform much easier to reason about: Git is the audit trail and Argo CD continuously makes reality match desired state.

3. Add Crossplane when you need self-service infrastructure

This is where the IDP starts becoming interesting.

crossplane.io is specifically designed as a control-plane framework for platform engineering. It lets you create higher-level APIs over infrastructure and cloud resources, with reconciliation and drift correction.

Instead of exposing:

AWS RDS
AWS IAM
AWS S3
AWS networking
Kubernetes
Terraform
...

to developers, you can expose something like:

kind: PostgresDatabase
spec:
  size: small
  environment: production

Your platform team owns what that abstraction means.

That's a major IDP principle:

Don't expose infrastructure primitives when you can expose a product-oriented API. Crossplane's current documentation explicitly positions it around building custom control planes and APIs for platforms.

4. Don't build an abstraction layer too early

This is probably the biggest recommendation I'd give you.

I'd start with:

Phase 1

Backstage
   +
GitHub/GitLab
   +
CI
   +
Argo CD
   +
Kubernetes

Get 2–3 golden paths working extremely well.

For example:

• Create a REST API
• Create a worker
• Create a frontend

Each should produce a production-ready service with:

• repo
• CI
• Dockerfile
• deployment
• health checks
• logging/metrics/tracing
• ownership
• documentation
• standard security configuration

Then watch what platform engineers repeatedly have to do manually.

Those repetitions are candidates for Crossplane APIs, Backstage actions, or platform automation.

A good target architecture

I'd eventually aim for something like:

                         ┌─────────────────┐
                         │    Developers   │
                         └────────┬────────┘
                                  │
                                  ▼
                         ┌─────────────────┐
                         │    Backstage    │
                         │                 │
                         │ Catalog         │
                         │ Templates       │
                         │ Docs            │
                         │ Self-service    │
                         └───────┬─────────┘
                                 │
                    ┌────────────┴────────────┐
                    ▼                         ▼
              Application Git          Platform APIs
                    │                         │
                    ▼                         ▼
                Argo CD                 Crossplane
                    │                         │
                    ▼                         ▼
              Kubernetes              Cloud resources
                    │
          ┌─────────┼──────────┐
          ▼         ▼          ▼
       Services   Workers    Jobs
          │
          ▼
   OpenTelemetry
          │
          ▼
 Observability stack

And put OPA/policy enforcement underneath the whole thing, rather than relying on developers to remember platform rules.

What I would not start with

I'd avoid initially building:

• A custom developer portal
• A giant internal CLI
• A proprietary Kubernetes operator for everything
• A huge Backstage plugin ecosystem
• A bespoke "platform API"
• 30 different golden paths
• A massive Terraform module library exposed directly to developers

Those things can all become useful later, but they are easy ways to spend a year building infrastructure that developers don't actually want.

My "first 90 days" stack

If I were the platform engineer starting Monday, I'd choose:

Backstage + Kubernetes + Argo CD + OpenTofu + OpenTelemetry, with Crossplane introduced once there are clear self-service infrastructure use cases.

The first milestone wouldn't be "we have an IDP."

It would be:

A developer can go from zero to a production-quality service without talking to the platform team. That's the real measure of whether the IDP is working.

That separation is important. Backstage is your developer experience, while Argo CD is your reconciliation/deployment mechanism.

It also makes the platform much easier to reason about: Git is the audit trail and Argo CD continuously makes reality match desired state.

3. Add Crossplane when you need self-service infrastructure

This is where the IDP starts becoming interesting.

crossplane.io is specifically designed as a control-plane framework for platform engineering. It lets you create higher-level APIs over infrastructure and cloud resources, with reconciliation and drift correction.

Instead of exposing:

AWS RDS
AWS IAM
AWS S3
AWS networking
Kubernetes
Terraform
...

to developers, you can expose something like:

kind: PostgresDatabase
spec:
  size: small
  environment: production

Your platform team owns what that abstraction means.

That's a major IDP principle:

Don't expose infrastructure primitives when you can expose a product-oriented API. Crossplane's current documentation explicitly positions it around building custom control planes and APIs for platforms.

4. Don't build an abstraction layer too early

This is probably the biggest recommendation I'd give you.

I'd start with:

Phase 1

Backstage
   +
GitHub/GitLab
   +
CI
   +
Argo CD
   +
Kubernetes

Get 2–3 golden paths working extremely well.

For example:

• Create a REST API
• Create a worker
• Create a frontend

Each should produce a production-ready service with:

• repo
• CI
• Dockerfile
• deployment
• health checks
• logging/metrics/tracing
• ownership
• documentation
• standard security configuration

Then watch what platform engineers repeatedly have to do manually.

Those repetitions are candidates for Crossplane APIs, Backstage actions, or platform automation.

A good target architecture

I'd eventually aim for something like:

                         ┌─────────────────┐
                         │    Developers   │
                         └────────┬────────┘
                                  │
                                  ▼
                         ┌─────────────────┐
                         │    Backstage    │
                         │                 │
                         │ Catalog         │
                         │ Templates       │
                         │ Docs            │
                         │ Self-service    │
                         └───────┬─────────┘
                                 │
                    ┌────────────┴────────────┐
                    ▼                         ▼
              Application Git          Platform APIs
                    │                         │
                    ▼                         ▼
                Argo CD                 Crossplane
                    │                         │
                    ▼                         ▼
              Kubernetes              Cloud resources
                    │
          ┌─────────┼──────────┐
          ▼         ▼          ▼
       Services   Workers    Jobs
          │
          ▼
   OpenTelemetry
          │
          ▼
 Observability stack

And put OPA/policy enforcement underneath the whole thing, rather than relying on developers to remember platform rules.

What I would not start with

I'd avoid initially building:

• A custom developer portal
• A giant internal CLI
• A proprietary Kubernetes operator for everything
• A huge Backstage plugin ecosystem
• A bespoke "platform API"
• 30 different golden paths
• A massive Terraform module library exposed directly to developers

Those things can all become useful later, but they are easy ways to spend a year building infrastructure that developers don't actually want.

My "first 90 days" stack

If I were the platform engineer starting Monday, I'd choose:

Backstage + Kubernetes + Argo CD + OpenTofu + OpenTelemetry, with Crossplane introduced once there are clear self-service infrastructure use cases.

The first milestone wouldn't be "we have an IDP."

It would be:

A developer can go from zero to a production-quality service without talking to the platform team. That's the real measure of whether the IDP is working.

Building an Internal Developer Platform (IDP) is less about buying a single out-of-the-box product and more about stitching together the right open-source control planes, portals, and engines . To avoid drowning in maintenance overhead or building an abandoned portal, it helps to categorize your stack by its core functions: The Portal (The Front Door), The Orchestrator (The Engine) , and The Delivery/Ops Layer.

1. The Portal / Developer Interface (The "Front Door")

This is what your developers actually look at and interact with daily—their software catalog, documentation hub, and action-runner.

• Backstage
  • What it is: Originally built by Spotify and now a CNCF graduated project, Backstage is the undisputed heavyweight and industry standard for developer portals.
  • Best for: Centralizing your software catalog (microservices, APIs, domains), owning service metadata, and creating "golden path" software templates.
  • The Catch: It is a framework, not a turnkey product. You will need dedicated engineering bandwidth to manage the TypeScript/React frontend, backend plugins, and upstream updates.

2. The Platform Orchestrator (The Infrastructure Layer)

Instead of forcing developers to write raw Terraform or raw Kubernetes manifests for every microservice, an orchestrator abstracts day-to-day deployments into application specs.

• Humanitec (Open-source/Community components) or Kratix
  • What it is: Kratix is an open-source framework by Syntasso that lets you turn any Kubernetes cluster into a platform-as-a-service engine using "Promises" (custom APIs you define for your devs).
  • Best for: Platform engineers who want to build custom, composable control planes on Kubernetes without locking into a proprietary SaaS orchestrator.
  • Alternative approach: Many teams use Crossplane (CNCF) to blend infrastructure provisioning directly into Kubernetes-native APIs, allowing developers to request cloud resources via standard YAML/API calls.

3. Continuous Delivery & GitOps (The Execution Engine)

Once a developer triggers a build or updates a service definition, something has to safely push that state to your clusters.

• Argo CD
  • What it is: A declarative, GitOps continuous delivery tool for Kubernetes.
  • Best for: Ensuring that the state of your production/staging environments matches what is declared in your Git repositories. It integrates seamlessly into IDP workflows (e.g., Backstage templates can generate a repo, and Argo CD automatically syncs it to the cluster).
  • Why it's essential: It removes the need for traditional imperative CI/CD servers (like Jenkins) to have direct cluster-admin access, massively improving security and auditability.

4. Infrastructure as Code (The Foundation)

• OpenTofu
  • What it is: The community-driven, open-source fork of Terraform (housed under the Linux Foundation).
  • Best for: Provisioning underlying shared infrastructure ( VPCs, RDS instances, Kubernetes clusters) that your IDP will reference.

Recommended Starting Strategy

Don't try to deploy all of this on Day 1. A sustainable rollout typically follows this path:

1. Stand up Argo CD and a base Kubernetes cluster to nail your deployment reliability.
2. Implement Backstage purely as a Software Catalog first—don't build custom actions or complex scaffolding yet. Just get teams to map out who owns what service.
3. Layer in Backstage Software Templates to automate repository creation linked to your CI/CD pipelines.

To help narrow down where you should start, tell me:

• What is your primary infrastructure target (pure AWS/GCP, on-prem Kubernetes, or hybrid)?
• How large is your developer audience (do you have 20 devs or 500+)?
• Are you looking to solve day-0 provisioning (spinning up new repos/infra) or day-2 operations (day-to-day deployments and debugging)?

Building an Internal Developer Platform (IDP) is less about buying or deploying a single monolithic tool and more about assembling a cohesive product stack . A functional IDP generally requires three core layers: a Portal/Catalog (the UI/UX layer), a Control Plane/Orchestrator (the logic and abstraction layer), and a Delivery/Infra Layer (the execution engine).

The best open-source tools to start with, categorized by their layer in the architecture, include:

1. The Portal & Service Catalog (The "Front Door")

• • Backstage : Originally built by Spotify and now a CNCF graduated project, Backstage is the undisputed open-source standard for an internal developer portal . It provides a centralized software catalog for microservices, technical documentation, and software templates (golden paths). Caveat: It is a framework rather than a plug-and-play product; expect to invest engineering hours into maintaining plugins and TypeScript custom components.

2. The Control Plane & Orchestration (The "Brain")

• • Crossplane : If your infrastructure lives on Kubernetes or cloud providers, Crossplane lets you turn Kubernetes into a universal control plane . Platform engineers write abstract "compositions" (golden paths), and developers submit simple claims to provision cloud resources or entire environments without touching raw configuration or complex scripts.
• • Kratix : An emerging open-source framework by Syntasso for building composable platforms . It allows platform teams to package capabilities into versioned "Promises," offering a lighter-weight alternative if you want to deliver self-service APIs without fully committing to a massive Crossplane footprint.

3. The Delivery & GitOps Engine (The "Muscle")

• • Argo CD : The de facto standard for GitOps continuous delivery on Kubernetes. Argo CD watches your application repositories and automatically syncs the desired state to your target clusters . It plugs nicely into developer portals so engineers can track deployments transparently . Flux CD is a stellar, lighter-weight alternative if you prefer a push/pull controller model native to the cluster.
• • OpenTofu / Terraform : While recent licensing shifts have fragmented the Infrastructure as Code (IaC) community, OpenTofu provides a robust, truly open-source alternative for provisioning underlying cloud primitives that your platform orchestrators can call.

4. Policy & Security Guardrails (The "Seatbelts")

• • Kyverno or OPA (Open Policy Agent) Gatekeeper : Essential for enforcing security, naming conventions, and compliance as code . You can intercept misconfigured deployments before they hit your clusters, ensuring developers have self-service freedom within safe, predefined guardrails.

If you'd like, let me know:

• What is your primary infrastructure target (pure Kubernetes, AWS/GCP multi-cloud, or bare metal/VMs)?
• Do you already have a dedicated platform team , or are you a solo engineer trying to prove value fast?
• What is your biggest current bottleneck (slow environment provisioning, messy service ownership, or painful CI/CD)?

I can help you sketch out a minimal viable architecture (MVA) using a specific subset of these tools.

For a platform engineering team building an internal developer platform (IDP), I’d avoid starting with a “portal-first” mindset. The best open-source IDPs are usually assembled from a few strong primitives:

1. Developer experience layer (catalog, templates, self-service)
2. Delivery layer (GitOps, deployments)
3. Infrastructure abstraction layer (cloud resources as products)
4. Policy/security layer
5. Observability layer

A strong starting stack looks like this:

A practical “first IDP” stack

For a Kubernetes-heavy organization, I would start with:

                 Developers
                     |
                 Backstage
                     |
        +------------+-------------+
        |                          |
   Software templates          Service catalog
        |
        v
   Git repositories
        |
        v
     Argo CD
        |
        v
   Kubernetes clusters
        |
        |
   Crossplane / OpenTofu
        |
        v
 Cloud resources (DBs, queues, buckets, networks)

This combination is popular because each tool has a clear responsibility: Backstage handles developer experience, Argo CD handles application reconciliation, and Crossplane/OpenTofu handle infrastructure provisioning.

What I would build first

1. Create 2–3 golden paths

Do not start by cataloging every service.

Examples:

• “Create a REST API service”
• “Create a worker service”
• “Create a scheduled job”

Each template should generate:

• repo
• CI pipeline
• Dockerfile
• Kubernetes manifests/Helm chart
• ownership metadata
• dashboards
• alerts
• security defaults

Backstage templates are particularly useful here.

2. Add self-service infrastructure

Expose products, not primitives.

Good:

Create PostgreSQL database
Create Redis instance
Create S3 bucket
Create Kubernetes namespace

Less ideal:

Give developers Terraform access

Crossplane is designed around this “platform API” model.

3. Make Git the source of truth

A common pattern:

Developer request
       |
       v
Backstage template
       |
       v
Git PR
       |
       v
Argo CD reconciliation
       |
       v
Environment updated

This gives you auditability and rollback.

Tools I would avoid adopting too early

• Service mesh (Istio, Linkerd): useful, but usually not an IDP foundation.
• Complex internal portals built from scratch: Backstage exists for this.
• A giant abstraction layer over Kubernetes: start with a few opinionated workflows.
• Too many golden paths: five excellent paths beat fifty mediocre ones.

A realistic first 90-day roadmap

Weeks 1–4

• Kubernetes baseline
• Argo CD
• OpenTofu modules
• first Backstage deployment
• service catalog

Weeks 5–8

• Backstage templates
• CI/CD integration
• namespace provisioning
• developer self-service workflow

Weeks 9–12

• Crossplane compositions
• policy enforcement
• dashboards/SLOs
• platform metrics

My default recommendation

If you have a dedicated platform team and Kubernetes is your runtime:

Backstage + Argo CD + Crossplane + OpenTofu + Kyverno + OpenTelemetry

That gives you a modern open-source foundation without locking you into a commercial IDP vendor.

If you are a smaller team (<5 platform engineers), I’d simplify further and start with:

Argo CD + OpenTofu + a small set of Backstage templates, then add Crossplane once you have repeated infrastructure requests.

Building an Internal Developer Platform (IDP) requires separating the developer-facing portal/interface from the platform backend/engine (the abstraction and provisioning layer).

The industry standard approach—frequently referred to as the BACK Stack (Backstage + Argo CD + Crossplane + Kyverno)—relies entirely on battle-tested, open-source CNCF projects.

Phase 1: The Developer-Facing Portal (The "Front Door")

• Backstage — Created by Spotify and now a CNCF graduated project, Backstage is the undisputed open-source giant for developer portals. It gives you a central software catalog, TechDocs (documentation-as-code), and a scaffolder for golden-path templates.
  • Caveat: It is a framework , not an out-of-the-box product. Expect to invest TypeScript/Node.js engineering hours into maintaining plugins and upgrades.
• Alternative Open-Source Choice: OpenChoreo — A newer CNCF sandbox project that bundles a ready-to-run Kubernetes developer platform rather than raw framework scaffolding.

Phase 2: The Infrastructure & Orchestration Engine (The "Brain")

• Crossplane — Turns your Kubernetes clusters into a universal control plane. Instead of writing raw Terraform wrappers for every database or bucket request, Crossplane lets you expose cloud resources as Kubernetes Custom Resource Definitions (CRDs) that reconcile continuously.
• Argo CD — The de facto declarative GitOps continuous delivery tool for Kubernetes. It handles the actual synchronization between your desired state repository and your runtime clusters.

Phase 3: Guardrails & Policy Enforcement

• Kyverno — A Kubernetes-native policy engine designed to act as guardrails for your platform. You can use it to validate, mutate, and generate configurations, ensuring developers don't provision insecure or non-compliant infrastructure through self-service paths.

A Pragmatic Strategy to Start

1. Don't build everything at once. Start with a simple GitOps pipeline (Argo CD) and a single golden-path template.
2. Evaluate your team's bandwidth. If your team has strong TypeScript/React skills and wants deep customization, start with Backstage . If you want a catalog-and-self-service layer fast without running heavy portal infrastructure yourself, consider checking out if a managed tier or a commercial catalog-first alternative fits your timeline better.

To help narrow down the right architectural footprint, tell me:

• What does your current deployment setup look like (Kubernetes-heavy, VMs, serverless, or hybrid)?
• How many platform/DevOps engineers are available to maintain the tooling?

If you're building an IDP from open-source components, I’d avoid trying to find one “IDP product.” A good platform is usually a thin developer experience layer over a few strong primitives.

My 2026 starting stack

The key is not to deploy all of these on day one.

1. Start with Backstage

Backstage is probably the best open-source starting point for the developer-facing portion of an IDP. Its core pieces are the Software Catalog, Software Templates, and TechDocs.

The important thing is to make the portal answer:

“What do I own, how do I deploy it, what dependencies does it have, and how do I create another one?”

rather than becoming a giant dashboard.

I'd initially implement:

• Service catalog + ownership
• Golden-path templates
• Links to CI/CD and observability
• TechDocs
• Basic scorecards/metadata

Backstage templates can actually generate repositories and standardize things like language, CI, Dockerfiles, deployment configuration, ownership, and documentation.

2. Use OpenTofu for infrastructure

If your platform needs to provision AWS/Azure/GCP resources, OpenTofu is a strong open-source foundation.

It gives you the familiar write → plan → apply workflow, reusable modules, state management, and providers for infrastructure and SaaS systems.

The important IDP design decision is:

Don't expose OpenTofu directly to application developers.

Instead:

Developer
    ↓
Backstage
    ↓
Golden path
    ↓
Platform API / automation
    ↓
OpenTofu modules
    ↓
Cloud infrastructure

The platform team owns the complexity; developers select things like:

service: payments-api
database: postgres
environment: production
region: us-east-1

rather than writing VPC and IAM configuration.

3. Add Crossplane when you need a real platform API

This is where I'd distinguish a developer portal from an actual platform.

Crossplane lets you build custom APIs on top of Kubernetes and use them to provision/manage cloud resources. Its current model is explicitly aimed at building control planes and higher-level abstractions.

For example, instead of exposing:

aws:
  vpc: ...
  subnet: ...
  iam: ...
  rds: ...

you can expose something conceptually like:

apiVersion: platform.example.com/v1
kind: PostgreSQLDatabase
spec:
  size: small
  environment: production

Crossplane then translates that abstraction into the underlying infrastructure.

That's extremely powerful—but don't introduce Crossplane merely because you're building an IDP. If OpenTofu plus automation solves your initial use cases, start there.

4. Use Argo CD for Kubernetes delivery

If Kubernetes is part of your platform, Argo CD is the obvious open-source GitOps layer I'd evaluate first.

It treats application configuration and environments as declarative, version-controlled state and continuously reconciles Kubernetes toward that state.

A common flow becomes:

Backstage
   ↓
Create service
   ↓
Git repository
   ↓
CI builds image
   ↓
GitOps repository updated
   ↓
Argo CD
   ↓
Kubernetes

This separation is useful: Backstage is the UX, Git is the desired-state interface, and Argo is the reconciler.

The stack I'd actually build

For a new platform team, I'd phase it like this:

Phase 1 — Developer experience

Backstage
├── Catalog
├── Templates
└── TechDocs

Give developers one excellent golden path—for example:

“Create a production-ready REST service.”

Have that template create the repo, CI pipeline, Dockerfile, Kubernetes manifests/Helm, ownership metadata, docs, monitoring hooks, and deployment configuration.

Phase 2 — Self-service infrastructure

Backstage
    ↓
Platform automation
    ↓
OpenTofu
    ↓
Cloud

Add things like databases, buckets, queues, DNS, IAM roles, and environments.

Phase 3 — Kubernetes control plane

Backstage
    ↓
Crossplane APIs
    ↓
Cloud + Kubernetes

Introduce Crossplane when you have enough repeated infrastructure patterns that creating proper platform APIs starts paying off.

Phase 4 — GitOps

Backstage → Git → Argo CD → Kubernetes

Make deployment boring, reproducible, auditable, and self-healing.

What I would not build initially

I'd resist the temptation to assemble 20 CNCF projects.

In particular, don't start by building:

• a custom portal
• a custom Kubernetes operator
• a custom provisioning system
• a custom deployment system
• an elaborate platform abstraction language
• dozens of Backstage plugins

Your first milestone should be one golden path that developers genuinely prefer over doing the work themselves.

The most important architectural principle is:

Backstage should be the front door, not the platform itself.

Backstage gives you the catalog, UX, templates and documentation; OpenTofu/Crossplane/Argo CD provide the actual control and automation underneath it. That separation keeps the IDP from turning into a giant bespoke application.

If I were starting a platform team from scratch today, my default would be Backstage + OpenTofu + Argo CD + Kubernetes, adding Crossplane only once the need for higher-level infrastructure APIs becomes clear.

Building an internal developer platform (IDP) requires a strong foundation. Here are the best open-source tools categorized by their core function in the platform ecosystem:

• Backstage - Created by Spotify, this is the leading open-source developer portal. It acts as a centralized "pane of glass" for software catalogs, documentation, templates (scaffolder), and plugins.
• Port - While traditionally commercial, Port has open-source components and agent-based cataloging, though for a pure OSS portal, Backstage is the heavy favorite. (Note: stick to Backstage for a 100% open-source core portal).
• Crossplane - Turns your Kubernetes cluster into a control plane, allowing platform engineers to manage cloud infrastructure using Kubernetes-native declarative APIs and composite resources.
• Argo CD - The industry-standard declarative, GitOps continuous delivery tool for Kubernetes, essential for automating application deployments within your IDP.
• Humanitec - A commercial orchestrator, but if you want an open-source equivalent for environment and workload management, combining Kratix or custom operators with Argo CD is common.
• Kratix - An open-source framework by Syntasso for building internal developer platforms, letting you turn any Kubernetes cluster into a platform that delivers "Promises" (composable services) to developers.
• Otoole / Config Management tools - Tools like Kustomize or Helm for templating and managing application configurations consistently across environments.

To help you narrow down the stack, could you share:

• Are you aiming to build around a Kubernetes-native architecture?
• Do you need a Developer Portal (like Backstage) first, or Infrastructure Provisioning tools?

If you're building an IDP from scratch, I'd avoid trying to find one tool that does everything. The strongest open-source approach is a small set of composable primitives, with your platform team owning the developer-facing abstractions.

My default open-source stack

1. Backstage — the developer experience layer

Backstage is probably my first choice for the front door of the IDP.

It gives you a software catalog, ownership metadata, templates/scaffolding, and TechDocs. Its plugin architecture also lets you integrate the rest of your platform.

The important architectural distinction is:

Backstage should be the UI/API experience, not the thing that actually provisions your infrastructure.

For example:

Create service → Backstage template → Git repo → CI → Argo CD → Kubernetes

and:

Create PostgreSQL → Backstage → platform API → Crossplane → cloud database

That's a much cleaner separation than stuffing infrastructure logic into Backstage plugins.

2. Crossplane — the platform API

Crossplane is the tool I'd investigate most seriously if your goal is a real platform, rather than a collection of scripts.

Crossplane lets you define your own APIs/abstractions and have controllers reconcile them into underlying infrastructure. You can therefore expose something like:

apiVersion: platform.example.com/v1
kind: Application
spec:
  environment: production
  database:
    size: medium
  ingress:
    public: true

without exposing developers to AWS/GCP/Azure primitives.

That's exactly the "platform as a product" model: your platform team owns the API and guardrails, while developers consume a relatively small set of golden-path abstractions. Crossplane explicitly supports this control-plane/API approach.

3. OpenTofu — infrastructure foundation

OpenTofu is the obvious open-source IaC choice if you're starting fresh or want a Terraform-compatible ecosystem.

It supports cloud and on-prem infrastructure through providers and has a large existing provider/module ecosystem.

I'd use it for things such as:

• Kubernetes clusters
• VPC/networking
• IAM foundations
• DNS
• Cloud accounts/projects
• shared platform infrastructure

Then use Crossplane above it where you need a self-service API.

You don't necessarily need to make Crossplane replace OpenTofu everywhere.

4. Argo CD — deployment engine

Argo CD is my default choice for Kubernetes application delivery.

It's a GitOps controller that continuously compares the desired state in Git with live Kubernetes state and reconciles differences. It supports Helm, Kustomize, Jsonnet and plain manifests.

A good IDP shouldn't ask developers to understand:

kubectl
helm
Kustomize
Argo ApplicationSets
cluster credentials
namespace provisioning

Instead:

Developer
   ↓
Backstage
   ↓
"Deploy service"
   ↓
Git
   ↓
Argo CD
   ↓
Kubernetes

The platform owns the complexity.

5. Kyverno — guardrails

I'd add a policy engine once you have the basic golden path working.

For example:

• every production workload must have resource limits
• only approved container registries
• no privileged containers
• required labels/owners
• approved ingress classes
• required security context
• approved cloud regions
• mandatory cost-center metadata

The key principle is paved roads, not walls.

Let developers move quickly inside the platform's supported paths, and use policy to prevent genuinely dangerous configurations.

6. OpenTelemetry — make observability part of the platform

OpenTelemetry is an excellent platform primitive because it keeps your application teams independent of a particular observability vendor.

It provides vendor-neutral APIs/SDKs and a Collector for receiving, processing and exporting telemetry.

Your platform can therefore provide:

New service
   ↓
standard instrumentation
   ↓
OpenTelemetry
   ├── metrics
   ├── traces
   └── logs

and let the underlying backend evolve independently.

---

What I'd actually build first

I wouldn't deploy all of those on day one.

I'd start with:

Phase 1

GitHub/GitLab
      │
      ├── CI
      │
      ↓
   Argo CD
      │
      ↓
 Kubernetes

plus Backstage as the developer portal.

Get one golden path working extremely well:

"Create a service → get repo → CI → deploy to dev → promote to production → get docs/ownership/observability automatically."

Then add:

Phase 2

                 Backstage
                 /       \
                ↓         ↓
          Application   Infrastructure
                ↓         ↓
             Argo CD   Crossplane
                ↓         ↓
             Kubernetes / Cloud

Then add policy, secrets, observability, cost management, environments, and more sophisticated platform APIs.

One thing I'd strongly avoid

Don't start by building a giant "platform" with 30 Kubernetes operators and a huge Backstage customization.

Your first IDP should answer perhaps 5 questions extremely well:

1. How do I create a service?
2. How do I deploy it?
3. How do I get an environment?
4. How do I get the infrastructure I need?
5. How do I know whether it's healthy and who owns it?

If developers can accomplish those without becoming Kubernetes/IAM/Terraform experts, you're building an IDP rather than merely exposing your infrastructure through another UI.

If I were starting today, my shortlist would be: Backstage + Argo CD + Crossplane + OpenTofu + Kyverno + OpenTelemetry, with Kubernetes underneath. The exact mix changes if you're not Kubernetes-centric, but that is a very strong open-source starting architecture.