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

If you're building an IDP from scratch, I'd resist trying to find one tool that is "the IDP." A good open-source stack is usually a few focused primitives:

Layer	Tool	What I'd use it for
Developer portal / catalog	Backstage	Service catalog, ownership, templates, docs, developer UI
Kubernetes delivery	Argo CD	GitOps deployment and reconciliation
Infrastructure APIs	Crossplane	Exposing cloud resources as platform APIs
IaC	OpenTofu	Provisioning where Crossplane isn't appropriate
Secrets	External Secrets Operator	Pulling secrets from Vault/cloud secret managers
Policy	Kyverno	Guardrails, admission policies, compliance
Observability	Prometheus + Grafana	Metrics, dashboards, service health
Developer environments	Dev Containers	Reproducible local environments

What I'd actually start with

1. Backstage + Git + CI/CD

Backstage is the natural front door: its catalog tracks services, ownership and dependencies; Software Templates implement golden paths; and TechDocs gives you docs-as-code.Backstage+1

backstage.io

Don't initially build elaborate custom plugins. Get one golden path working:

"Create a service" → repo → CI → container → deployment → catalog entry → documentation That single workflow will teach you far more about what your platform actually needs than building a giant portal upfront.

2. Argo CD for deployment

Make Git the desired-state interface and have Argo CD reconcile Kubernetes. This keeps your IDP's provisioning logic separate from the actual deployment mechanism.

A useful mental model is:

Developer
    │
    ▼
Backstage
    │
    ├── creates repo
    ├── creates manifests/config
    └── registers service
             │
             ▼
          Git repo
             │
             ▼
          Argo CD
             │
             ▼
        Kubernetes

3. Add Crossplane only when you need infrastructure self-service

Crossplane becomes interesting when you want developers to request things like:

kind: PostgresInstance
spec:
  size: small
  environment: production

rather than asking them to understand RDS/VPC/security-group/IAM implementation details.

That is where an IDP starts becoming a platform API, rather than merely a portal.

I wouldn't introduce Crossplane on day one unless infrastructure provisioning is already a major pain point. It adds substantial platform-engineering surface area.

4. Keep OpenTofu for the infrastructure that doesn't belong in Crossplane

You don't need religious purity here. A very reasonable architecture is:

                    Backstage
                       │
              ┌────────┴────────┐
              ▼                 ▼
        Service templates   Infra requests
              │                 │
              ▼                 ▼
          Git / CI          Crossplane
                                │
                       ┌────────┴────────┐
                       ▼                 ▼
                    AWS/GCP           Kubernetes

while OpenTofu handles infrastructure that is better represented as conventional IaC.

The part I'd prioritize most: golden paths

The biggest mistake I see in IDP architecture is starting with technology rather than developer journeys.

Start with perhaps three:

• Create a new API service
• Create a worker/consumer
• Create a database-backed service

Each template should produce a genuinely usable production skeleton:

service/
├── src/
├── tests/
├── Dockerfile
├── helm/
├── catalog-info.yaml
├── mkdocs.yml
├── docs/
├── CI configuration
└── security/...

Backstage's templates can generate these consistently, and TechDocs can live alongside the source code.Backstage+1

A pragmatic maturity path

I'd build it in roughly this order:

Phase 1 — Developer experience

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

Get developers from "I need a service" → "my service is running" with essentially no platform-team ticket.

Phase 2 — Platform APIs

Add:

Crossplane
External Secrets
Kyverno

Now you can offer capabilities such as:

Postgres
Redis
S3 bucket
Kafka topic
DNS
TLS certificate
IAM identity

as standardized platform abstractions.

Phase 3 — Reliability and governance

Add:

Prometheus
Grafana
OpenTelemetry
Trivy
Kyverno
service scorecards

Then your catalog can answer not just:

"What services exist?" but:

"Who owns this service, where is it deployed, is it healthy, does it meet our standards, and how do I operate it?"

One alternative worth investigating

If Backstage feels too heavyweight for your organization, there are newer open-source portals worth evaluating, including ForgePortal. It positions itself as a simpler Backstage alternative with catalog, scaffolding and scorecards.GitHub

