Schlagwort: Platform Engineering

Veröffentlicht am

Internal Developer Portals 2.0: How AI Copilots Inside Backstage and Port Are Transforming Developer Self-Service

Internal Developer Portals have spent the past three years earning their place in the platform engineering stack. Backstage — now a CNCF Graduated project — established the blueprint: a service catalog, software templates, TechDocs, and a plugin ecosystem exceeding 900 integrations. For many organizations, that was enough. But static catalogs have hit a ceiling. Developers still context-switch between Backstage, Slack, their IDE, and a dozen dashboards to scaffold a service, request infrastructure, or troubleshoot an incident. The portal that was supposed to unify developer experience became just another tab.

2025 and 2026 have introduced a different paradigm: AI copilots embedded directly inside IDPs. Not chatbots bolted onto the side, but intelligent agents that understand your service catalog, your golden paths, and your organizational policies — and let developers interact with infrastructure through natural language instead of form-driven UIs. This is Internal Developer Portals 2.0, and it changes the economics of platform engineering.

From Catalog-Centric to Action-Centric Portals

The first generation of IDPs was catalog-centric. You browsed a list of services, looked up ownership, maybe triggered a pre-built template. The developer experience was better than nothing, but it still required knowing where to click and which template to use. For a senior engineer who helped build the portal, that was fine. For a new hire on day three, it was another maze.

Action-centric IDPs flip the model. Instead of navigating a catalog hierarchy, a developer types:

"Deploy my payment-service to staging with the new database migration"

The AI copilot inside the portal understands the intent, resolves the service from the catalog, identifies the correct deployment pipeline, checks RBAC policies, and either executes or presents a confirmation step. The catalog is still there — it’s the knowledge backbone — but the interaction layer has fundamentally changed.

This isn’t speculative. Port has shipped an AI assistant that queries its internal software catalog and executes self-service actions through natural language. Cortex integrates LLM-driven recommendations directly into its scorecards. Humanitec has taken an API-first approach that makes AI orchestration a first-class integration pattern. Even Backstage itself is seeing community plugins that expose catalog data to AI agents via standardized protocols.

The Knowledge Graph Advantage

What makes IDP-embedded AI fundamentally different from a generic ChatGPT wrapper is context. An Internal Developer Portal already holds a rich knowledge graph:

  • Service dependencies: which services call which, what databases they use, what message queues connect them
  • Team ownership: who owns what, who’s on-call, escalation paths
  • Runbooks and documentation: operational playbooks indexed per service
  • Deployment history: what was deployed when, by whom, with what configuration
  • Scorecards: production readiness, security posture, cost allocation

When an AI copilot has access to this graph, its responses move from generic to surgical. Ask it "Why is checkout-service latency spiking?" and it can correlate recent deployments, check the dependency graph for upstream changes, pull relevant runbooks, and suggest specific remediation steps — all without the developer leaving the portal.

Compare this to ChatOps bots in Slack that operate with minimal context, or IDE-integrated copilots that understand your code but not your infrastructure. The IDP sits at the intersection of code, infrastructure, and organizational knowledge. That’s where AI adds the most leverage.

MCP Servers: The Bridge Between AI Agents and IDP APIs

The technical glue making this possible is increasingly the Model Context Protocol (MCP). Originally open-sourced by Anthropic in 2024 and now seeing broad adoption, MCP provides a standardized interface for AI agents to discover and invoke tools — including IDP APIs.

An MCP server wrapping your Backstage or Port API exposes capabilities like:

  • Querying the service catalog (list services, get owners, check dependencies)
  • Triggering software templates (scaffold a new microservice, provision a database)
  • Reading and updating scorecards
  • Executing self-service actions (deploy, rollback, scale)
  • Fetching TechDocs and runbooks for context

This decouples the AI layer from the IDP implementation. Your platform team maintains the MCP server as a thin adapter. The AI agent — whether it’s embedded in the portal UI, accessible via Slack, or running inside an IDE — connects through the same protocol. You get a single source of truth for what actions are available and what permissions govern them.

For teams already running Backstage, this is particularly powerful. The existing plugin ecosystem handles data aggregation; an MCP server adds an AI-native interaction layer on top without replacing the portal itself.

Scorecards Meet AI Analysis

Scorecards have been one of the quiet successes of the IDP movement. Tools like Backstage (via the Scorecards plugin), Port, and Cortex let platform teams define maturity criteria — production readiness, security compliance, documentation coverage, cost efficiency — and track every service against them.

AI transforms scorecards from passive dashboards into active recommendation engines:

  • Service maturity gaps: „Your order-service scores 62% on production readiness. Adding health check endpoints and configuring pod disruption budgets would bring it to 85%.“
  • Security posture: „Three services in the payments domain are running container images older than 90 days. Here are the specific CVEs affecting them.“
  • Cost optimization: „Based on CPU utilization patterns over the last 30 days, analytics-worker is over-provisioned by 3x. Recommended resource requests: 200m CPU, 256Mi memory.“

The shift is from „here’s your score“ to „here’s what to do about it.“ When combined with self-service actions, the AI can even generate the pull request to implement the recommendation — turning insight into action in a single interaction.

Dynamic Golden Paths: AI-Generated Templates

Golden paths — the blessed, paved roads for common developer tasks — have traditionally been static. Your platform team creates a service template, a database provisioning workflow, a CI/CD pipeline configuration. Developers pick from the menu.

AI-powered IDPs make golden paths dynamic. Instead of maintaining 15 slightly different service templates for different tech stacks and deployment targets, you maintain a smaller set of composable building blocks. The AI assembles them based on the developer’s intent:

"I need a new Go microservice with a PostgreSQL database, deployed to our EU region, with PII data handling compliance"

The copilot generates a tailored template that includes the correct Helm values for the EU cluster, enables encryption-at-rest annotations for PII compliance, configures the appropriate network policies, and sets up the CI/CD pipeline with the required security scanning stages. The golden path isn’t a fixed road anymore — it’s a GPS that calculates the route based on where you’re going.

This has real implications for template maintenance. Platform teams spend significant effort keeping templates current across Kubernetes versions, policy changes, and infrastructure updates. AI-generated templates that compose from maintained primitives reduce that burden substantially.

Incident Response: The Killer Use Case

If there’s a single scenario where IDP-embedded AI proves its ROI overnight, it’s incident response. Consider the typical flow today:

  1. Alert fires in PagerDuty or Opsgenie
  2. On-call engineer opens the monitoring dashboard
  3. Checks recent deployments in the CI/CD tool
  4. Looks up service ownership in the IDP
  5. Searches for relevant runbooks
  6. Correlates with dependency graph to identify blast radius
  7. Begins remediation

Steps 2 through 6 are pure context gathering — and they happen under pressure at 3 AM. An AI agent inside the IDP can perform all of them in seconds:

  • Correlate the alert with the service catalog entry
  • Identify recent changes (deployments, config updates, dependency upgrades)
  • Pull the relevant runbook and highlight the most likely remediation steps
  • Map the blast radius through the dependency graph
  • Suggest or auto-execute a rollback if the confidence is high enough

The on-call engineer still makes the decision, but the mean time to context drops from 15 minutes to 15 seconds. For organizations running hundreds of microservices, that’s not a nice-to-have — it’s a competitive advantage.

Developer Experience Metrics: Measuring What Matters

AI-powered IDPs also change how we measure developer experience. The DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to recovery) and the SPACE framework (satisfaction, performance, activity, communication, efficiency) are becoming first-class citizens in IDP dashboards.

The AI layer adds predictive and diagnostic capabilities:

  • Trend analysis: „Deployment frequency for the checkout team has dropped 30% over the past sprint. The primary bottleneck appears to be flaky integration tests in the payment-gateway pipeline.“
  • Correlation: „Teams using the v3 service template have 40% lower change failure rates than those on v2. Consider migrating remaining v2 services.“
  • Forecasting: „Based on current velocity, the platform migration will complete in Q3 — two weeks later than planned. The blocker is database schema migrations for three legacy services.“

This is where platform engineering ROI becomes measurable. When you can demonstrate that AI-assisted self-service reduces time-to-production for new services from five days to four hours, the investment case writes itself.

Backstage’s Plugin Ecosystem vs. AI-Native Platforms

The market is splitting into two camps, and platform teams need to understand the tradeoffs:

Dimension Backstage + AI Plugins AI-Native Platforms (Port, Cortex)
Flexibility 900+ plugins, infinite customization Fewer but deeper integrations
AI integration Community-driven, via MCP/plugins Built-in, first-class AI features
Maintenance burden High (self-hosted, plugin compatibility) Lower (SaaS, managed updates)
Data ownership Full control (self-hosted) Vendor-dependent
Time to value Weeks to months Days to weeks
Vendor lock-in Low (CNCF, open source) Moderate to high
Knowledge graph depth As deep as you build it Pre-built entity models

Neither approach is universally better. If your organization has strong platform engineering capacity and wants full control, Backstage with AI plugins and MCP servers gives you maximum flexibility. If you want faster time-to-value and your team is lean, an AI-native platform like Port gets you to production-grade IDP faster — at the cost of some flexibility and data sovereignty.

ChatOps vs. IDP-Embedded AI vs. IDE Copilots

It’s worth clarifying where IDP-embedded AI fits relative to other AI integration points:

  • ChatOps (Slack/Teams bots): Good for notifications and simple commands. Limited context about your infrastructure. Works well for quick queries but struggles with complex multi-step workflows.
  • IDE-integrated copilots (GitHub Copilot, Cursor): Excellent for code generation. No awareness of your deployment topology, service catalog, or organizational policies. Wrong tool for infrastructure tasks.
  • IDP-embedded AI: Sits at the intersection of organizational knowledge, infrastructure state, and developer workflows. Best for self-service actions, incident response, and cross-cutting concerns that span multiple services.

The ideal setup uses all three — but the IDP is the orchestration layer. Your Slack bot calls the IDP’s AI capabilities through MCP. Your IDE copilot references the service catalog for context. The IDP is the brain; everything else is an interface.

Multi-Tenancy, RBAC, and Governance

Here’s where many early AI-in-IDP implementations fall short: governance. When an AI agent can trigger deployments, modify infrastructure, or scaffold services, you need the same (or stricter) access controls as your existing self-service workflows.

