Skip to main content

Sovereign cloud API management: keeping your gateway config and audit data inside your perimeter

How regulated enterprises deploy a sovereign cloud API gateway with full data residency — all config, audit, and traffic logs inside your own perimeter.

  • architecture
  • deployment
  • data-residency
  • regulated-industries
  • compliance
Zerq team

European financial institutions have a problem that most API gateway vendors quietly ignore. Every request that passes through a modern API gateway carries something sensitive: authentication tokens, request payloads, partner identifiers, internal routing decisions. That data (all of it) also flows into the gateway's configuration store and audit log. Where those records live matters as much as where the traffic goes.

Sovereign cloud API management means one thing: your API configuration, your audit trail, and your request logs stay inside your defined legal and geographic perimeter. No vendor-hosted control plane storing your API topology. No analytics pipeline shipping telemetry to a vendor's datacentre. No configuration database you cannot inspect, back up, or migrate independently.

For a bank operating under GDPR and Schrems II, or a healthcare organisation subject to patient data residency rules, or a government agency with boundary policy requirements, this is not a preference. It is a procurement requirement that eliminates most cloud-native API gateways from consideration before a proof of concept begins.

Why vendor control planes create a data residency problem

The architecture of most enterprise API gateways reflects how they were designed: as cloud services first, with on-premises support bolted on afterward.

Kong Konnect uses a cloud-hosted control plane in Kong's own infrastructure. API configuration, analytics, and audit events flow to Kong's systems before any data can appear in the platform's dashboard. The "self-managed" data plane runs in your environment, but the control plane does not.

Apigee is a Google Cloud product. Your API proxies, developer portal configuration, and analytics data live in Google's infrastructure. Google Cloud regions give you geographic choice within Google's system boundary, but that boundary is still Google's, not yours.

AWS API Gateway stores configuration in AWS infrastructure and routes all management operations through AWS systems. There is no deployment model where your API configuration database runs on your own hardware or in a sovereign cloud provider of your choosing.

Azure API Management offers EU region deployments, but the management plane has dependencies across regions, and the audit data model is designed around Azure Monitor. Your compliance data flows through Azure's logging infrastructure regardless of where the gateway sits.

MuleSoft Anypoint Platform requires connectivity to MuleSoft's Anypoint control plane for configuration synchronisation and analytics. Running it in a fully isolated environment means losing management plane functionality, not optional features.

What these platforms share is an architecture where the control plane (the component that stores configuration and produces audit records) is a service the vendor hosts. Retrofitting full data residency onto that architecture is not a configuration option. It would require replacing the control plane, which in practice means replacing the product.

How Zerq handles sovereign cloud deployment

Zerq's architecture starts from the opposite assumption. Every component that processes or stores your API configuration and audit data runs in your environment. The vendor receives nothing during normal operation. No configuration sync. No analytics pipeline. No telemetry.

The component model

A production Zerq deployment consists of six services, all running in your infrastructure:

┌──────────────────────────────────────────────────────────────┐
│   Your environment (sovereign cloud, private DC, or both)    │
│                                                              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │  Backend (Go binary)                                  │  │
│  │  Gateway runtime · Management API · Portal API · MCP  │  │
│  └──────────────────────────┬────────────────────────────┘  │
│                             │                                │
│  ┌──────────────┐  ┌────────┴──────┐  ┌──────────────────┐  │
│  │  MongoDB     │  │  KeyDB/Redis  │  │  Keycloak        │  │
│  │  config +    │  │  rate limit   │  │  (or your IdP)   │  │
│  │  audit data  │  │  state        │  │                  │  │
│  └──────────────┘  └───────────────┘  └──────────────────┘  │
│                                                              │
│  ┌───────────────────┐    ┌───────────────────────────────┐  │
│  │  Management UI    │    │  Developer Portal             │  │
│  │  (Next.js)        │    │  (Next.js)                    │  │
│  └───────────────────┘    └───────────────────────────────┘  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

The backend is a single Go binary. It serves four surfaces from one process: the gateway runtime that proxies API traffic, the management API that the admin UI calls, the developer portal API that partners interact with, and the MCP endpoints that AI agents use. There is no separate data plane process and no sidecar agent that makes outbound calls.

MongoDB holds your API configuration and your complete audit trail. This is your MongoDB instance: you provision it, you back it up, you control the retention policy. KeyDB (Redis-compatible) holds rate limit counters and optional response caches. Keycloak, or any OIDC-compatible provider you already run, handles identity. Every component is replaceable with your preferred equivalent.

Deploying in a sovereign cloud environment

The following Docker Compose configuration represents a baseline sovereign deployment. Every service runs in your environment. No external network dependency is required after the initial image pull.