I'd still start by evaluating Backstage because its ecosystem and capabilities are unusually broad, but I wouldn't assume it is automatically the right portal for every team.

My "starter stack"

If I were setting up a new platform team today, I'd start with:

┌─────────────────────────────────────────┐
│              Backstage                  │
│  Catalog · Templates · TechDocs · UI   │
└───────────────────┬─────────────────────┘
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       Git/CI              Platform APIs
          │                   │
          ▼              Crossplane
       Argo CD                 │
          │              Cloud resources
          ▼
     Kubernetes
          │
     ┌────┴─────┐
     ▼          ▼
 Prometheus   Grafana

Don't build all of this at once. The first milestone I'd target is a single excellent golden path. Once developers actually use it, let their friction tell you whether the next investment should be infrastructure APIs, secrets, policy, observability, environments, or something else.

If you tell me your cloud (AWS/GCP/Azure), Kubernetes situation, CI system, and roughly how many developers/services you have, I can turn this into a concrete open-source reference architecture with repo structure and a phased implementation plan.

If you’re building an IDP from scratch, I’d resist assembling a giant platform on day one. Start with a small golden path and add components only when they remove real developer toil.

A strong open-source starting stack

Capability	Tool	Why I’d consider it
Developer portal/catalog	Backstage	Best-known OSS foundation for service catalog, ownership, templates, docs, and plugins.Backstage+1
Infrastructure as Code	OpenTofu	Open-source IaC with a large provider/module ecosystem and Terraform-compatible workflows.OpenTofu+1
Platform control plane	Crossplane	Excellent when you want developers to consume higher-level APIs such as Postgres, Bucket, or Application rather than raw cloud resources.Crossplane Documentation+1
Deployment / GitOps	Argo CD	A natural Kubernetes deployment layer if you're adopting GitOps.
Kubernetes networking	Cilium	eBPF-based networking, security policy, and Hubble observability.Cilium Documentation
Kubernetes ingress/API	Gateway API	A Kubernetes-native, role-oriented abstraction for traffic routing and infrastructure provisioning.Kubernetes
CI/CD automation	Dagger	Makes build/test/deploy pipelines programmable and reproducible rather than tying everything to one CI vendor.GitHub
Feature flags	OpenFeature	Vendor-neutral API so application code isn't coupled to a particular flagging implementation.OpenFeature+1

If I were starting today

I'd initially build around:

Backstage → OpenTofu → Kubernetes → Argo CD → Crossplane

with Cilium if Kubernetes networking/security is part of your platform responsibilities.

The important architectural distinction is:

• Backstage = developer experience / front door
• Crossplane = platform API / control plane
• OpenTofu = infrastructure provisioning
• Argo CD = continuous reconciliation/deployment
• Kubernetes = application runtime

Backstage itself isn't the platform—it gives developers a consistent interface to the platform. Its catalog and templates are particularly useful for establishing ownership and "golden paths."Backstage+1

Don't build everything into Backstage

A common IDP failure mode is turning Backstage into a giant internal admin application.

Instead, I'd aim for a flow like:

                    Developer
                        │
                        ▼
                  ┌───────────┐
                  │ Backstage │
                  │  Portal   │
                  └─────┬─────┘
                        │
              "Create a new service"
                        │
                        ▼
                ┌──────────────┐
                │ Golden Path  │
                │   Template   │
                └──────┬───────┘
                       │
          ┌────────────┼─────────────┐
          ▼            ▼             ▼
       Git repo      CI/CD       Platform API
                                    │
                                    ▼
                               Crossplane
                                    │
                            ┌───────┼───────┐
                            ▼       ▼       ▼
                           DB     Queue    Bucket

The key idea is that developers interact with intent, rather than implementation details.

For example:

kind: Database
metadata:
  name: orders-db
spec:
  engine: postgres
  size: small
  environment: production

The platform team can subsequently change how that database gets provisioned without forcing application teams to rewrite their workflows.

That's where Crossplane becomes interesting: it lets you define your own declarative APIs and hide infrastructure complexity behind them.Crossplane Documentation

What I'd build first

Don't start with 30 platform capabilities. Start with one excellent golden path:

1. Developer clicks Create Service.
2. Backstage creates the repository.
3. Standard repo structure is generated.
4. CI is configured automatically.
5. Service gets a Kubernetes deployment definition.
6. Argo CD deploys it.
7. Backstage registers the service automatically.
8. Developer can see ownership, docs, deployment status, and links from one place.

Then add the next golden path:

"Give my service a PostgreSQL database."

Then:

"Give my service an S3-compatible bucket."

Then:

"Create a production environment."

That progression gives you a platform that is actually driven by developer workflows rather than by infrastructure components.

One important design principle

I'd make your platform APIs the long-term abstraction boundary, not your portal.

Backstage is replaceable. Argo CD is replaceable. Even Kubernetes is replaceable.

Your internal concept of:

"A team can request a production database with these guarantees" is the valuable part.

Crossplane is particularly well suited to that model because its purpose is building control planes with custom APIs, policies, permissions, and reconciliation.Crossplane Documentation+1

If you tell me your environment (AWS/Azure/GCP/on-prem, Kubernetes or not, GitHub/GitLab, and roughly how many developers/services), I can turn this into a concrete OSS IDP reference architecture + repo structure + first 90-day implementation plan.

Building an Internal Developer Platform (IDP) is less about buying a single magical product and more about assembling a cohesive stack . A solid open-source IDP typically breaks down into four functional layers: The Portal/User Interface, The Orchestrator/Control Plane, Infrastructure Provisioning (IaC) , and Deployment/GitOps.

The top open-source tools to start building your IDP foundation are organized by layer below:

1. The Portal Layer (The "Single Pane of Glass")
   • Backstage — Originally created by Spotify and now a graduated CNCF project, it is the de facto standard open-source developer portal. It gives you a centralized software catalog, tech docs, and a plugin architecture to build custom golden paths. (Warning: It requires significant maintenance and TypeScript/React overhead to customize, but it is immensely extensible).linkedin.com
2. The Platform Orchestrator (Resource & Environment Management)
   • Humanitec or Score (Open-source workload specification) — While full platform orchestrators are often commercial, using an open specification like Score lets developers define workloads agnostic of infrastructure, which your platform backend can then interpret. It bridges the gap between app code and infrastructure configurations.cncf.io
3. Infrastructure & Composition Layer (The Provisioning Engine)
   • Crossplane — A CNCF project that turns Kubernetes into a universal control plane. Instead of writing raw Terraform triggered by webhooks, Crossplane allows platform engineers to build custom composite APIs ( Paved Roads ) so developers can provision cloud resources natively via Kubernetes CRDs.
   • OpenTofu — The open-source, community-driven successor to Terraform. If your IDP needs to execute infrastructure-as-code scripts under the hood when a developer requests a database or a cluster, OpenTofu is the go-to choice to avoid licensing friction.
4. The Deployment & Delivery Layer (GitOps)
   • Argo CD — The industry standard for declarative, GitOps-based continuous delivery on Kubernetes. Your IDP can dynamically generate application manifests, commit them to an app-Repo, and let Argo CD safely sync those changes to your target clusters.

To help narrow down the best starting architecture, tell me:

• Are your workloads running strictly on Kubernetes , or do you need to provision traditional VMs/Serverless resources too?
• Does your team have frontend/React capacity to customize a portal like Backstage?

If you're building an IDP from scratch, I'd avoid starting with a giant collection of tools. The most useful approach is to assemble a small platform stack around a developer portal, Kubernetes/GitOps, infrastructure provisioning, and golden paths.

A strong open-source starting stack

Capability	Tool I'd start with	Why
Developer portal/catalog	backstage.io	Mature catalog, ownership, templates, plugins
Platform orchestration	kratix.io	Build reusable platform capabilities and expose them as APIs
Kubernetes delivery	argo-cd.readthedocs.io	Strong GitOps foundation
Infrastructure as code	opentofu.org	Open-source Terraform-compatible IaC
Kubernetes infrastructure APIs	crossplane.io	Turn infrastructure into self-service Kubernetes APIs
Secrets	external-secrets.io	Connect Kubernetes workloads to existing secret stores
Policy	kyverno.io	Kubernetes-native policy and guardrails
Observability	opentelemetry.io	Vendor-neutral telemetry
Metrics/logging	prometheus.io +grafana.com	Well-established OSS observability stack