Critical requirements:

  • RBAC for AI actions: The AI copilot should inherit the requesting user’s permissions, not operate with elevated privileges
  • Audit trails: Every AI-initiated action must be logged with the full context — who asked, what was requested, what was executed, what was the outcome
  • Approval gates: Destructive or high-risk actions (production deployments, database migrations, security policy changes) should require human approval, even when AI-initiated
  • Multi-tenancy: In organizations with multiple teams sharing an IDP, AI actions must respect tenant boundaries. Team A’s copilot cannot access Team B’s secrets or deploy to Team B’s namespaces
  • Rate limiting: Prevent AI agents from executing runaway loops of infrastructure changes

Without these controls, you’re trading developer friction for security risk — not a trade worth making.

The Risks: What Can Go Wrong

Let’s be direct about the failure modes:

  • Hallucinated infrastructure configurations: An AI that generates a Kubernetes manifest with incorrect resource limits, missing security contexts, or wrong network policies can cause outages. Every AI-generated configuration must pass through the same validation pipelines (OPA/Kyverno, CI checks) as human-authored configs.
  • Insufficient audit trails: If an AI agent makes a change and the audit log only shows „AI modified resource X,“ you’ve lost forensic capability. Log the full chain: user prompt → AI interpretation → action taken → result.
  • Shadow IT acceleration: If self-service becomes too easy, developers spin up resources without proper tagging, cost allocation, or lifecycle management. AI-powered IDPs need to enforce organizational policies at the point of creation, not after the fact.
  • Over-reliance on AI recommendations: Scorecard suggestions and incident response playbooks should augment human judgment, not replace it. Build a culture where AI recommendations are validated, not blindly accepted.

Getting Started: A Practical Roadmap

If you’re running Backstage today and want to add AI capabilities, here’s a pragmatic path:

  1. Start with read-only: Build an MCP server that exposes your service catalog, scorecards, and documentation to an AI agent. Let developers query the catalog through natural language. Zero risk, immediate value.
  2. Add scorecard analysis: Connect the AI to your scorecard data and let it generate improvement recommendations. Still read-only, but now actively useful.
  3. Enable template generation: Allow the AI to compose software templates based on developer intent. Route the output through your existing PR review process.
  4. Introduce action execution: Wire up deployment, scaling, and provisioning actions with approval gates. Start with non-production environments.
  5. Extend to incident response: Connect alerting systems and let the AI perform context gathering and remediation suggestions during incidents.

Each step builds on the previous one, and each can be rolled back independently. The key is maintaining human oversight throughout — AI copilots augment your platform team, they don’t replace it.

The Bottom Line

Internal Developer Portals 2.0 aren’t about replacing Backstage or rebuilding your IDP from scratch. They’re about adding an intelligence layer that transforms the portal from a passive catalog into an active assistant. The service catalog becomes a knowledge graph. Templates become dynamic. Scorecards become recommendation engines. Incident response becomes proactive.

The organizations that get this right will see measurable improvements in developer productivity, onboarding speed, and operational resilience. The ones that don’t will keep maintaining static portals that developers tolerate rather than love.

The technology is ready. The protocols (MCP) are standardizing. The question isn’t whether AI belongs in your IDP — it’s how quickly you can integrate it without compromising the governance that makes your platform trustworthy.

Veröffentlicht am

The .de DNSSEC Meltdown: What Platform Teams Can Learn from Germany’s TLD Outage

TL;DR — On May 5 2026, DENIC pushed broken DNSSEC signatures into the .de zone. Because DNSSEC validation is a strict chain-of-trust model, every validating resolver on the planet began returning SERVFAIL for all .de domains. Millions of websites, APIs, and mail servers went dark. Resolvers that had deployed Serve-Stale (RFC 8767) and Negative Trust Anchors (RFC 7646) recovered within minutes; everyone else waited hours. This article breaks down the incident, the mitigation patterns, and the concrete steps platform teams should take so a single TLD mistake doesn’t take down their stack.

What Happened on May 5, 2026

At approximately 10:42 UTC on Monday, May 5, monitoring dashboards across Europe lit up. DNS resolution for .de domains — one of the world’s largest country-code TLDs, consistently ranking in the Top 5 at Cloudflare Radar — started failing en masse. The root cause: DENIC, the registry operator for .de, had published DNSSEC signatures that did not match the zone’s active Zone Signing Key (ZSK).

The timing was no coincidence. The faulty signatures surfaced during a scheduled ZSK rotation — one of the most operationally sensitive windows in DNSSEC key management. A misconfiguration in the signing pipeline meant that the new signatures were generated with a key that validating resolvers could not verify against the published DS records in the root zone. The result was catastrophic: the entire .de chain of trust was broken.

Within minutes, every DNSSEC-validating resolver worldwide — including Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and Quad9’s 9.9.9.9 — began returning SERVFAIL for queries to .de domains. Non-validating resolvers continued to work, which created a confusing split-brain situation where some users could reach German websites and others couldn’t, depending on their configured resolver.

The DNSSEC Chain of Trust: One Link Breaks, Everything Falls

To understand why a single registry mistake can have such a massive blast radius, you need to understand how DNSSEC validation works.

DNSSEC adds cryptographic signatures to DNS records. Resolvers verify these signatures by walking a chain of trust from the root zone (.) down through the TLD (.de) to the individual domain (example.de). Each level delegates trust to the next via DS (Delegation Signer) records. If any link in this chain produces an invalid signature, a validating resolver must return SERVFAIL. That’s not a bug — it’s the design. DNSSEC was built to prevent cache poisoning, and treating unverifiable answers as failures is the entire point.

The double-edged nature of this design becomes painfully clear during operator errors at the TLD level. When DENIC’s signatures broke, it wasn’t just one domain that failed — it was every single .de domain, regardless of whether the individual domain owner had done everything right. The TLD is a single point of cryptographic failure for all domains beneath it.

ZSK/KSK Rotation: The Critical Window

DNSSEC uses two types of keys: the Key Signing Key (KSK), which signs the DNSKEY RRset, and the Zone Signing Key (ZSK), which signs the actual zone data. ZSK rotations happen more frequently and involve a carefully choreographed dance: pre-publish the new key, wait for caches to expire, sign with the new key, remove the old one. Get any step wrong — wrong timing, wrong key reference, stale DS record — and you shatter the chain of trust. This is exactly what happened with .de.

How Major Resolvers Responded

The incident provided a real-world stress test for two mitigation techniques that the DNS community has been advocating for years: Serve-Stale and Negative Trust Anchors.

Serve-Stale (RFC 8767)

Serve-Stale allows a resolver to return expired (stale) cached records instead of failing with SERVFAIL when it cannot fetch a fresh, valid answer from upstream. Cloudflare’s 1.1.1.1 had Serve-Stale enabled, and their detailed incident report showed that users hitting warm caches continued to get working answers for .de domains — stale data, but functional. For most use cases (websites, APIs, mail routing), a stale A or AAAA record from five minutes ago is infinitely better than SERVFAIL.

The limitation: Serve-Stale only works if the record was previously cached. Cold caches — new queries for domains the resolver hadn’t seen recently — still failed. And once stale TTLs expired (typically capped at 1–3 days depending on implementation), even warm caches would stop serving.

Negative Trust Anchors (RFC 7646)

Negative Trust Anchors (NTAs) are the emergency brake for DNSSEC. An NTA tells a resolver: „Stop validating DNSSEC for this specific domain or zone.“ When applied to .de, it effectively disables signature verification for the entire TLD, allowing queries to resolve normally — at the cost of losing DNSSEC protection.

Cloudflare, Google, and Quad9 all deployed NTAs for .de within the first hour of the incident. This was the fastest path to restoring service for end users. The NTAs were removed once DENIC republished correct signatures later that day.

The Third Option: Disabling DNSSEC Validation Entirely

Some smaller operators chose the nuclear option: disabling DNSSEC validation on their resolvers entirely. This restored service for all domains immediately but removed cryptographic protection for every zone, not just the broken one. This is the equivalent of disabling your firewall because one rule is misconfigured — it works, but the security implications are severe. NTAs are strictly preferable because they scope the trust bypass to the affected zone.

The Amplification Problem

DNS outages create a vicious feedback loop. When resolvers return SERVFAIL, clients retry — aggressively. Applications retry. Browsers retry. Stub resolvers retry. Monitoring systems fire off their own queries. Cloudflare reported a 10x spike in query volume for .de during the incident, as retry storms amplified the load on authoritative servers and resolvers alike.

This client-retry amplification is a well-known pattern in distributed systems, but it’s especially brutal in DNS because retries happen at multiple layers simultaneously. It delays recovery because even after the root cause is fixed, the query flood continues until retry backoffs settle.

Parallels to Prior TLD Outages

The .de incident wasn’t the first time a TLD’s DNSSEC misconfiguration caused widespread outages. In 2024, New Zealand’s .nz experienced a similar DNSSEC signing failure that took down domains across the country. Sweden’s .se has had its own DNSSEC-related incidents. Each time, the pattern is the same: a key management error at the TLD level cascades into a nationwide or zone-wide outage, and the community rediscovers that DNSSEC’s strict validation model trades availability for integrity.

The lesson keeps repeating because the operational complexity of DNSSEC key management is genuinely hard, and the failure mode is binary: it either validates or it doesn’t. There’s no graceful degradation built into the protocol itself.

Platform Engineering Lessons

If you’re running a platform team — especially one operating in the EU — the .de incident should be a wake-up call. DNS is deeply embedded in every layer of a modern cloud-native stack: ExternalDNS syncs records, cert-manager validates domain ownership via DNS-01 challenges, Ingress controllers rely on DNS routing, service meshes resolve endpoints. A DNS outage isn’t just „websites are down“ — it can break certificate issuance, deployment pipelines, service discovery, and monitoring.

1. Monitor DNSSEC Validation, Not Just Resolution

Most teams monitor whether DNS resolution works. Few monitor whether DNSSEC validation is healthy. Set up checks that specifically test DNSSEC signature validity for your critical domains and their parent zones. Tools like DNSViz, Zonemaster, and RIPE Atlas probes can automate this. Alert on validation failures before your users notice.

2. Implement a Multi-Resolver Strategy

