Digital public infrastructure sandbox

Problem

Building on Digital Public Infrastructure means integrating with rails a developer cannot freely experiment against: identity verification, messaging channels, and voice, each with its own contract, credentials, and rate limits. Wiring those into a prototype early is slow and risky, and there is no safe place to fail.

The platform is a sandbox that stands those rails up as local, contract-compatible services so a team can build and test an application end to end before touching a production provider. It follows an established DPI reference architecture pattern, so what works in the sandbox maps onto the real deployment.

How it works

The platform is a set of FastAPI microservices behind an API gateway. A shared auth service issues OAuth2/JWT tokens and manages sessions and admin users; a rate limiter, a health service, and a monitoring service run alongside it. PostgreSQL is the primary store for user management, service data, and audit logs, and Redis holds tokens, rate-limit counters, and short-lived data.

Around that core sit sandbox connectors, one per DPI channel: identity verification, one-way and two-way messaging, interactive voice, and an AI service. Each connector is its own service with its own container, so a developer can bring up only the rails their prototype needs. The AI service is a FastAPI content-generation and analysis service tuned for local-market context.

Everything is packaged for the full lifecycle. Docker Compose brings up the stack locally, Helm and Helmfile deploy it to Kubernetes across environments, and Terraform provisions the cloud infrastructure. Prometheus scrapes per-service metrics and Grafana visualizes them. Configuration is centralized and environment-scoped, with secrets kept out of the repo and secret-scanning wired into pre-commit and CI.

Developer -> API Gateway
   -> Auth Service (OAuth2/JWT, sessions, admin)  -> PostgreSQL / Redis
   -> Rate Limiter / Health / Monitoring
   -> Sandbox connectors: Identity | Messaging (1-way, 2-way) | Voice | AI service

  Ops: Docker Compose (local) / Helm + Helmfile (k8s) / Terraform (cloud)
       Prometheus -> Grafana

Hard parts

• One gateway, many rails: each DPI channel is an independent containerized service behind a shared gateway, so a prototype composes only the connectors it needs and each can scale and fail on its own.
• Contract-compatible sandboxing: the connectors mirror the shape of the real DPI providers so an application built against the sandbox maps onto production without a rewrite.
• Centralized, environment-scoped configuration with secrets kept out of the repository, enforced by a secret-scanning pre-commit hook and CI check.
• Full-lifecycle packaging: the same services run under Docker Compose locally, Helm/Helmfile on Kubernetes, and Terraform-provisioned cloud infrastructure, so local and deployed behavior stay aligned.
• Operational visibility from the start: per-service Prometheus metrics and Grafana dashboards, plus a dedicated health service and structured audit logging.

What it does

The clearest way to describe the platform is what it stands up for you: a one-command local bring-up of the gateway, auth, the supporting services, and the DPI connectors, with test-data generation and API docs for each rail. A developer gets a working, observable, contract-compatible environment to build a DPI application against before touching any production provider.

Artifacts

A microservices monorepo: an API gateway, an OAuth2/JWT auth service, rate-limiter, health, and monitoring services, and per-channel DPI sandbox connectors including an AI content service. Deployment assets for Docker Compose, Helm/Helmfile, and Terraform, with Prometheus and Grafana monitoring. Built for a public-sector developer program, so the source is not public.