GitOps.dk

Enterprise Internal Developer Platform

Portal, delivery core and fleet as one coherent platform.

GitOps.dk

A common failure mode is to buy a portal and call it a platform. The portal is the front door — this architecture is the building behind it: a software catalog that reflects reality, a delivery core that enforces it, and a fleet that runs it.

The portal and the catalog

The catalog is only useful while it is true. Every entry is generated from the same repositories that deliver the software — ownership, dependencies, SLOs and documentation live next to the code and surface in the portal automatically. A catalog maintained by hand is a wiki with better fonts, and it decays at wiki speed.

Reference architectureEnterprise internal developer platform

Portal

The front door. Displays state; never owns it.

  • Software catalog (generated)
  • Ownership and SLOs
  • Documentation
  • Self-service
Every fact backed by

Delivery core

One reconciliation-based delivery system for every team.

  • Declarative environments
  • Progressive promotion
  • Policy and SLO gates
  • Audit trail = commit history
Runs on

Fleet

Clusters as a fleet, not pets with hostnames.

  • One definition of a compliant cluster
  • Continuous convergence
  • Adding a region = a pull request
Delivered to teams as

Paved roads

Templates that explain themselves and are deprecated deliberately.

  • Service templates
  • Docs-as-code
  • Versioned deprecation

RuleThe portal displays state; it never owns it. Every fact shown has a reconciled source of truth behind it, or the portal becomes the drift.

A portal that displays generated truth, a single reconciliation-based delivery core beneath it, a fleet converged toward one definition of a compliant cluster, and versioned paved roads.

The delivery core

Underneath, one reconciliation-based delivery system serves every team: declarative environments, progressive promotion gated by policy and SLOs, and an audit trail that is simply the commit history. Teams do not build pipelines; they inherit a delivery capability the way they inherit the corporate network.

The fleet

Clusters are managed as a fleet, not as pets with hostnames. One definition of 'a compliant cluster' exists in Git; every cluster is continuously converged toward it. Adding a region is a pull request. Losing a cluster is an inconvenience, not an incident review.

Paved roads and templates

  • Service templates: production-wired from the first commit — delivery, observability, security, cost tags.
  • Documentation-as-code: the template ships with its own docs, so the paved road explains itself.
  • Deprecation policy: templates are versioned and migrated deliberately — no team left on an unmaintained road.

The result is an IDP that survives its own success: growth adds tenants, not entropy, because every layer reconciles toward declared truth instead of accumulating exceptions.

Turning these ideas into a platform?

For platforms where failure has consequences.

Start an Architecture Conversation