Don’t depend on a single upstream resolver. Configure failover across multiple providers: Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9). Each operator has different NTA deployment speeds and Serve-Stale configurations. During the .de incident, the window between „Cloudflare deployed NTA“ and „smaller ISP resolvers deployed NTA“ was measured in hours. A multi-resolver setup lets you ride the fastest responder.

3. Deploy Serve-Stale in Your Own Resolvers

If you run local resolvers (CoreDNS, Unbound, BIND), enable Serve-Stale. In CoreDNS, this means configuring the cache plugin with serve_stale. In Unbound, set serve-expired: yes with appropriate serve-expired-ttl and serve-expired-client-timeout values. This single configuration change is your best passive defense against upstream DNSSEC failures.

# Unbound example
server:
    serve-expired: yes
    serve-expired-ttl: 86400
    serve-expired-client-timeout: 1800
# CoreDNS example
.:53 {
    forward . 1.1.1.1 8.8.8.8 9.9.9.9
    cache 3600 {
        serve_stale 86400
    }
}

4. Treat DNS as a Critical Dependency in Your Architecture

Map out every component in your stack that depends on DNS resolution. ExternalDNS, cert-manager (DNS-01 challenges), Ingress controllers, external API calls, webhook endpoints, OAuth/OIDC provider discovery — all of these break when DNS breaks. Document these dependencies and include DNS failure scenarios in your chaos engineering practice.

5. Build a DNS Incident Response Playbook

Your runbook should5 include:

  • Detection: Automated alerts for DNSSEC validation failures and elevated SERVFAIL rates
  • Triage: Is the issue local, resolver-level, or TLD-level? Use dig +dnssec and delv to isolate
  • Mitigation: Pre-approved steps to deploy NTAs on local resolvers, switch upstream resolvers, or enable Serve-Stale
  • Communication: Templates for status page updates that explain DNS issues to non-technical stakeholders
  • Recovery: Validation that DNSSEC signatures are correct before removing NTAs

6. NIS2 and DORA: DNS Resilience Is Now a Compliance Issue

For organizations operating in the EU, the NIS2 Directive and the Digital Operational Resilience Act (DORA) explicitly require resilience measures for critical infrastructure, including ICT supply chain risks. DNS is a foundational ICT service. A TLD-level outage that takes down your platform because you had no failover, no Serve-Stale, and no incident playbook is now a compliance gap, not just an operational one. Document your DNS resilience measures as part of your NIS2/DORA risk assessments.

The Bigger Picture

The .de DNSSEC meltdown highlights a fundamental tension in internet infrastructure: the systems designed to protect us (DNSSEC, certificate validation, strict security policies) can also become single points of failure when they break. The answer isn’t to disable security — it’s to build resilience layers that absorb the impact of failures without sacrificing protection during normal operations.

Serve-Stale and Negative Trust Anchors are exactly this kind of resilience layer. They don’t weaken DNSSEC; they give operators a controlled way to maintain availability while the underlying issue is fixed. Every platform team should have both in their toolkit.

Conclusion: Your DNS Is Only as Strong as Your Weakest Trust Anchor

The .de outage wasn’t caused by a sophisticated attack. It was a configuration error during routine key rotation — the kind of mistake that can happen to any registry, any operator, at any time. What separated the teams that weathered it from those that scrambled was preparation: multi-resolver setups, Serve-Stale configurations, DNSSEC monitoring, and tested incident playbooks.

Your action items for this week:

  1. Check if your resolvers have Serve-Stale enabled. If not, enable it today.
  2. Set up DNSSEC validation monitoring for your critical domains and their parent TLDs.
  3. Document your DNS dependencies and add DNS failure to your incident response playbook.
  4. Test a multi-resolver failover — don’t wait for the next TLD outage to find out if it works.

The next DNSSEC meltdown isn’t a matter of if — it’s a matter of which TLD and when. Be ready.

Veröffentlicht am

The Vercel Breach Playbook: What Platform Teams Must Do When Their PaaS Provider Gets Compromised

Today — April 19, 2026 — Vercel disclosed a security incident involving unauthorized access to its internal systems. The breach has been linked to the ShinyHunters group, a threat actor known for targeting SaaS platforms via social engineering and vulnerability exploitation. Vercel says a „limited subset of customers“ was impacted and recommends reviewing environment variables — particularly urging use of their Sensitive Environment Variable feature.

If you’re a platform engineer running production workloads on Vercel, this is your signal to act. Not tomorrow. Now.

But this post isn’t just about Vercel. It’s about what every platform team should do when the infrastructure they trust gets compromised — because this has happened before, and it will happen again.

We’ve Been Here Before

The Vercel breach follows a pattern that platform teams should recognize by now:

  • CircleCI (January 2023) — An engineer’s laptop was compromised, giving attackers access to customer environment variables, tokens, and keys. CircleCI’s guidance was unambiguous: rotate every secret, immediately. Teams that delayed paid the price.
  • Codecov (April 2021) — Attackers modified Codecov’s Bash Uploader script, exfiltrating environment variables from CI pipelines for two months before detection. Thousands of repositories had their credentials silently harvested.
  • Travis CI (September 2021) — A vulnerability exposed secrets from public repositories, including signing keys and access tokens. The scope was enormous because the trust boundary had been quietly violated for years.

The common thread: environment variables are the crown jewels, and PaaS providers are the vault. When the vault gets cracked, every secret inside is potentially compromised.

The Shared Responsibility Blind Spot

Most teams understand the shared responsibility model for IaaS — you secure your workloads, AWS secures the hypervisor. But with PaaS providers like Vercel, Netlify, or Railway, the trust boundary is far murkier.

Consider what Vercel has access to in a typical deployment:

  • Your source code (pulled from Git during builds)
  • Every environment variable you’ve configured — database URLs, API keys, signing secrets
  • Build-time and runtime secrets
  • Deployment metadata and audit logs
  • DNS configuration and SSL certificates

When Vercel’s internal systems are breached, all of these become part of the blast radius. You didn’t misconfigure anything. You didn’t leak a credential. Your provider’s security posture became your security posture.

This is the platform trust boundary problem: the more convenience your PaaS offers, the more implicit trust you’ve delegated.

Immediate Response: The First 24 Hours

If you’re running on Vercel right now, here’s the checklist. Don’t wait for their investigation to conclude — assume the worst and work backward.

1. Audit Your Environment Variables

Vercel’s own advisory specifically calls out environment variables. Start here:

# List all Vercel projects and their env vars
vercel env ls --environment production
vercel env ls --environment preview
vercel env ls --environment development

Or use the consolidated environment variables page Vercel provides. Document every secret. You need to know what’s potentially exposed before you can rotate.

2. Rotate Every Secret — No Exceptions

This is the lesson from CircleCI: partial rotation is no rotation. If a secret was accessible to your PaaS provider, treat it as compromised.

  • Database credentials (connection strings, passwords)
  • API keys (Stripe, Twilio, SendGrid, any third-party service)
  • OAuth client secrets
  • JWT signing keys
  • Webhook secrets
  • Encryption keys

Prioritize by blast radius: payment processing keys and database credentials first, monitoring API keys last.

3. Review Deployment History

Check for unauthorized deployments or unexpected build activity:

# Review recent deployments via Vercel CLI
vercel ls --limit 50

# Check for deployments from unexpected branches or commits
vercel inspect <deployment-url>

Look for deployments that don’t correlate with your Git history. An attacker with access to Vercel’s internals could potentially trigger builds with modified environment variables or injected build steps.

4. Revoke and Regenerate Tokens

Beyond environment variables, rotate all integration tokens:

  • Vercel API tokens (personal and team)
  • Git integration tokens (GitHub/GitLab app installations)
  • Any webhook endpoints that use shared secrets for verification
  • CI/CD integration tokens that connect to Vercel

5. Check Downstream Systems

If your database credentials were in Vercel env vars, check your database audit logs for unusual access patterns. If your AWS keys were stored there, review CloudTrail. Every secret that was in Vercel is a thread to pull.

Stop Storing Secrets in Environment Variables

The deeper lesson here is architectural. Environment variables are the de facto standard for passing configuration to applications — but they were never designed as a secrets management system. They’re plaintext, they get logged, they get copied into build caches, and they’re only as secure as the system storing them.

External Secrets Operator

If you’re running Kubernetes workloads (even alongside a PaaS), the External Secrets Operator lets you reference secrets from external stores without ever putting them in your deployment platform:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

The secret lives in Vault or AWS Secrets Manager. Your PaaS never sees it. If the PaaS is breached, the secret isn’t in the blast radius.

HashiCorp Vault with Dynamic Secrets

Even better: don’t store long-lived credentials at all. Vault’s dynamic secrets generate short-lived database credentials on demand:

# Application requests temporary database credentials at startup
vault read database/creds/my-role
# Returns credentials valid for 1 hour
# Automatically revoked after TTL expires

When your PaaS is breached, there’s nothing useful to steal — the credentials expired hours ago.

CI/CD Credential Hygiene: Kill the Static Tokens

Static API keys and long-lived tokens are the gift that keeps giving — to attackers. Every major PaaS breach has involved harvesting static credentials. The fix is structural.

OIDC Federation: Identity Without Secrets

Instead of storing cloud provider credentials in your CI/CD platform, use OIDC federation. Your pipeline proves its identity to the cloud provider directly, receiving short-lived tokens that can’t be stolen from the PaaS:

# GitHub Actions example — no AWS keys stored anywhere
- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/deploy-role
    aws-region: eu-central-1
    # No access-key-id or secret-access-key needed
    # GitHub's OIDC token proves the workflow's identity

All major cloud providers support OIDC federation from GitHub Actions, GitLab CI, and most CI/CD platforms. There is no good reason to store static cloud credentials in your PaaS in 2026.

Workload Identity and SPIFFE7.

For more complex deployments, SPIFFE (Secure Production Identity Framework for Everyone) and its reference implementation SPIRE provide cryptographic identity attestation for workloads. Every workload gets a verifiable identity (SVID) without static credentials, and identity is attested based on the workload’s environment — not a secret that can be exfiltrated.

This is zero-trust for deployment pipelines: trust is established through verifiable identity, not shared secrets.

SBOM and Provenance: Know What You Shipped

