Skip to content

PATTERN Cited by 1 source

Developer portal as interface

Pattern

An internal developer platform exposes its capabilities through one intuitive frontend — the developer portal — that hides all underlying tooling (Kubernetes, Crossplane, OPA, ArgoCD, CI/CD, IAM, …) behind a unified self-service surface. Application teams never see the machinery; they see a portal that provisions environments, deploys services, and surfaces status.

The portal is the platform team's deliverable. The internal substrate can be replaced without rewriting tenant-facing workflows — only the portal contract matters to them.

Canonical framing (Santander Catalyst)

"The platform's in-house frontend was developed as an intuitive developer portal, offering a unified interface for all provisioning and resource management needs." (Source: sources/2026-02-26-aws-santander-catalyst-platform-engineering)

Why a portal, not a wiki of internal tools

Without a developer portal, the platform team typically ships:

  • A kubectl context + RBAC matrix
  • A Crossplane XRD catalog in a Git repo
  • An ArgoCD UI for the one cluster users should touch
  • A ticket queue for everything else
  • A wiki page that stitches the above together

Each of these surfaces has its own auth model, UX, and terminology. Application teams end up juggling N platform tools + memorizing which one to use for which task; platform teams end up as a permanent helpdesk.

The portal absorbs this into one place: one auth, one UX, one terminology. "Self-service" becomes real instead of aspirational.

What the portal typically surfaces

  • Catalog of provisionable things — backed by the stacks catalog (patterns/crossplane-composition in Santander Catalyst's case) / golden paths (patterns/golden-path-with-escapes)
  • Environment + service lifecycle — create / update / retire flows with status and links to logs / metrics / traces
  • Policy gate output — why a request was rejected (patterns/policy-gate-on-provisioning in Santander Catalyst's case)
  • Ownership + service catalog — who runs what, who to page
  • Documentation + runbooks — contextual to the thing the user is looking at

Relation to other platform-engineering patterns

The portal is the interface layer. The other platform- engineering patterns in the wiki are substrate layers behind it:

Caveats

  • Portal rot. If the portal isn't maintained in lockstep with the substrate, it drifts into "use the real tool directly" — now you have N+1 surfaces instead of one.
  • Portal lock-in. Building your own portal is a one-way door. OSS options (Backstage, Port, self- hosted Cortex) reduce this risk but still require integration work for every substrate capability the portal exposes.
  • UX debt is real debt. Platform teams underinvested in UX produce portals worse than kubectl; the pattern requires frontend investment the platform team may not initially have.

Seen in

  • sources/2026-02-26-aws-santander-catalyst-platform-engineering — Santander Catalyst's in-house developer portal is the single tenant-facing surface over the EKS control plane cluster (which internally runs Crossplane + ArgoCD + OPA); all provisioning and resource-management flows go through the portal. The portal is explicitly in-house (not a Backstage-class OSS adoption), fitting the canonical shape of large-enterprise platform teams that treat the portal as product.
Last updated · 200 distilled / 1,178 read