Why platform engineering matters in federal
Federal agencies face a structural delivery problem: every new service must traverse an authorization process designed for monolithic systems built once and operated for decades. Modern delivery teams want to ship weekly, but the controls catalog (NIST 800-53 Rev 5), the FedRAMP authorization boundary, the agency authorizing official's risk acceptance, and the inherited POA&Ms all conspire to slow them down. Platform engineering exists to absorb that compliance burden in one place so that delivery teams can move fast on top.
Done well, a federal internal developer platform (IDP) compresses the time from "I have an idea for a microservice" to "it is deployed to production with an ATO" from 12 months to 12 days. Done poorly, it becomes a wrapper around the same problems. The difference is whether the platform is treated as a product with internal customers, or as an architecture document that nobody reads.
Platform-as-a-Product for federal agencies
The most important shift platform engineering brings to federal is the operating model. Rather than treating the platform as a one-time IT modernization project, it is operated as an internal product with:
- A product manager who owns the roadmap, gathers feedback from delivery teams, and prioritizes work against developer outcomes (lead time, deployment frequency, change failure rate, mean time to recover).
- A defined customer base — the agency's delivery teams. Not a captive audience: in mature federal IDP rollouts, teams choose to use the platform because it is the path of least resistance.
- Service level objectives for the platform itself: portal uptime, golden-path scaffolding latency, time from PR merge to deploy, time from new service to first authorized release.
- An adoption motion — onboarding sessions, office hours, paired implementation for the first few teams, and explicit graduation criteria.
- A retirement plan for legacy patterns the platform replaces.
The Platform-as-a-Product framing is what separates a real IDP from a SharePoint page that links to internal documentation. Federal agencies that have adopted this model — most notably the VA, the GSA's Technology Transformation Services, and parts of CMS — have seen disproportionate gains because every internal customer is a federal employee or contractor whose time is paid for by appropriated funds.
Backstage as the federal developer portal
Backstage, the CNCF incubating project, has emerged as the dominant developer portal for both commercial and federal IDPs. We deploy and customize Backstage for federal agencies with attention to several federal-specific concerns:
- Identity: OIDC integration with the agency's identity provider (Okta Federal, ICAM, AAD Government, or PIV/CAC via a broker). Group memberships from the IdP drive entity ownership in the Backstage catalog.
- Software templates: Scaffolder templates that produce a compliant repo from a single form submission. Templates wire in the approved CI/CD pipeline, the cleared base image, the standard Terraform modules, the SBOM step, the secrets-management pattern, and the observability hooks.
- TechDocs: Markdown-as-code documentation rendered alongside each service. Hosted on internal S3 (GovCloud) or Azure Blob (Government). No outbound calls to external CDNs.
- Catalog: The single inventory of every service, system, API, library, and team. Crucial for system boundary documentation and authorization package generation.
- Plugins: Curated set of plugins for Argo CD, GitHub Actions or GitLab CI, Kubernetes, cost insights, and security scan results. We avoid third-party SaaS plugins that would push data outside the authorization boundary.
- Air-gapped operation: Backstage runs cleanly inside disconnected enclaves with internal NPM registry, internal git, and internal container registry.
Golden paths and paved roads
A golden path is the opinionated, pre-authorized way to build a specific kind of service. The agency does not need to standardize on one language or one cloud — it needs to standardize on the contract between a service and the platform. Typical federal golden paths we have implemented:
- REST API on Kubernetes — Python (FastAPI) or Go, deployed to EKS in GovCloud, with Istio sidecar, OpenTelemetry instrumentation, and inherited ATO controls from the platform.
- Batch ETL job — containerized job triggered by EventBridge, writing to the agency data lake with audit trail to the SIEM.
- ML inference endpoint — model registered in MLflow, served via KServe, with model card published to the catalog. See federal MLOps.
- Static documentation site — built and deployed via the platform's CI/CD, served from cloud.gov Pages or a hardened CDN.
- Event-driven worker — Kafka or SNS/SQS consumer with dead-letter queue, retry policy, and structured logging.
Each golden path comes with an attached controls inheritance document mapping the path to the relevant NIST 800-53 controls satisfied by the platform. That document is the artifact an authorizing official wants to see. When a delivery team uses the path unmodified, they inherit the controls. When they deviate, they document the deviation and the compensating control.
The platform team
A federal platform team typically has three internal sub-functions:
- Core platform engineering — owns the Kubernetes substrate, Terraform modules, networking, secrets management, identity integration. These engineers tend to come from SRE or cloud architecture backgrounds.
- Developer experience — owns Backstage, the software templates, the CLI, the documentation, the onboarding flow. These engineers tend to come from product engineering backgrounds and focus on internal user experience.
- Platform security — owns the supply chain, the policy engine (OPA Gatekeeper or Kyverno), the runtime security tooling, and the relationship with the agency information system security manager (ISSM).
The smallest viable team is four engineers and a platform lead. Once the platform serves more than three delivery teams or hosts more than ten production services, a dedicated platform product manager is required.
Federal compliance baked into the platform
A federal IDP is not just a developer convenience — it is a compliance instrument. Controls we build into the platform substrate so that delivery teams inherit them:
- AC family (access control) — RBAC tied to the IdP, just-in-time elevation for production, session recording for privileged operations.
- AU family (audit and accountability) — every platform action and every workload event shipped to the agency SIEM, retained per the agency records schedule.
- CM family (configuration management) — every change is a pull request, every cluster state declared in git, drift detection runs continuously.
- SC family (system and communications protection) — service mesh mTLS by default, network policy default-deny, all inbound traffic through the authorized ingress.
- SI family (system and information integrity) — image signing verified at admission, runtime anomaly detection, vulnerability scanning at build and at runtime.
The result is that the authorization package for a new service running on the platform is a delta document, not a 600-page recreation of every control.
Measuring platform value
The platform team must measure itself or it will be cut in the next budget cycle. Metrics we track from day one:
- DORA metrics per delivery team using the platform: deployment frequency, lead time for changes, change failure rate, mean time to recover.
- Platform adoption — number of teams onboarded, number of services on the platform, percentage of new agency services launched on the platform.
- Platform reliability — portal uptime, scaffold success rate, pipeline mean time to feedback.
- Compliance velocity — average days from new service kickoff to first authorized production release.
- Cost — platform infrastructure cost per delivery team, normalized.
Federal reference patterns
Two federal patterns inform how we build IDPs:
- DoD Platform One — the Air Force's reference DevSecOps platform. Iron Bank for hardened images, Big Bang for the platform itself, Party Bus for managed delivery. We build agency platforms that compose well with Platform One artifacts where appropriate.
- cloud.gov — GSA's FedRAMP-authorized PaaS, a model for what a federal agency-as-platform-provider looks like at the small end.
Who we build platforms for
- DoD — Platform One-aligned IDPs for service-component delivery teams.
- VA — multi-tenant platforms for the Lighthouse API program and digital service teams.
- HHS — IDPs for CMS and ONC modernization initiatives.
- GSA — extending cloud.gov patterns to component agencies.
- DHS — platforms for component-level delivery teams.