When your build platform is compromised, one critical question emerges: can you prove that what’s running in production is what you intended to ship?

Build provenance — cryptographic attestations that link a deployed artifact to its source code, build parameters, and builder identity — becomes essential during incident response:

# Verify build provenance with cosign
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity builder@your-org.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com \
  ghcr.io/your-org/your-app:latest

If you maintain SBOMs (Software Bills of Materials) and SLSA provenance attestations, you can forensically verify whether a compromised build platform injected anything into your artifacts. Without them, you’re flying blind.

Long-Term: Multi-Provider Resilience

The uncomfortable truth is that every PaaS provider will eventually have a security incident. The question isn’t if — it’s whether your architecture limits the blast radius when it happens.

Reduce Single Points of Trust

  • Secrets in an external vault, not in the PaaS — Vault, AWS Secrets Manager, Azure Key Vault
  • Build artifacts signed independently — don’t rely on the build platform’s integrity alone
  • DNS and TLS managed separately — if your PaaS controls your DNS, a breach can redirect traffic
  • Audit logs forwarded in real-time — ship PaaS audit logs to your own SIEM before the provider can tamper with them

Portable Deployments

If your deployment is tightly coupled to a single PaaS, you can’t move quickly during an incident. Containerized workloads with Infrastructure-as-Code configuration give you the option to shift to another platform within hours, not weeks. You don’t need to be multi-cloud on day one — but you need the capability to move when the trust relationship breaks.

The Incident Response Checklist

Pin this somewhere visible. When your next PaaS breach notification lands in your inbox:

Timeframe Action
0-1 hours Inventory all secrets stored in the provider. Begin rotating critical credentials (database, payment, auth).
1-4 hours Revoke all API tokens and integration credentials. Review deployment history for anomalies.
4-12 hours Complete rotation of all remaining secrets. Check downstream system audit logs. Verify build artifact integrity.
12-24 hours Confirm no unauthorized deployments occurred. Brief stakeholders. Document timeline.
1-7 days Conduct full post-incident review. Implement architectural improvements (external secrets, OIDC federation). Update runbooks.

Trust, but Architect for Betrayal

The Vercel breach is a reminder that platform trust is borrowed, not owned. Every convenience a PaaS provides — environment variable storage, built-in secrets, managed DNS — is a trust delegation that becomes a liability during a breach.

The platforms you depend on will get compromised. The question is whether you’ve architected your systems so that a provider breach is a inconvenience you handle in hours — or a catastrophe that takes weeks to untangle.

Start rotating your secrets now. Then start building the architecture that means you won’t have to do it so urgently next time.

Veröffentlicht am

Code Knowledge Graphs: Semantic Search for AI Coding Agents

AI coding tools have revolutionized software development, but there’s a fundamental limitation hiding in plain sight: most AI agents don’t actually understand your codebase—they just search it. When you ask Claude Code, Cursor, or GitHub Copilot to refactor a function, they retrieve relevant file chunks using embedding similarity. But code isn’t a collection of independent text fragments. It’s a graph of interconnected symbols, call hierarchies, and dependencies.

A new generation of tools is changing this paradigm. By parsing repositories into knowledge graphs and exposing them via MCP (Model Context Protocol), projects like Codebase-Memory, CodeGraph, and Lattice give AI agents structural awareness—enabling call-graph traversal, impact analysis, and semantic queries with sub-millisecond latency.

The RAG Problem: Why File-Based Retrieval Falls Short

Traditional RAG (Retrieval-Augmented Generation) pipelines treat codebases as document collections. They chunk files, generate embeddings, and retrieve the most similar fragments when an agent needs context. This approach has critical limitations for code:

  • Scattered evidence: Function definitions get split across chunks, separating signatures from implementations and losing import context.
  • Semantic blindness: Vector similarity doesn’t understand call relationships. A function and its callers may embed to distant vectors despite being tightly coupled.
  • Context window pressure: Complex queries requiring multi-file context quickly exhaust token budgets, forcing truncation of relevant code.
  • No impact awareness: When modifying a function, RAG can’t tell you which downstream components will break.

The result? AI agents that confidently generate code changes without understanding the ripple effects through your architecture.

Enter Code Knowledge Graphs

Knowledge graphs offer a fundamentally different approach: instead of treating code as text to embed, they parse it into structured relationships. Every function, class, import, and call site becomes a node in a traversable graph. This enables queries that RAG simply cannot answer:

  • „What functions call processPayment()?“ — Direct graph traversal, not similarity search.
  • „Show me the impact radius if I change the User interface.“ — Transitive dependency analysis.
  • „Find all implementations of the Repository pattern.“ — Semantic pattern matching across the codebase.

The key enabler is Tree-Sitter, a parsing library that generates abstract syntax trees (ASTs) for 66+ programming languages. By walking these ASTs, tools can extract symbols, relationships, and structural information without language-specific parsers.

Codebase-Memory: The MCP-Native Approach

Codebase-Memory has emerged as a leading implementation, garnering 900+ GitHub stars since its February 2026 release. It parses repositories with Tree-Sitter and stores the resulting knowledge graph in SQLite, then exposes 14 MCP query tools for AI agents:

ToolPurpose
get_symbolRetrieve a symbol’s definition, docstring, and location
get_callersFind all functions that call a given symbol
get_calleesList all functions called by a symbol
get_impact_radiusTransitive analysis of what breaks if a symbol changes
semantic_searchNatural language queries over the graph
get_module_structureHierarchical view of a module’s exports

The performance gains are substantial. Codebase-Memory reports 10x lower token costs compared to file-based retrieval—agents get precisely the context they need without padding prompts with irrelevant code. Query latency runs in sub-milliseconds, even on large repositories.

CodeGraph and token-codegraph: Multi-Language Support

CodeGraph, originally a TypeScript project by Colby McHenry, pioneered the concept of exposing code structure via MCP. Its Rust port, token-codegraph, extends support to Rust, Go, Java, and Scala. Key features include:

  • libsql storage with FTS5 full-text search for hybrid queries
  • Incremental syncing for fast re-indexing on file changes
  • JSON-RPC over stdio for seamless MCP integration
  • Zero external dependencies—runs entirely locally

The local-first architecture matters for enterprise adoption. Unlike cloud-based code intelligence (Sourcegraph, GitHub Code Search), these tools keep your proprietary code on-premises while still enabling AI-powered navigation.

Lattice: Beyond Syntax to Intent

Lattice takes a different approach by connecting code to its reasoning. Its knowledge graph spans four dimensions:

  1. Research: Background investigation, technical spikes, competitor analysis
  2. Strategy: Architecture decisions, trade-off evaluations, design rationale
  3. Requirements: User stories, acceptance criteria, constraints
  4. Implementation: The actual code and its structural relationships

This enables queries that pure code graphs can’t answer: „Why did we choose PostgreSQL over MongoDB for this service?“ or „What requirements drove the decision to make this component async?“

For AI agents, this context is invaluable. When tasked with extending a feature, they can trace back to the original requirements and strategic decisions rather than guessing from code patterns alone.

Integration Patterns for DevOps Teams

Adopting code knowledge graphs requires integrating them into your existing AI coding workflows:

1. CI/CD Graph Updates

Run graph indexing as part of your pipeline. On each merge to main:

- name: Update Code Knowledge Graph
  run: |
    codebase-memory index --repo . --output graph.db
    codebase-memory serve --port 3001 &

This ensures AI agents always query against the latest codebase structure.

2. MCP Server Configuration

Configure your AI coding tool to connect to the graph server. For Claude Code:

{
  "mcpServers": {
    "codebase": {
      "command": "codebase-memory",
      "args": ["serve", "--db", "./graph.db"]
    }
  }
}

3. Impact Analysis in PR Reviews

Use graph queries to automatically flag high-impact changes:

changed_functions=$(git diff --name-only | xargs codebase-memory changed-symbols)
for fn in $changed_functions; do
  impact=$(codebase-memory get-impact-radius "$fn" --depth 3)
  echo "## Impact Analysis: $fn" >> pr-comment.md
  echo "$impact" >> pr-comment.md
done

Benchmarks: Knowledge Graphs vs. RAG

Recent research validates the knowledge graph approach. On SWE-bench Verified—a benchmark where AI agents resolve real GitHub issues—systems using repository-level graphs significantly outperform pure RAG approaches:

ApproachSWE-bench ScoreToken Efficiency
RAG-only retrieval~45%Baseline
RepoGraph + RAG hybrid~62%3x improvement
Full knowledge graph~68%10x improvement

The token efficiency gains compound over time. Agents make fewer exploratory queries when they can directly traverse the call graph, reducing both latency and API costs.

The Future: Hybrid Structural-Semantic Retrieval

The next evolution combines structural graph queries with semantic embeddings. Rather than choosing between „find callers of X“ (structural) and „find code similar to X“ (semantic), hybrid systems enable queries like:

„Find functions that call the payment API and handle similar error patterns to our retry logic.“

This bridges the gap between precise structural navigation and fuzzy semantic understanding—giving AI agents both the map and the intuition to navigate complex codebases.

Conclusion

Code knowledge graphs represent a fundamental shift in how AI agents understand software. By treating repositories as queryable graphs rather than searchable text, tools like Codebase-Memory, CodeGraph, and Lattice unlock capabilities that RAG-based retrieval simply cannot match: call-graph traversal, impact analysis, and sub-millisecond structural queries.

For platform engineering teams, the adoption path is clear: index your repositories, expose the graph via MCP, and integrate impact analysis into your PR workflows. The payoff—10x token efficiency and dramatically more accurate AI assistance—makes this infrastructure investment worthwhile for any team serious about AI-augmented development.

The tools are open source and ready to deploy. The question isn’t whether to adopt code knowledge graphs, but how quickly you can integrate them into your AI coding pipeline.

Veröffentlicht am

The Platform Scorecard: Measuring IDP Value Beyond DORA Metrics

Introduction

You’ve built an Internal Developer Platform. Golden paths are paved, self-service portals are live, and developers can spin up environments in minutes instead of days. But when leadership asks „what’s the ROI?“, you find yourself scrambling for numbers that don’t quite capture the value you’ve created.

