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. There is also no support mode in which a Zerq engineer can query your MongoDB. That is a consequence of the architecture, not a policy that a future terms update could revoke: data that never leaves your environment cannot be accessed from outside it.

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.

Where these records live matters because audit data often becomes regulated data itself. Under GDPR, audit records of calls that process personal data can carry user IDs, email addresses in request parameters, or IP addresses; with the records in your own MongoDB, you remain the controller and do not rely on a vendor's data processing agreement to justify their location. Under HIPAA, audit records that capture PHI become PHI, and storing them in a vendor's SaaS brings a Business Associate Agreement and a vendor security review into scope. For PCI DSS, SOX, and national banking rules that require access-controlled audit trails for defined periods, your existing database access controls, backup policy, and retention configuration simply apply.

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.

What else lives in your data layer

Audit and request logs are the records compliance teams ask about first, but they are not the only categories in your MongoDB:

  • Gateway configuration. Collections, proxies, workflows, policies, access profiles, upstream targets, authentication rules, and rate limit settings. If an auditor asks what the rate limits on the payments endpoint were on a given date, the answer comes from your database.
  • Client and credential metadata. Which client has access to which products, when credentials were issued, and when they expire. Credential values themselves are encrypted at rest.
  • Metrics. Request volume, latency distributions, error rates, and breakdowns by product, partner, and endpoint, with granularity and retention set by your capacity and configuration.
  • Platform users and sessions. Management console accounts, role assignments, and session records.

KeyDB holds a different kind of data. Rate limit counters exist so that multiple gateway replicas enforce one shared quota instead of per-replica counts a client could game by spreading requests. That is a correctness concern, not a persistence one: the counters do not need to be backed up or treated as a compliance asset, and cached responses are short-lived and contain no audit data.

Operating the data layer yourself

Owning the data layer is the point, but it is also an operational commitment. Plan for four things:

  • You own the backup. Zerq does not back up your data. Your existing MongoDB backup and restore procedures apply to gateway configuration and audit records, the same as any other compliance-relevant store.
  • You choose the topology. Zerq connects through a standard MongoDB connection string, so single-node for development, a replica set for production HA, or a multi-region replica set for geographic redundancy all work. That includes self-managed clusters and managed MongoDB-compatible services such as Atlas or Azure Cosmos DB for MongoDB; Amazon DocumentDB works with limitations, so check compatibility. For sovereignty purposes, the region and operator you pick for that database are your residency answer.
  • You control access. You can show auditors that the audit collection is writable only by the gateway service account and readable only by your compliance team, using MongoDB controls already inside your security review scope.
  • You manage the connection secret. The connection string is a credential like any other: rotate it and hold it in Vault or your preferred secrets manager.

The database schema is created on first startup and indexes are applied automatically, so routine version upgrades need no separate migration tooling.

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

Illustrative scenario, not a specific customer deployment.

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