1. Backstage for the developer experience

I'd seriously consider Backstage as the front door.

Its Software Catalog gives you a central inventory of services, libraries, websites, pipelines, ownership, relationships, etc., using metadata stored alongside source code.Backstage

Its Scaffolder lets you create golden paths such as:

Create a Go service → Git repo → CI pipeline → Kubernetes manifests → deployment → monitoring → documentation → ownership metadata And TechDocs gives you docs-as-code directly in the portal.Backstage+1

backstage.io

Important: don't make Backstage the platform itself. Treat it as the UX/API entry point into your platform.

2. Argo CD for GitOps

Use Argo CD as the deployment engine.

A useful architecture is:

Developer
   │
   ▼
Backstage
   │
   ▼
Golden Path / Platform API
   │
   ▼
Git repository
   │
   ▼
Argo CD
   │
   ▼
Kubernetes

That gives you a clean separation between requesting a platform capability and actually reconciling infrastructure/application state.

3. OpenTofu + Crossplane for infrastructure

There are two complementary approaches here.

OpenTofu is a good choice when you want conventional IaC:

AWS/Azure/GCP
      ▲
      │
   OpenTofu
      ▲
      │
 Platform pipelines

Crossplane becomes interesting when you want infrastructure to behave like a Kubernetes-native API:

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

The developer doesn't need to know whether that ultimately means RDS, Cloud SQL, Azure Database, etc.

I'd start with OpenTofu unless you have a clear reason to make infrastructure Kubernetes-native. Crossplane is powerful, but it adds another abstraction layer that you need to operate.

4. Kratix if you want a proper platform orchestration layer

Syntasso's Kratix is particularly interesting if your goal is to build reusable platform capabilities rather than simply glue tools together.

Kratix describes its model around reusable Promises, workflows, destinations and lifecycle/policy management. It can expose platform capabilities to portals such as Backstage.Kratix Docs+1

For example:

"Give me a PostgreSQL database"
             │
             ▼
          Kratix
             │
       ┌─────┴─────┐
       ▼           ▼
    Policy      Workflow
       │           │
       └─────┬─────┘
             ▼
        Cloud resource

I'd investigate Kratix if you're building a platform team/platform-as-a-product, rather than just assembling CI/CD.

5. OpenChoreo is worth evaluating as an alternative

OpenChoreo is a different proposition: rather than assembling an IDP from many independent components, it provides a more complete Kubernetes-oriented platform.

It currently describes itself as an open-source developer platform with a Backstage-powered portal, CI/CD, GitOps, observability, multi-tenancy and platform abstractions.OpenChoreo+1

So I'd evaluate:

Build it yourself:
Backstage + Argo CD + OpenTofu/Crossplane + ...
             vs.
More integrated:
OpenChoreo

The former gives you more architectural control; the latter potentially gets you to a working platform faster.

What I'd actually build first

For a team starting today, my v1 would be deliberately boring:

                    ┌──────────────┐
                    │  Developers  │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │   Backstage  │
                    │ Catalog + UX │
                    └──────┬───────┘
                           │
                  Golden paths / APIs
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
        ┌───────────┐             ┌──────────┐
        │   Git     │             │ OpenTofu │
        │           │             │          │
        └─────┬─────┘             └────┬─────┘
              │                        │
              ▼                        ▼
        ┌───────────┐             Cloud APIs
        │  Argo CD  │
        └─────┬─────┘
              │
              ▼
        ┌───────────┐
        │ Kubernetes│
        └─────┬─────┘
              │
       ┌──────┴──────┐
       ▼             ▼
 OpenTelemetry    Prometheus/
                  Grafana

Then add Kyverno + External Secrets once the basic workflow works.

The key design principle

Don't measure the IDP by how many tools you've deployed.

Measure whether a developer can go from:

"I need a production service" to:

running service + database + DNS + TLS + CI/CD + observability + ownership + documentation with a small number of intentional decisions.

That's the real "platform" abstraction.