DORA metrics—deployment frequency, lead time, change failure rate, mean time to recovery—have become the default answer. But in 2026, they’re increasingly insufficient. AI-assisted development can inflate deployment frequency while masking review bottlenecks. Lead time improvements might come at the cost of technical debt. And none of these metrics capture what platform teams actually deliver: developer productivity and organizational capability.

This article introduces the Platform Scorecard—a framework for measuring IDP value that combines traditional delivery metrics with developer experience indicators, adoption signals, and business impact measures. It’s designed for platform teams who need to justify investment, prioritize roadmaps, and demonstrate value beyond „we deployed more stuff.“

Why DORA Metrics Fall Short

DORA metrics revolutionized how we think about software delivery performance. The research is solid, the correlations are real, and every platform team should track them. But they were designed to measure delivery capability, not platform value.

The AI Inflation Problem

With AI coding assistants generating more code faster, deployment frequency naturally increases. But this doesn’t mean developers are more productive—it might mean they’re spending more time reviewing AI-generated PRs, debugging subtle issues, or managing technical debt that accumulates faster than before.

A platform team that enables 10x more deployments hasn’t necessarily delivered 10x more value. They might have just enabled 10x more churn.

The Attribution Problem

When lead time improves, who gets credit? The platform team who built the CI/CD pipelines? The SRE team who optimized the deployment process? The developers who adopted better practices? The AI tools that generate boilerplate faster?

DORA metrics measure outcomes at the organizational level. Platform teams need metrics that measure their specific contribution to those outcomes.

The Experience Gap

A platform can have excellent DORA metrics while developers hate using it. Friction might be hidden in workarounds, shadow IT, or teams simply avoiding the platform altogether. DORA doesn’t capture whether developers want to use your platform—only whether code eventually ships.

The Platform Scorecard Framework

The Platform Scorecard measures platform value across four dimensions:

┌─────────────────────────────────────────────────────────────┐
│                   PLATFORM SCORECARD                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │   MONK      │  │   DX Core   │  │  Adoption   │        │
│  │ Indicators  │  │     4       │  │   Metrics   │        │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘        │
│         │                │                │                │
│         └────────────────┼────────────────┘                │
│                          ▼                                 │
│                 ┌─────────────┐                            │
│                 │  Business   │                            │
│                 │   Impact    │                            │
│                 └─────────────┘                            │
└─────────────────────────────────────────────────────────────┘
  1. MONK Indicators: Platform-specific capability metrics
  2. DX Core 4: Developer experience measurements
  3. Adoption Metrics: Platform usage and engagement signals
  4. Business Impact: Translation to organizational value

MONK Indicators: Measuring Platform Capability

MONK stands for four platform-specific indicators that measure what your IDP actually enables:

M — Mean Time to Productivity

How long does it take a new developer to ship their first meaningful change?

This isn’t just „time to first commit“—it’s time to first production deployment that delivers user value. It captures the entire onboarding experience: environment setup, access provisioning, documentation quality, and golden path effectiveness.

Level MTTP What It Indicates
Elite < 1 day Fully automated onboarding, excellent docs
High 1-3 days Good automation, minor manual steps
Medium 1-2 weeks Significant manual setup, tribal knowledge
Low > 2 weeks Broken onboarding, high friction

How to measure: Track the timestamp of a developer’s first day against their first production deployment. Survey new hires about blockers. Instrument your onboarding automation to identify where time is spent.

O — Observability Coverage

What percentage of services have adequate observability?

„Adequate“ means: structured logging, distributed tracing, key metrics dashboards, and alerting. If developers can’t debug their services without SSH-ing into production, your platform isn’t delivering on its observability promise.

Level Coverage What It Indicates
Elite > 95% Observability is default, opt-out not opt-in
High 80-95% Most services instrumented, some gaps
Medium 50-80% Inconsistent adoption, manual setup
Low < 50% Observability is an afterthought

How to measure: Scan your service catalog for observability signals. Check for active traces, log streams, and dashboard usage. Automate detection of services without adequate instrumentation.

N — Number of Services on Golden Paths

How many services use your platform’s recommended patterns?

Golden paths only deliver value if teams actually walk them. This metric tracks adoption of your templates, scaffolding, and recommended architectures versus custom or legacy approaches.

Level Adoption What It Indicates
Elite > 80% Golden paths are genuinely useful
High 60-80% Good adoption, some justified exceptions
Medium 30-60% Mixed adoption, paths may need improvement
Low < 30% Teams prefer alternatives, paths aren’t valuable

How to measure: Tag services by creation method (template vs. custom). Track which CI/CD patterns are in use. Survey teams about why they didn’t use golden paths.

K — Knowledge Accessibility

Can developers find answers without asking humans?

This measures documentation quality, search effectiveness, and self-service capability. Every question that requires Slack escalation is a failure of your platform’s knowledge layer.

Level Self-Service Rate What It Indicates
Elite > 90% Excellent docs, effective search, AI-assisted
High 70-90% Good docs, some gaps in edge cases
Medium 50-70% Inconsistent docs, frequent escalations
Low < 50% Tribal knowledge dominates

How to measure: Track support ticket volume per developer. Survey developers about where they find answers. Analyze search query success rates in your portal.

DX Core 4: Measuring Developer Experience

The DX Core 4 framework, developed by DX (formerly GetDX), measures developer experience through four key dimensions:

Speed

How fast can developers complete common tasks?

  • Time to create a new service
  • Time to add a new dependency
  • Time to deploy a change
  • Time to rollback a bad deployment
  • CI/CD pipeline duration

Effectiveness

Can developers accomplish what they’re trying to do?

  • Task completion rate for common workflows
  • Error rates in self-service operations
  • Percentage of tasks requiring manual intervention
  • First-try success rate for deployments

Quality

Does the platform help developers build better software?

  • Security vulnerability detection rate
  • Policy compliance scores
  • Test coverage trends
  • Production incident rates by platform-generated vs. custom services

Impact

Do developers feel they’re making meaningful contributions?

  • Percentage of time on feature work vs. toil
  • Developer satisfaction scores (quarterly surveys)
  • Net Promoter Score for the platform
  • Voluntary platform adoption rate

Adoption Metrics: Measuring Platform Usage

Adoption metrics tell you whether developers are actually using your platform—and how deeply.

Breadth Metrics

  • Active users: Monthly active developers using the platform
  • Team coverage: Percentage of teams with at least one active user
  • Service coverage: Percentage of production services managed by the platform

Depth Metrics

  • Feature adoption: Which platform capabilities are actually used?
  • Engagement frequency: How often do developers interact with the platform?
  • Workflow completion: Do users complete multi-step workflows or drop off?

Retention Metrics

  • Churn rate: Teams that stop using the platform
  • Return rate: Users who come back after initial use
  • Expansion: Teams adopting additional platform features

Shadow IT Indicators

  • Workaround detection: Teams building alternatives to platform features
  • Escape hatch usage: How often do teams need to bypass the platform?
  • Manual process survival: Legacy processes that should be automated

Business Impact: Translating to Value

Ultimately, platform investment needs to translate to business outcomes. The Platform Scorecard connects capability metrics to value through:

Cost Metrics

  • Infrastructure cost per service: Does the platform optimize resource usage?
  • Time savings: Developer hours saved by automation (valued at loaded cost)
  • Incident cost reduction: MTTR improvements × average incident cost
  • Onboarding cost: MTTP improvement × new hire cost per day

Risk Metrics

  • Security posture: Vulnerability exposure window, compliance violations
  • Operational risk: Single points of failure, bus factor for critical systems
  • Regulatory risk: Audit findings, compliance gaps

Capability Metrics

  • Time to market: How fast can the organization ship new products?
  • Experimentation velocity: A/B tests launched, feature flags toggled
  • Scale readiness: Can the organization 10x without 10x headcount?

Implementing the Platform Scorecard

Start Simple

Don’t try to measure everything at once. Pick one metric from each category:

  1. MONK: Mean Time to Productivity (easiest to measure)
  2. DX Core 4: Developer satisfaction survey (quarterly)
  3. Adoption: Monthly active users
  4. Business Impact: Developer hours saved

Automate Collection

Manual metrics decay quickly. Invest in:

  • Event tracking in your developer portal
  • CI/CD pipeline instrumentation
  • Automated surveys triggered by workflow completion
  • Service catalog scanning for compliance

Review Cadence

  • Weekly: Adoption metrics (leading indicators)
  • Monthly: MONK indicators, DX speed/effectiveness
  • Quarterly: Full scorecard review, business impact calculation

Benchmark and Trend

Absolute numbers matter less than trends. A 70% golden path adoption rate might be excellent for your organization or terrible—context determines meaning. Track improvement over time and benchmark against similar organizations when possible.

Presenting to Leadership

When presenting Platform Scorecard results to leadership, focus on:

  1. Business impact first: Lead with cost savings and risk reduction
  2. Trends over absolutes: Show improvement trajectories
  3. Developer voice: Include satisfaction quotes and NPS
  4. Comparative context: Industry benchmarks where available
  5. Investment connection: Link metrics to roadmap priorities

Conclusion

DORA metrics remain valuable, but they’re not enough to measure platform value. The Platform Scorecard provides a comprehensive framework that captures what platform teams actually deliver: developer capability, experience improvement, and organizational value.

The key insight is that platforms are products, and products need product metrics. Deployment frequency tells you code is shipping. The Platform Scorecard tells you whether developers are thriving, the organization is more capable, and your investment is paying off.

Start measuring what matters. Your platform’s value is real—now you can prove it.

Veröffentlicht am

The Great Migration: From Kubernetes Ingress to Gateway API

Introduction

After years as the de facto standard for HTTP routing in Kubernetes, Ingress is being retired. The Ingress-NGINX project announced in March 2026 that it’s entering maintenance mode, and the Kubernetes community has thrown its weight behind the Gateway API as the future of traffic management.

This isn’t just a rename. Gateway API represents a fundamental rethinking of how Kubernetes handles ingress traffic—more expressive, more secure, and designed for the multi-team, multi-tenant reality of modern platform engineering. But migration isn’t trivial: years of accumulated annotations, controller-specific configurations, and tribal knowledge need to be carefully translated.

This article covers why the migration is happening, how Gateway API differs architecturally, and provides a practical migration workflow using the new Ingress2Gateway tool that reached 1.0 in March 2026.