services:
  backend:
    image: zerq/backend:latest
    environment:
      PORT: "8080"
      LOG_LEVEL: INFO

      # All management actions written to your MongoDB, never to Zerq systems
      AUDIT_ENABLED: "true"

      # Your MongoDB instance, in your sovereign cloud region
      MONGODB_URI: mongodb://mongodb:27017
      DB_NAME: api_gateway

      # Rate limit state, in your KeyDB instance
      REDIS_URL: redis://keydb:6379/0

      # Credential encryption (AES-256 at rest)
      JWT_SECRET: ${JWT_SECRET}
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}

      # Management plane identity via your OIDC provider
      OIDC_ENABLED: "true"
      BACKEND_OIDC_ISSUER_URL: https://auth.internal.example.com/realms/platform
      OIDC_AUDIENCE: api-gateway-management
      OIDC_ROLE_CLAIM_PATH: realm_access.roles

      # Role separation: auditors read logs, editors manage config
      OIDC_ADMIN_ROLES: admin
      OIDC_MODIFIER_ROLES: editor,admin
      OIDC_AUDITOR_ROLES: auditor,admin
      OIDC_VIEWER_ROLES: viewer,editor,admin

      # Public URL for gateway MCP and developer portal links
      BACKEND_PUBLIC_URL: https://api.internal.example.com

      # Auth methods the gateway enforces at runtime
      AUTH_METHODS_ENABLED: token,jwt,oidc,mtls

  frontend:
    image: zerq/frontend:latest
    environment:
      NEXT_PUBLIC_API_BASE_URL: https://api.internal.example.com
      NEXTAUTH_URL: https://admin.internal.example.com
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
      OIDC_ISSUER_URL: https://auth.internal.example.com/realms/platform
      OIDC_CLIENT_ID: api-gateway-frontend
      OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}

      # Optional: configure AI Copilot with a self-hosted LLM (Ollama or
      # any OpenAI-compatible endpoint), AI interactions stay in-perimeter
      AI_MODELS: '[{"id":"llama3","name":"Llama 3","provider":"openai","baseUrl":"http://ollama:11434/v1"}]'
      AI_DEFAULT_MODEL: llama3

  developer-portal:
    image: zerq/developer-portal:latest
    environment:
      NEXT_PUBLIC_API_URL: https://api.internal.example.com
      BACKEND_API_URL: http://backend:8080
      DEVELOPER_PORTAL_NEXTAUTH_URL: https://portal.internal.example.com

  mongodb:
    image: mongo:7
    volumes:
      # Persistent volume in your sovereign environment, you own the data
      - mongo_data:/data/db
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${MONGO_USERNAME}
      MONGO_INITDB_ROOT_PASSWORD: ${MONGO_PASSWORD}
      MONGO_INITDB_DATABASE: api_gateway

  keydb:
    image: eqalpha/keydb:latest
    volumes:
      - keydb_data:/data

volumes:
  mongo_data:
  keydb_data:

Every environment variable that references a sensitive value uses a ${VAR} reference to an injected secret; the actual values are never baked into an image or a config file checked into source control. The MongoDB and KeyDB volumes land in the storage layer of your sovereign cloud provider or your own data centre, not in any Zerq-managed infrastructure.

The audit trail stays in your MongoDB

Every management action (creating a collection, publishing a proxy, assigning a client to a profile, rotating a credential) produces a structured audit record in your MongoDB instance. With AUDIT_ENABLED=true (the default), no audit event is buffered or shipped elsewhere. The observability layer writes directly to your database.

An audit record from Zerq looks like this:

{
  "_id": "683b9a2c000000000000001f",
  "timestamp": "2026-05-25T09:14:22Z",
  "actor_id": "[email protected]",
  "actor_type": "user",
  "action": "UPDATE",
  "resource_type": "proxy",
  "request_id": "req_8fgHJk29mNpQr1Ts",
  "ip_address": "10.20.30.41",
  "user_agent": "Mozilla/5.0 (compatible; Zerq Admin UI)",
  "metadata": {
    "url": "/api/v1/collections/coll_payments/proxies/prx_psd2_balances",
    "request_body": "{\"status\":\"published\",\"rate_limit_policy\":\"pl_psd2_tpp\"}",
    "response_body": "{\"id\":\"prx_psd2_balances\",\"status\":\"published\"}",
    "status_code": 200
  }
}

Your compliance team can query this directly in MongoDB, export it to your SIEM, or use the audit log viewer in the management UI, all without routing data through Zerq's systems. The auditor OIDC role (OIDC_AUDITOR_ROLES: auditor,admin) gives read-only access to audit data for compliance officers, separated from the editor role that platform engineers use day-to-day. This is the separation of duties model that regulated industry audit requirements typically expect.

Request logs follow the same pattern

Runtime request logs (every API call through the gateway) land in the same MongoDB instance. Each record captures the client ID, profile ID, collection, target URL, HTTP status, latency, and optional payload snapshots. Your perimeter contains the complete operational picture: who called what, when, and what the gateway did with it.