If you're starting with Kubernetes + AWS/Azure/GCP and roughly 10–100 engineering teams, I can also lay out a concrete reference architecture, repo structure, Backstage templates, and first 90-day implementation plan using entirely open-source components.

Building an Internal Developer Platform (IDP) from scratch can easily turn into a trap of maintaining more internal software instead of helping others ship code. To avoid this, the smartest move is to assemble an IDP out of proven open-source components that cover three main layers: the Portal (the UI/catalog), the Orchestrator (the backend logic/actions) , and the Infrastructure/GitOps layer.

Here are the best open-source tools to start your IDP stack with, categorized by their role:

• 1. Backstage (The Portal & Service Catalog)
     Created by Spotify and now a CNCF graduated project, Backstage is the undisputed open-source heavyweight for the developer-facing UI. It gives you a central software catalog to track ownership, APIs, and documentation (TechDocs ), plus a massive plugin ecosystem. Caveat: It is a framework rather than an out-of-the-box product, meaning your team will spend time writing TypeScript/Node.js to glue plugins together and maintain it.linkedin.com+2
• 1. Argo CD (The GitOps & Deployment Engine)
     For continuous delivery and keeping your cluster state synced with your git repositories, Argo CD is the gold standard in the Kubernetes ecosystem. Your IDP can trigger actions that commit changes to a manifest repo, and Argo CD handles the heavy lifting of safely rolling it out to production with automated rollbacks and clear visibility.
• 1. Crossplane (The Infrastructure Abstraction Layer)
     If you want to provide self-service infrastructure (like spinning up an RDS database or an S3 bucket) without writing raw Terraform scripts for every developer request, Crossplane lets you turn your Kubernetes cluster into a control plane. You can define custom composite resource definitions (XRDs) that act as your company’s "golden paths," abstracting cloud provider complexities away from developers.
• 1. OpenTofu or Pulumi (The Infrastructure as Code Foundation)
     If your platform still relies heavily on traditional IaC to provision underlying cloud resources via self-service templates, skip legacy licensing restrictions and opt for open-source alternatives. OpenTofu provides a true open-source fork of Terraform, while Pulumi lets developers write infrastructure using general-purpose programming languages like TypeScript or Python.

To help narrow down the right starting architecture, could you tell me:

• What does your current infrastructure footprint look like (pure Kubernetes, AWS/GCP, or a hybrid setup)?
• Do your developers prefer UI-driven portals , or a CLI/API-first approach?

For a platform engineering team building an internal developer platform (IDP), I’d avoid thinking of an IDP as “a portal.” The portal is only one layer. A useful IDP usually combines:

1. Developer experience layer (catalog, templates, self-service)
2. Automation/control plane (provisioning and orchestration)
3. Delivery layer (CI/CD + GitOps)
4. Governance (policies, security, standards)
5. Observability (health, ownership, reliability)

A strong open-source starting stack looks like this:Kubernetes Recipe Book+1

Recommended open-source IDP starter stack

Capability	Tool	Why start here
Developer portal	Backstage	Service catalog, templates, docs, plugins, golden paths
Container platform	Kubernetes	Common substrate for self-service platforms
GitOps delivery	Argo CD	Declarative app delivery and environment reconciliation
Infrastructure abstraction	Crossplane	Expose cloud resources as developer-friendly APIs
IaC	OpenTofu or Terraform	Provision foundational infrastructure
Packaging	Helm	Standardize application deployment
Policy	Kyverno	Enforce security and platform rules
Secrets	OpenBao or SOPS	Manage sensitive configuration
Observability	Prometheus and Grafana ecosystem	Metrics, dashboards, service health
Telemetry	OpenTelemetry	Vendor-neutral tracing/metrics/logging

GitHub Catio## My suggested first implementation

Phase 1: Build the "golden path"

Do not start by building a huge portal. Start with one developer workflow:

"Create a new production-ready service" Example flow:

1. Developer opens Backstage
2. Selects "Create Go API service"
3. Template creates: - Git repository

• CI pipeline
• Dockerfile
• Helm chart
• Kubernetes manifests
• Ownership metadata

4. Argo CD deploys it
5. Prometheus/Grafana dashboards appear automatically