Why Ingress Is Being Retired

Ingress served Kubernetes well for nearly a decade, but its limitations have become increasingly painful:

The Annotation Problem

Ingress’s core specification is minimal—it handles basic host and path routing. Everything else—rate limiting, authentication, header manipulation, timeouts, body size limits—lives in annotations. And annotations are controller-specific.

# NGINX-specific annotations
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/verify"
    # ... dozens more

Switch from NGINX to Traefik? Rewrite all your annotations. Want to use multiple ingress controllers? Good luck keeping the annotation schemas straight. This has led to:

  • Vendor lock-in: Teams hesitate to switch controllers because migration costs are high
  • Configuration sprawl: Critical routing logic is buried in annotations that are hard to audit
  • No validation: Annotations are strings—typos cause runtime failures, not deployment rejections

The RBAC Gap

Ingress is a single resource type. If you can edit an Ingress, you can edit any Ingress in that namespace. There’s no built-in way to separate „who can define routes“ from „who can configure TLS“ from „who can set up authentication policies.“

In multi-team environments, this forces platform teams to either:

  • Give app teams too much power (security risk)
  • Centralize all Ingress management (bottleneck)
  • Build custom admission controllers (complexity)

Limited Expressiveness

Modern traffic management needs capabilities that Ingress simply doesn’t support natively:

  • Traffic splitting for canary deployments
  • Header-based routing
  • Request/response transformation
  • Cross-namespace routing
  • TCP/UDP routing (not just HTTP)

Enter Gateway API

Gateway API is designed from the ground up to address these limitations. It’s not just „Ingress v2″—it’s a complete reimagining of how Kubernetes handles traffic.

Resource Model

Instead of cramming everything into one resource, Gateway API separates concerns:

┌─────────────────────────────────────────────────────────────┐
│                    GATEWAY API MODEL                        │
│                                                             │
│   ┌─────────────────┐                                       │
│   │  GatewayClass   │  ← Infrastructure provider config    │
│   │  (cluster-wide) │    (managed by platform team)        │
│   └────────┬────────┘                                       │
│            │                                                │
│   ┌────────▼────────┐                                       │
│   │     Gateway     │  ← Deployment of load balancer       │
│   │   (namespace)   │    (managed by platform team)        │
│   └────────┬────────┘                                       │
│            │                                                │
│   ┌────────▼────────┐                                       │
│   │   HTTPRoute     │  ← Routing rules                     │
│   │   (namespace)   │    (managed by app teams)            │
│   └─────────────────┘                                       │
└─────────────────────────────────────────────────────────────┘
  • GatewayClass: Defines the controller implementation (like IngressClass, but richer)
  • Gateway: Represents an actual load balancer deployment with listeners
  • HTTPRoute: Defines routing rules that attach to Gateways
  • Plus: TCPRoute, UDPRoute, GRPCRoute, TLSRoute for non-HTTP traffic

RBAC-Native Design

Each resource type has separate RBAC controls:

# Platform team: can manage GatewayClass and Gateway
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-admin
rules:
  - apiGroups: ["gateway.networking.k8s.io"]
    resources: ["gatewayclasses", "gateways"]
    verbs: ["*"]

---
# App team: can only manage HTTPRoutes in their namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: route-admin
  namespace: team-alpha
rules:
  - apiGroups: ["gateway.networking.k8s.io"]
    resources: ["httproutes"]
    verbs: ["*"]

App teams can define their routing rules without touching infrastructure configuration. Platform teams control the Gateway without micromanaging every route.

Typed Configuration

No more annotation strings. Gateway API uses structured, validated fields:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
  namespace: production
spec:
  parentRefs:
    - name: production-gateway
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
          weight: 90
        - name: api-service-canary
          port: 8080
          weight: 10
      timeouts:
        request: 30s
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: X-Request-ID
                value: "${request_id}"

Traffic splitting, timeouts, header modification—all first-class, validated fields. No more hoping you spelled the annotation correctly.

Ingress2Gateway: The Migration Tool

The Kubernetes SIG-Network team released Ingress2Gateway 1.0 in March 2026, providing automated translation of Ingress resources to Gateway API equivalents.

Installation

# Install via Go
go install github.com/kubernetes-sigs/ingress2gateway@latest

# Or download binary
curl -LO https://github.com/kubernetes-sigs/ingress2gateway/releases/latest/download/ingress2gateway-linux-amd64
chmod +x ingress2gateway-linux-amd64
sudo mv ingress2gateway-linux-amd64 /usr/local/bin/ingress2gateway

Basic Usage

# Convert a single Ingress
ingress2gateway print --input-file ingress.yaml

# Convert all Ingresses in a namespace
kubectl get ingress -n production -o yaml | ingress2gateway print

# Convert and apply directly
kubectl get ingress -n production -o yaml | ingress2gateway print | kubectl apply -f -

What Gets Translated

Ingress2Gateway handles:

  • Host and path rules: Direct translation to HTTPRoute
  • TLS configuration: Mapped to Gateway listeners
  • Backend services: Converted to backendRefs
  • Common annotations: Timeout, body size, redirects → native fields

What Requires Manual Work

Not everything translates automatically:

  • Controller-specific annotations: Authentication plugins, custom Lua scripts, rate limiting configurations often need manual migration
  • Complex rewrites: Regex-based path rewrites may need adjustment
  • Custom error pages: Implementation varies by Gateway controller

Ingress2Gateway generates warnings for annotations it can’t translate, giving you a checklist for manual review.

Migration Workflow

Phase 1: Assessment

# Inventory all Ingresses
kubectl get ingress -A -o yaml > all-ingresses.yaml

# Run Ingress2Gateway in analysis mode
ingress2gateway print --input-file all-ingresses.yaml 2>&1 | tee migration-report.txt

# Review warnings for untranslatable annotations
grep "WARNING" migration-report.txt

Phase 2: Parallel Deployment

Don’t cut over immediately. Run both Ingress and Gateway API in parallel:

# Deploy Gateway controller (e.g., Envoy Gateway, Cilium, NGINX Gateway Fabric)
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm   --version v1.0.0   -n envoy-gateway-system --create-namespace

# Create GatewayClass
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

# Create Gateway (gets its own IP/hostname)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production
  namespace: gateway-system
spec:
  gatewayClassName: envoy
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-cert

Phase 3: Traffic Shift

With both systems running, gradually shift traffic:

  1. Update DNS to point to Gateway API endpoint with low weight
  2. Monitor error rates, latency, and functionality
  3. Increase Gateway API traffic percentage
  4. Once at 100%, remove old Ingress resources

Phase 4: Testing

Behavioral equivalence testing is critical:

# Compare responses between Ingress and Gateway
for endpoint in $(cat endpoints.txt); do
  ingress_response=$(curl -s "https://ingress.example.com$endpoint")
  gateway_response=$(curl -s "https://gateway.example.com$endpoint")
  
  if [ "$ingress_response" != "$gateway_response" ]; then
    echo "MISMATCH: $endpoint"
  fi
done

Common Migration Pitfalls

Default Timeout Differences

Ingress-NGINX defaults to 60-second timeouts. Some Gateway implementations default to 15 seconds. Explicitly set timeouts to avoid surprises:

rules:
  - matches:
      - path:
          value: /api
    timeouts:
      request: 60s
      backendRequest: 60s

Body Size Limits

NGINX’s proxy-body-size annotation doesn’t have a direct equivalent in all Gateway implementations. Check your controller’s documentation for request size configuration.

Cross-Namespace References

Gateway API supports cross-namespace routing, but it requires explicit ReferenceGrant resources:

# Allow HTTPRoutes in team-alpha to reference services in backend namespace
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-team-alpha
  namespace: backend
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: team-alpha
  to:
    - group: ""
      kind: Service

Service Mesh Interaction

If you’re running Istio or Cilium, check their Gateway API support status. Both now implement Gateway API natively, which can simplify your stack—but migration needs coordination.

Gateway Controller Options

Several controllers implement Gateway API:

Controller Backing Proxy Notes
Envoy Gateway Envoy CNCF project, feature-rich
NGINX Gateway Fabric NGINX From F5/NGINX team
Cilium Envoy (eBPF) If already using Cilium CNI
Istio Envoy Native Gateway API support
Traefik Traefik Good for existing Traefik users
Kong Kong Enterprise features available

Timeline and Urgency

While Ingress isn’t disappearing overnight, the writing is on the wall:

  • March 2026: Ingress-NGINX enters maintenance mode
  • Gateway API v1.0: Already stable since late 2023
  • New features: Only coming to Gateway API (traffic splitting, GRPC routing, etc.)

Start planning migration now. Even if you don’t execute immediately, understanding Gateway API will be essential for any new Kubernetes work.

Conclusion

The migration from Ingress to Gateway API is inevitable, but it doesn’t have to be painful. Gateway API offers genuine improvements—better RBAC, typed configuration, richer routing capabilities—that justify the migration effort.

Start with Ingress2Gateway to understand the scope of your migration. Deploy Gateway API alongside Ingress to validate behavior. Shift traffic gradually, test thoroughly, and you’ll emerge with a more maintainable, more secure traffic management layer.

The annotation chaos era is ending. The future of Kubernetes traffic management is typed, validated, and RBAC-native. It’s time to migrate.

Veröffentlicht am

Intent-Driven Infrastructure: From IaC Scripts to Self-Reconciling Platforms

Introduction

For years, Infrastructure as Code (IaC) has been the gold standard for managing cloud resources. Tools like Terraform, Pulumi, and CloudFormation brought version control, repeatability, and collaboration to infrastructure management. But as cloud environments grow in complexity, a fundamental tension has emerged: IaC scripts describe how to build infrastructure, not what infrastructure should look like.

Intent-driven infrastructure flips this paradigm. Instead of writing imperative scripts or even declarative configurations that describe specific resources, you express intents — high-level descriptions of desired outcomes. The platform then continuously reconciles reality with intent, automatically correcting drift, scaling resources, and enforcing policies.

This article explores how intent-driven infrastructure works, the technologies enabling it, and practical steps to adopt this approach in your organization.

The Limitations of Traditional IaC