{
  "id": "683b9b4d000000000000002a",
  "method": "GET",
  "path": "/v1/accounts",
  "target_url": "https://core-banking.internal/accounts",
  "status": 200,
  "latency": 142,
  "created_at": "2026-05-25T09:15:07Z",
  "client_ip": "203.0.113.45",
  "client_id": "cl_tpp_partner_a",
  "profile_id": "pr_oidc_fapi_advanced",
  "collection": "coll_psd2_accounts",
  "request_id": "req_zXa9Lm4kTbPd2Yqs"
}

These records support both operational dashboards and regulatory audit. A regulator asking for all third-party access to your payment accounts API in a given month is satisfied with a MongoDB query against your own data, not a vendor-generated report that arrives with lag and may not reflect the full picture.

Deploying in a truly air-gapped environment

Sovereign cloud deployment covers the case where you control the data residency boundary but still have internet access for image pulls and updates. Air-gapped deployment goes further: no outbound connectivity at all.

Zerq supports both modes with the same configuration. For air-gapped:

  1. Pull all container images to an internal registry during a maintenance window with network access.
  2. Update image references in your compose or Helm values to point to registry.internal.example.com/zerq/backend:VERSION.
  3. Set BACKEND_PUBLIC_URL to your internal gateway hostname.
  4. Configure BACKEND_OIDC_ISSUER_URL to point to your internally-hosted Keycloak instance.
  5. The Go binary serves all four surfaces from one process with no external runtime calls required to proxy traffic or enforce access controls.
  6. If you run Zerq Copilot for your platform team, configure AI_MODELS to point to an Ollama instance running locally. The LLM inference stays inside the perimeter as well.

After initial setup, no component in the stack makes outbound calls to Zerq's systems or any external dependency. The binary reads config from MongoDB, writes logs to MongoDB, enforces policies using state in KeyDB, and validates tokens against your OIDC provider. The traffic path is entirely self-contained.

What this looks like in practice

A European bank preparing for a PSD3 audit typically faces two pressures at once: demonstrating that third-party provider access is logged completely, and proving that audit data has not left the institution's data perimeter.

With a cloud-native gateway vendor, satisfying the second requirement requires a legal review of the vendor's data processing agreement, regional hosting options, and data retention controls. The conclusion is often that the vendor controls the audit database, so the bank must negotiate contractual protections that may satisfy the legal team but leave the platform team uncertain about what is actually stored where.

With Zerq deployed on their sovereign cloud infrastructure, the answer is architectural rather than contractual. The bank points to the MongoDB replica set running in their national cloud provider. The audit_logs collection is there, queryable, exportable. They control the backups. They control the retention. They control who has access via the OIDC_AUDITOR_ROLES config. When the regulator asks, they export the records directly from their own system.

The bank also controls their update cadence. A new Zerq binary version is pulled to an internal registry during a maintenance window. The Kubernetes rolling update replaces pods without dropping traffic because the readiness probe confirms each new pod is serving before the old one is terminated. Their SOC team never needs to open a firewall rule for the upgrade.

A sovereignty checklist for your API platform evaluation

Before evaluating any API gateway for a regulated deployment, validate these points with the vendor:

  1. Config database location: Does the vendor run the configuration store, or do you? Can you inspect and export it without proprietary vendor tooling?
  2. Audit log storage: Where do management audit events land? Can your compliance team query them directly, in real time?
  3. Request log storage: Where do runtime request logs land? Are payload fields captured within your environment?
  4. Control plane connectivity: Does the gateway runtime require outbound calls to the vendor to serve traffic, or only during deployment?
  5. License validation: Does the binary phone home for license checks? What happens in the event of a network partition?
  6. Analytics pipeline: Where does usage data go? Can you disable all telemetry entirely?
  7. Update mechanism: Can you pull new images from an internal registry and update without internet access to the vendor?
  8. Credential storage: Are API credentials and secrets encrypted at rest in your environment, using a key you hold?
  9. Identity provider: Can you bring your own OIDC provider, or does the vendor's IdP sit in the authentication chain?
  10. AI features: If the platform includes AI capabilities, can you run them against a self-hosted model with no outbound LLM API calls?

Zerq satisfies all ten points without configuration gymnastics. The security model was designed for this: every secret is encrypted with an ENCRYPTION_KEY you provide, credentials can reference your secrets manager instead of storing values directly, and no component in the stack has a hard dependency on Zerq's network infrastructure.

For regulated enterprises, that is the baseline. Audit compliance, partner access control, and AI agent governance all build on top of it, and sovereignty of the data layer is the prerequisite that everything else depends on.

Zerq is an enterprise API gateway built for regulated industries — one platform for API management, AI agent access, compliance audit, and developer portal, running entirely in your own infrastructure. See how it works or request a demo to walk through your specific requirements.

Request Enterprise DemoExplore capabilities