This creates visible value quickly.

Phase 2: Add self-service infrastructure

Introduce Crossplane when developers need things like:

• databases
• buckets
• queues
• managed Kubernetes resources
• cloud networking primitives

Instead of exposing:

apiVersion: rds.aws.crossplane.io/v1beta1
kind: Instance

developers request something like:

apiVersion: platform.company.io/v1
kind: Database
spec:
  size: small
  environment: production

The platform team owns the implementation details.

Phase 3: Add governance

Useful additions:

• Kubernetes admission policies with Kyverno
• service ownership metadata
• automated scorecards
• dependency tracking
• vulnerability checks

The goal is:

Make the easiest path the correct path.

Tools I would avoid starting with

Building a custom portal

A custom React portal often becomes a maintenance burden. Backstage exists specifically to avoid rebuilding catalogs, plugins, and scaffolding systems.

Exposing Kubernetes directly

Giving developers kubectl access is not an IDP. It transfers complexity rather than removing it.

Automating everything immediately

Start with 1–3 high-value workflows:

• new service creation
• environment creation
• database provisioning

A practical "80/20" stack

If I were starting an IDP from scratch today:

Backstage
   |
   +-- Templates / Scaffolder
   |
GitHub/GitLab
   |
CI pipeline
   |
Argo CD
   |
Kubernetes
   |
Helm
   |
Crossplane
   |
Cloud APIs

Observability:
Prometheus + Grafana + OpenTelemetry

Policy:
Kyverno

This is close to the common open-source pattern of Backstage + Argo CD + Crossplane + Kubernetes for a self-service platform.Kubernetes Recipe Book+1

One caveat: the right stack depends heavily on your environment. A 20-person engineering org, a regulated enterprise, and a 5,000-developer company will build very different IDPs.

If you share your current stack (AWS/Azure/GCP/on-prem, Kubernetes or not, number of developers, and current CI/CD), I can suggest a more opinionated architecture.

The goal is:

Make the easiest path the correct path.

Tools I would avoid starting with

Building a custom portal

A custom React portal often becomes a maintenance burden. Backstage exists specifically to avoid rebuilding catalogs, plugins, and scaffolding systems.

Exposing Kubernetes directly

Giving developers kubectl access is not an IDP. It transfers complexity rather than removing it.

Automating everything immediately

Start with 1–3 high-value workflows:

• new service creation
• environment creation
• database provisioning

A practical "80/20" stack

If I were starting an IDP from scratch today:

Building an Internal Developer Platform (IDP) is less about buying a single magical product and more about assembling a cohesive paved path from source code to production.

The best open-source tools to start with are categorized below by their core role in your IDP architecture:

1. The Developer Portal (The UI & Catalog)
   • Backstage — Created by Spotify and now a CNCF incubating project, Backstage is the undisputed open-source heavyweight for building developer portals. It gives you a centralized software catalog (for microservices, APIs, and docs) and a template engine ("Software Templates") to bootstrap new services securely.
   • Alternative: If you want something lighter or more data-driven out of the box without writing heavy TypeScript/React plugins, many teams start by mapping Backstage GitHub Plugins or looking at community-driven data models.linkedin.com+1
2. The Deployment & GitOps Engine
   • Argo CD — The gold standard for declarative, GitOps-based continuous delivery on Kubernetes. It syncs the desired state of your applications from Git repositories straight to your clusters, giving developers a clear view of what is deployed where.
   • Alternative: Flux is another exceptional, lightweight, CNCF-native GitOps alternative if you prefer a controller-heavy, highly modular approach over Argo’s UI-centric workflow.linkedin.com+1
3. Infrastructure Provisioning & Abstraction
   • Crossplane — Instead of forcing developers to write raw Terraform, Crossplane lets you turn cloud infrastructure (AWS, GCP, Azure) into custom Kubernetes APIs. This is massive for platform engineers building self-service infrastructure because you can write composite resources that hide cloud complexity from developers.
   • OpenTofu — Since HashiCorp altered its licensing, OpenTofu has emerged as the premier community-driven, truly open-source alternative for Infrastructure as Code (IaC).
   • Pulumi — Great if your team prefers defining infrastructure using real programming languages (TypeScript, Python, Go) rather than HCL or YAML. They also provide open-source reference blueprints for DIY developer platforms.linkedin.com+1