Traditional IaC has served us well, but several pain points are driving the need for evolution:

  • Configuration Drift: Despite declarative tools, drift between desired and actual state is common. Manual changes, failed applies, and partial rollbacks create inconsistencies that require human intervention to resolve.
  • Brittle Pipelines: CI/CD pipelines for infrastructure often break on edge cases — timeouts, API rate limits, dependency ordering. Recovery requires manual debugging and re-running pipelines.
  • Cognitive Overhead: Developers must understand cloud-provider-specific APIs, resource dependencies, and lifecycle management. This creates a bottleneck where only specialized engineers can make infrastructure changes.
  • Day-2 Operations Gap: Most IaC tools excel at provisioning but struggle with ongoing operations — scaling, patching, certificate rotation, and compliance enforcement.

What is Intent-Driven Infrastructure?

Intent-driven infrastructure introduces a higher level of abstraction. Instead of specifying individual resources, you express intents like:

“I need a production-grade PostgreSQL database with 99.9% availability, encrypted at rest, accessible only from the application namespace, with automated backups retained for 30 days.”

The platform interprets this intent and:

  1. Compiles it into concrete resource definitions (RDS instance, security groups, backup policies, monitoring rules)
  2. Validates against organizational policies (cost limits, security requirements, compliance rules)
  3. Provisions the resources across the appropriate cloud accounts
  4. Continuously reconciles — if drift is detected, the platform automatically corrects it

Core Architectural Patterns

Kubernetes as Universal Control Plane

The Kubernetes API server and its reconciliation loop have proven to be remarkably versatile. Projects like Crossplane leverage this pattern to manage any infrastructure resource through Kubernetes Custom Resource Definitions (CRDs). The key insight: the reconciliation loop that keeps your pods running can also keep your cloud infrastructure aligned with intent.

Crossplane Compositions as Intent Primitives

Crossplane v2 Compositions allow platform teams to define reusable, opinionated templates that abstract away provider-specific complexity. A single DatabaseIntent CRD can provision an RDS instance on AWS, Cloud SQL on GCP, or Azure Database — the developer only expresses intent, not implementation.

apiVersion: platform.example.com/v1alpha1
kind: DatabaseIntent
metadata:
  name: orders-db
spec:
  engine: postgresql
  version: "16"
  availability: high
  encryption: true
  backup:
    retentionDays: 30
  network:
    allowFrom:
      - namespace: orders-app

Policy Guardrails: OPA, Kyverno, and Cedar

Intent without governance is chaos. Policy engines ensure that every intent is validated before execution:

  • OPA (Open Policy Agent) / Gatekeeper: Rego-based policies for Kubernetes admission control. Powerful but requires learning a new language.
  • Kyverno: YAML-native policies that feel natural to Kubernetes operators. Lower barrier to entry, excellent for common patterns.
  • Cedar: AWS-backed authorization language for fine-grained access control. Emerging as a standard for application-level policy.

Together, these tools enforce constraints like cost ceilings, security baselines, and compliance requirements — automatically, at every change.

Continuous Reconciliation vs. Imperative Apply

The fundamental shift from traditional IaC to intent-driven infrastructure is moving from imperative apply (run a pipeline to make changes) to continuous reconciliation (the platform constantly ensures reality matches intent). This eliminates drift by design rather than detecting it after the fact.

Orchestration Platforms: Humanitec and Score

Humanitec provides an orchestration layer that translates developer intent into fully resolved infrastructure configurations. Using Score (an open-source workload specification), developers describe what their application needs without specifying how it is provisioned. The platform engine resolves dependencies, applies organizational rules, and generates deployment manifests.

Benefits in Practice

  • Faster Recovery: When infrastructure drifts or fails, the reconciliation loop automatically corrects it. MTTR drops from hours to minutes.
  • Safer Changes: Policy gates validate every change before execution. No more “oops, I deleted the production database” moments.
  • Developer Velocity: Developers express intent in familiar terms, not cloud-provider-specific configurations. Time-to-production for new services drops significantly.
  • Compliance by Default: Security, cost, and regulatory policies are enforced continuously, not checked periodically.
  • AI-Agent Compatibility: Intent-based APIs are natural interfaces for AI agents. An AI coding assistant can express “I need a cache with 10GB capacity” without understanding the intricacies of ElastiCache configuration.

Challenges and Guardrails

Intent-driven infrastructure is not without its challenges:

  • Abstraction Leakage: When things go wrong, engineers need to understand the underlying resources. Too much abstraction can make debugging harder.
  • Policy Complexity: As organizations grow, policy definitions can become complex and conflicting. Invest in policy testing and simulation.
  • Observability: You need new metrics — not just “is the resource healthy?” but “is the intent satisfied?” Intent satisfaction metrics are a new concept for most teams.
  • Migration Path: Existing Terraform/Pulumi codebases represent significant investment. Migration must be gradual, starting with new workloads and selectively adopting intent-driven patterns for existing ones.
  • Organizational Change: Intent-driven infrastructure shifts responsibilities. Platform teams own the abstraction layer; application teams own the intents. This requires clear role definitions and trust.

Getting Started: A Minimal Viable Implementation

  1. Start Small: Pick one workload type (e.g., databases) and create an intent CRD using Crossplane Compositions.
  2. Add Policy Gates: Implement basic Kyverno policies for cost limits and security baselines.
  3. Enable Reconciliation: Let the Crossplane controller continuously reconcile. Monitor drift detection and auto-correction rates.
  4. Measure Impact: Track MTTR, change drift frequency, time-to-recover, and developer satisfaction.
  5. Iterate: Expand to more resource types, add more sophisticated policies, and integrate with your IDP (Internal Developer Portal).

Conclusion

Intent-driven infrastructure represents the next evolution of Infrastructure as Code. By shifting from imperative scripts to declarative intents backed by continuous reconciliation and policy guardrails, organizations can build platforms that are more resilient, more secure, and more developer-friendly.

The tools are maturing rapidly — Crossplane, Humanitec, OPA, Kyverno, and the broader Kubernetes ecosystem provide a solid foundation. The question is no longer whether to adopt intent-driven patterns, but how fast your team can start the journey.

Start with a single workload, prove the value, and scale from there. Your future self — debugging a production issue at 3 AM — will thank you when the platform auto-heals before you even finish your coffee.

Veröffentlicht am

Golden Paths for AI-Generated Code: How Platform Teams Keep Up with Machine-Speed Development

The AI Development Velocity Gap

AI coding assistants have fundamentally changed how software gets written. GitHub Copilot, Claude Code, Cursor, and their ilk are delivering on the promise of 55% faster development cycles—but they’re also creating a bottleneck that most organizations haven’t anticipated.

The problem isn’t the code generation. It’s what happens after the AI writes it.

Traditional code review processes, pipeline configurations, and compliance checks weren’t designed for machine-speed development. When a developer can generate 500 lines of functional code in minutes, but your security scan takes 45 minutes and your approval workflow spans three days, you’ve created a velocity cliff. The AI accelerates development right up to the point where organizational friction brings it to a halt.

This is where Golden Paths come in—not as a new concept, but as an evolution. Platform engineering teams are realizing that paved roads designed for human developers need to be reimagined for AI-assisted development. The path itself needs to be machine-consumable.

What Makes a Golden Path „AI-Native“?

Traditional Golden Paths provide opinionated defaults: here’s how we build microservices, here’s our standard CI/CD pipeline, here’s our approved tech stack. AI-native Golden Paths go further—they encode organizational knowledge in formats that both humans and AI assistants can understand and follow.

The Three Layers

1. Templates as Machine Instructions

Backstage scaffolders and Cookiecutter templates have always been about consistency. But when an AI assistant generates code, it needs to know not just what to create, but how to create it according to your standards.

Modern template systems are evolving to include:

  • Intent declarations — What is this template for? („Internal API with PostgreSQL, OAuth, and OpenTelemetry“)
  • Constraint specifications — What’s non-negotiable? („All services must use mTLS, secrets must reference Vault, no direct database access from handlers“)
  • Context documentation — Why these decisions? („mTLS required for zero-trust compliance, Vault integration prevents secret sprawl“)

This isn’t just documentation for humans. It’s context that AI assistants can consume to generate code that already complies with your standards—before the first commit.

2. Embedded Governance

The old model: write code, submit PR, wait for review, fix issues, merge. The AI-native model: generate compliant code from the start.

Golden Paths are increasingly embedding governance as code:

# Example: Terraform module with embedded policy
module "service_template" {
  source = "platform/golden-paths//microservice"
  
  # Intent declaration
  service_type = "internal-api"
  data_stores  = ["postgresql"]
  
  # Embedded compliance
  security_profile = "pci-dss"  # Enforces mTLS, encryption at rest, audit logging
  observability    = "full"     # Auto-injects OTel, requires SLO definitions
  
  # AI assistant instructions
  ai_context = {
    testing_strategy = "contract-first"
    docs_requirement = "openapi-generated"
    deployment_model = "canary-required"
  }
}

The AI assistant—whether it’s generating the initial service scaffold or helping add a new endpoint—has explicit guidance about organizational requirements. The „shift left“ here isn’t just moving security earlier; it’s embedding organizational knowledge so deeply that compliance becomes the path of least resistance.

3. Continuous Validation, Not Gates

Traditional pipelines are gate-based: run tests, run security scans, wait for approval, deploy. AI-native Golden Paths favor continuous validation: the path itself ensures compliance, and deviations are caught immediately—not at PR time.

Tools like Datadog’s Service Catalog, Cortex, and Port are evolving from static documentation to active validation systems. They don’t just record that your service should have tracing; they verify it’s actually emitting traces, that SLOs are defined, that dependencies are documented. The Golden Path becomes a living specification, continuously reconciled against reality.

The Platform Team’s New Role

This shift changes what platform engineering teams optimize for. Previously, the goal was standardization—get everyone using the same tools, the same patterns, the same pipelines. Now, the goal is machine-consumable context.

Platform teams are becoming curators of organizational knowledge. Their deliverables aren’t just templates and Terraform modules, but:

  • Decision records as structured data — Why do we use Kafka over RabbitMQ? The reasoning needs to be parseable by AI assistants, not just documented in Confluence.
  • Architecture constraints as code — Policy definitions that both CI pipelines and AI assistants can evaluate.
  • Context about context — Metadata about when standards apply, what exceptions exist, and how to evolve them.