4. Pipelines & Workflows
   • Argo Workflows — A container-native workflow engine for orchestrating parallel jobs, CI/CD pipelines, or complex data/infrastructure provisioning tasks directly inside Kubernetes.
   • Dagger — A programmable CI/CD engine that runs your pipelines as code in containers, making them portable and locally testable.linkedin.com+1

To help narrow down where you should anchor your first proof-of-concept, tell me:

• Are your target workloads primarily Kubernetes-based , or do you need to support VMs and serverless?
• What is the current skill set/size of your platform engineering team?

If you're building an IDP from scratch, I’d resist the temptation to assemble a giant platform immediately. Start with a small golden path: service catalog → infrastructure provisioning → deployment → developer self-service.

My open-source shortlist for 2026 would be:

Layer	Tool	Why I’d consider it
Developer portal	Backstage	Best-established OSS foundation for an internal developer portal
Infrastructure IaC	OpenTofu	Strong Terraform-compatible IaC foundation
Platform control plane	Crossplane	Excellent when you want to expose infrastructure through higher-level APIs
Kubernetes delivery	Argo CD	Mature GitOps deployment layer
Containers/orchestration	Kubernetes	The underlying control plane if you're Kubernetes-based
Secrets	External Secrets Operator	Keeps application secrets integrated with external secret stores
Policy	Open Policy Agent (OPA) / Kyverno	Codify platform/security guardrails
Observability	OpenTelemetry + Prometheus/Grafana	Vendor-neutral telemetry plus metrics/dashboards

1. Backstage — the developer-facing front door

Backstage is probably where I'd start for the portal UX.

It gives you a software catalog, ownership metadata, documentation, templates, and a plugin ecosystem. The CNCF describes it as an open framework for building developer portals, and its catalog can represent services, libraries, data pipelines, websites, ML models, etc.CNCF+1

The important distinction is:

Backstage should be the interface to your platform, not the platform itself. For example:

Developer
    │
    ▼
 Backstage
    │
    ├── "Create a service"
    │       │
    │       ▼
    │    Git repository
    │
    ├── "Create a database"
    │       │
    │       ▼
    │    Platform API / Crossplane
    │
    └── "Deploy"
            │
            ▼
         Argo CD

2. OpenTofu — infrastructure provisioning

OpenTofu is my default OSS IaC recommendation if you're starting fresh.

It gives you declarative infrastructure, plans/applies, reusable modules and a broad provider ecosystem. It's also designed as a drop-in replacement for Terraform workflows.OpenTofu+1

I'd use it for things like:

• VPCs/networks
• Kubernetes clusters
• IAM
• DNS
• databases
• cloud accounts/projects
• foundational shared infrastructure

Don't expose raw OpenTofu to application developers. Your platform team should turn it into higher-level capabilities.

3. Crossplane — when you want a real platform API

Crossplane is particularly interesting if your goal is to build an actual internal cloud/platform API rather than a collection of scripts.

Crossplane lets you create declarative APIs and abstractions over infrastructure. For example, instead of asking a developer to understand AWS RDS, networking, IAM, security groups, backups, etc., you can expose:

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

Your platform owns everything underneath that abstraction.

Crossplane explicitly positions itself as a control-plane framework for platform engineering, with Kubernetes-style APIs and reconciliation.Crossplane Documentation+1

My rule of thumb:

• Simple platform → Backstage + OpenTofu
• Kubernetes-heavy platform with increasingly sophisticated self-service → Backstage + Crossplane + OpenTofu
• Very large platform → Crossplane becomes increasingly attractive as the abstraction layer

Don't adopt Crossplane merely because it's fashionable, though. It adds significant conceptual complexity.

4. Argo CD — delivery

Argo CD is a strong choice for the deployment half of the platform.

It's a declarative GitOps CD system for Kubernetes: application definitions and environments live in version control, while Argo continuously reconciles the desired state.GitHub+1

A good platform flow is:

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