The best platform teams are already treating their Golden Paths as products—with user research (what do developers and AI assistants struggle with?), iteration (which constraints are too burdensome?), and metrics (time from idea to production, compliance drift, developer satisfaction).

Practical Implementation: Start Small

The organizations succeeding with AI-native Golden Paths aren’t boiling the ocean. They’re starting with one painful workflow and making it AI-friendly.

Phase 1: One Service Template

Pick your most common service type—probably an internal API—and create a template that encodes your current best practices. But don’t stop at file generation. Include:

  • A Backstage scaffolder with clear, structured metadata
  • CI/CD pipelines that validate compliance automatically
  • Documentation that explains why each decision was made
  • Example prompts that developers (or AI assistants) can use to extend the service

Phase 2: Expand to Common Patterns

Once the first template proves valuable, expand to other frequent scenarios:

  • Data pipeline templates („Ingest from Kafka, transform with dbt, load to Snowflake“)
  • ML serving templates („Model deployment with A/B testing, canary analysis, and drift detection“)
  • Frontend component templates („React component with Storybook, accessibility tests, and design system integration“)

For each, the goal isn’t just consistency—it’s making the organizational knowledge machine-consumable.

Phase 3: Active Validation

The final evolution is continuous reconciliation. Your Golden Path specifications should be validated against actual running services, with drift detection and automated remediation where possible. If a service was created with the „internal-api“ template but no longer has the required observability, the platform should flag it—not as a compliance violation, but as a service that’s fallen off the golden path.

The Competitive Imperative

Organizations that solve this problem will have a compounding advantage. Their developers—augmented by AI assistants—will move at machine speed, but with organizational guardrails that ensure security, compliance, and maintainability. Those stuck with human-speed governance processes will find their AI investments stalling at the velocity cliff.

The question isn’t whether to adopt AI coding assistants. That ship has sailed. The question is whether your platform can keep up with the pace they enable.

Golden Paths aren’t new. But Golden Paths designed for AI-generated code? That’s the platform engineering challenge of 2026.

Want to implement AI-native Golden Paths? Start with your most painful developer workflow. Make the path so clear that both humans and AI assistants can follow it without thinking. Then iterate.

Veröffentlicht am

Internal Developer Portals: Backstage, Port.io, and the Path to Self-Service Platforms

Platform Engineering: The 2026 Megatrend

The days when developers had to write tickets and wait for days for infrastructure are over. Internal Developer Portals (IDPs) are the heart of modern Platform Engineering teams — enabling self-service while maintaining governance.

Comparing the Contenders

Backstage (Spotify)

The open-source heavyweight from Spotify has established itself as the de facto standard:

  • Software Catalog — Central overview of all services, APIs, and resources
  • Tech Docs — Documentation directly in the portal
  • Templates — Golden paths for new services
  • Plugins — Extensible through a large community

Strength: Flexibility and community. Weakness: High setup and maintenance effort.

Port.io

The SaaS alternative for teams that want to be productive quickly:

  • No-Code Builder — Portal without development effort
  • Self-Service Actions — Day-2 operations automated
  • Scorecards — Production readiness at a glance
  • RBAC — Enterprise-ready access control

Strength: Time-to-value. Weakness: Less flexibility than open source.

Cortex

The focus is on service ownership and reliability:

  • Service Scorecards — Enforce quality standards
  • Ownership — Clear responsibilities
  • Integrations — Deep connection to monitoring tools

Strength: Reliability engineering. Weakness: Less developer experience focus.

Software Catalogs: The Foundation

An IDP stands or falls with its catalog. The core questions:

  • What do we have? — Services, APIs, databases, infrastructure
  • Who owns it? — Service ownership must be clear
  • What depends on what? — Dependency mapping for impact analysis
  • How healthy is it? — Scorecards for quality standards

Production Readiness Scorecards

Instead of saying „you should really have that,“ scorecards make standards measurable:

Service: payment-api
━━━━━━━━━━━━━━━━━━━━
✅ Documentation    [100%]
✅ Monitoring       [100%]
⚠️  On-Call Rotation [ 80%]
❌ Disaster Recovery [ 20%]
━━━━━━━━━━━━━━━━━━━━
Overall: 75% - Bronze

Teams see at a glance where action is needed — without anyone pointing fingers.

Integration Is Everything

An IDP is only as good as its integrations:

  • CI/CD — GitHub Actions, GitLab CI, ArgoCD
  • Monitoring — Datadog, Prometheus, Grafana
  • IaC — Terraform, Crossplane, Pulumi
  • Ticketing — Jira, Linear, ServiceNow
  • Cloud — AWS, GCP, Azure native services

The Cultural Shift

The biggest challenge isn’t technical — it’s the shift from gatekeeping to enablement:

Old (Gatekeeping) New (Enablement)
„Write a ticket“ „Use the portal“
„We’ll review it“ „Policies are automated“
„Takes 2 weeks“ „Ready in 5 minutes“
„Only we can do that“ „You can, we’ll help“

Getting Started

The pragmatic path to an IDP:

  1. Start small — A software catalog alone is valuable
  2. Pick your battles — Don’t automate everything at once
  3. Measure adoption — Track portal usage
  4. Iterate — Take developer feedback seriously

Platform Engineering isn’t a product you buy — it’s a capability you build. IDPs are the visible interface to that capability.

Veröffentlicht am

Agentic AI in the SDLC: From Copilot to Autonomous DevOps

The Evolution Beyond AI-Assisted Development

We’ve all gotten comfortable with AI assistants in our IDEs. Copilot suggests code, ChatGPT explains errors, and various tools help us write tests. But there’s a fundamental shift happening: AI is moving from assistant to agent.

The difference? An assistant waits for your prompt. An agent takes initiative.

What Does „Agentic AI“ Mean for the SDLC?

Traditional AI in development is reactive. You ask a question, you get an answer. Agentic AI is different—it operates with goals, not just prompts:

  • Planning — Breaking complex tasks into actionable steps
  • Tool Use — Interacting with APIs, CLIs, and infrastructure directly
  • Reasoning — Making decisions based on context and constraints
  • Persistence — Maintaining state across multiple interactions
  • Self-Correction — Detecting and recovering from errors

Imagine telling an AI: „We need a new microservice for payment processing with PostgreSQL, deployed to our EU cluster, with proper security policies.“ An agentic system doesn’t just write the code—it provisions the database, creates the Kubernetes manifests, configures network policies, sets up monitoring, and opens a PR for review.

The Architecture of Agentic DevSecOps

Building autonomous AI into your SDLC requires more than just API keys. You need infrastructure designed for agent operations:

1. Agent-Native Infrastructure

AI agents need first-class platform support:

apiVersion: platform.example.io/v1
kind: AIAgent
metadata:
  name: infra-provisioner
spec:
  provider: anthropic
  model: claude-3
  mcpEndpoints:
    - kubectl
    - crossplane-claims
    - argocd
  rbacScope: namespace/dev-team
  rateLimits:
    requestsPerMinute: 30
    resourceClaims: 5

This isn’t hypothetical—it’s where platform engineering is heading. Agents as managed workloads with proper RBAC, quotas, and audit trails.

2. Multi-Layer Guardrails

Autonomous AI requires autonomous safety. A five-layer approach:

  1. Input Validation — Schema enforcement, prompt injection detection
  2. Action Scoping — Resource limits, allowed operations whitelist
  3. Human Approval Gates — Critical actions require sign-off
  4. Audit Logging — Every agent action traceable and reviewable
  5. Rollback Capabilities — Automated recovery from failed operations

The goal: let agents move fast on routine tasks while maintaining human oversight where it matters.

3. GitOps-Native Agent Operations

Every agent action should be a Git commit. Database provisioned? That’s a Crossplane claim in a PR. Deployment scaled? That’s a manifest change with full history. This gives you:

  • Complete audit trail
  • Easy rollback (git revert)
  • Review workflows for sensitive changes
  • Drift detection (desired state vs. actual)

Real-World Agent Workflows

Here’s what becomes possible:

Scenario: Production Incident Response

  1. Alert fires: „Payment service latency > 500ms“
  2. Agent analyzes metrics, traces, and recent deployments
  3. Identifies: database connection pool exhaustion
  4. Creates PR: increase pool size + add connection timeout
  5. Runs canary deployment to staging
  6. Notifies on-call engineer for production approval
  7. After approval: deploys to production, monitors recovery

Time from alert to fix: minutes, not hours.

Scenario: Developer Self-Service

Developer: „I need a PostgreSQL database for my new service, small size, EU region, with daily backups.“

Agent:

  • Creates Crossplane Database claim
  • Provisions via the appropriate cloud provider
  • Configures External Secrets for credentials
  • Adds Prometheus ServiceMonitor
  • Updates team’s resource inventory
  • Responds with connection details and docs link

No tickets. No waiting. Full compliance.

The Security Imperative

With great autonomy comes great responsibility. Agentic systems in your SDLC must be security-first by design:

  • Zero Trust — Agents authenticate for every action, no ambient authority
  • Least Privilege — Granular RBAC scoped to specific resources and operations
  • No Secrets in Prompts — Credentials via Vault/External Secrets, never in context
  • Network Isolation — Agent workloads in dedicated, policy-controlled namespaces
  • Immutable Audit — Every action logged to tamper-evident storage

Getting Started

You don’t need to build everything at once. A pragmatic path:

  1. Start with observability — Let agents read metrics and logs (no write access)
  2. Add diagnostic capabilities — Agents can analyze and recommend, humans execute
  3. Enable scoped automation — Agents can act within strict guardrails (dev environments first)
  4. Expand with trust — Gradually increase scope based on demonstrated reliability

The Future is Agentic

The SDLC has always been about automation—from compilers to CI/CD to GitOps. Agentic AI is the next layer: automating the decisions, not just the execution.

The organizations that figure this out first will ship faster, respond to incidents quicker, and let their engineers focus on the creative work that humans do best.

The question isn’t whether to adopt agentic AI in your SDLC. It’s how fast you can build the infrastructure to do it safely.

This is part of our exploration of AI-native platform engineering at it-stud.io. We’re building open-source tooling for agentic DevSecOps—follow along on GitHub.