This gives you a very clean separation between build, desired state, and deployment.

The stack I'd actually build

For a new platform team, I'd start with:

                  ┌─────────────────┐
                  │    Backstage    │
                  │ Developer Portal│
                  └────────┬────────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        Service       Infrastructure   Docs/
        Catalog         API           Templates
             │             │
             │             ▼
             │        Crossplane
             │             │
             │       ┌─────┴─────┐
             │       ▼           ▼
             │    Cloud        K8s
             │
             ▼
        Git repository
             │
             ▼
           CI/CD
             │
             ▼
          Argo CD
             │
             ▼
         Kubernetes

Then add:

OpenTelemetry → observability
OPA/Kyverno    → policy
External Secrets → secrets
Prometheus/Grafana → metrics

What I'd not do initially

The biggest IDP mistake is building a platform that is technically impressive but developers don't actually want.

I wouldn't start by building:

• a custom portal
• a custom Kubernetes operator for everything
• dozens of Backstage plugins
• a giant abstraction over every cloud service
• a proprietary deployment system
• a "universal" platform API

Instead, pick one painful developer workflow.

For example:

"A developer should be able to create a production-ready service in under 10 minutes." Your first golden path might create:

New Service
   ↓
Git repo
   +
Dockerfile
   +
CI pipeline
   +
Kubernetes manifests
   +
Argo CD application
   +
observability
   +
standard IAM
   +
documentation
   +
Backstage catalog entry

Once that works beautifully, add database provisioning, then queues, then object storage, etc.

My priority order

If I had to choose only four projects to investigate first:

1. Backstage — developer experience/catalog
2. OpenTofu — infrastructure provisioning
3. Argo CD — application delivery
4. Crossplane — higher-level platform APIs, once your requirements justify it

The key architectural principle is don't make developers learn your infrastructure. Your IDP should turn complicated infrastructure into a small number of safe, opinionated developer-facing capabilities.

If you tell me your environment (e.g. AWS/Azure/GCP, Kubernetes or not, GitHub/GitLab, and roughly how many developers/services), I can sketch a concrete OSS IDP architecture and repo structure for it.

The stack I'd actually build

For a new platform team, I'd start with:

                  ┌─────────────────┐
                  │    Backstage    │
                  │ Developer Portal│
                  └────────┬────────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        Service       Infrastructure   Docs/
        Catalog         API           Templates
             │             │
             │             ▼
             │        Crossplane
             │             │
             │       ┌─────┴─────┐
             │       ▼           ▼
             │    Cloud        K8s
             │
             ▼
        Git repository
             │
             ▼
           CI/CD
             │
             ▼
          Argo CD
             │
             ▼
         Kubernetes

Then add:

OpenTelemetry → observability
OPA/Kyverno    → policy
External Secrets → secrets
Prometheus/Grafana → metrics

What I'd not do initially

The biggest IDP mistake is building a platform that is technically impressive but developers don't actually want.

I wouldn't start by building:

• a custom portal
• a custom Kubernetes operator for everything
• dozens of Backstage plugins
• a giant abstraction over every cloud service
• a proprietary deployment system
• a "universal" platform API

Instead, pick one painful developer workflow.

For example:

"A developer should be able to create a production-ready service in under 10 minutes." Your first golden path might create:

New Service
   ↓
Git repo
   +
Dockerfile
   +
CI pipeline
   +
Kubernetes manifests
   +
Argo CD application
   +
observability
   +
standard IAM
   +
documentation
   +
Backstage catalog entry

Once that works beautifully, add database provisioning, then queues, then object storage, etc.

My priority order

If I had to choose only four projects to investigate first:

1. Backstage — developer experience/catalog
2. OpenTofu — infrastructure provisioning
3. Argo CD — application delivery
4. Crossplane — higher-level platform APIs, once your requirements justify it

The key architectural principle is don't make developers learn your infrastructure. Your IDP should turn complicated infrastructure into a small number of safe, opinionated developer-facing capabilities.

If you tell me your environment (e.g. AWS/Azure/GCP, Kubernetes or not, GitHub/GitLab, and roughly how many developers/services), I can sketch a concrete OSS IDP architecture and repo structure for it.