Your Config and Audit Data Should Never Leave Your Perimeter — Here's How Zerq Enforces That

Most enterprise API gateway platforms have a topology that looks like this: the data plane runs in your environment, but the control plane — the thing that stores your configuration, processes your audit logs, and manages your credentials — lives in the vendor's SaaS. Your data travels out to them. Their engineers can theoretically see it. Your compliance team has to evaluate their security practices, their subprocessors, and their data residency claims.

Zerq's architecture inverts this. The entire platform, including the data layer, runs in your environment. Config and audit data go into MongoDB — your MongoDB instance, in your data center or cloud tenant, in your region, under your backup and access policies.

This is not a "self-hosted option." It is the only deployment model. There is no Zerq-operated control plane that your configuration passes through.

What data lives in MongoDB

Understanding what specifically is stored in your MongoDB instance is worth being precise about, because different categories of data have different compliance implications.

Gateway configuration. Collections, proxies, workflows, policies, access profiles, and all other configuration objects that define how your API products behave. This includes endpoint definitions, upstream targets, authentication rules, rate limit settings, and workflow steps. If a compliance auditor asks "what were the rate limits on the payments endpoint on this date?" — the answer comes from your MongoDB.

Client and credential metadata. Client records, access profile assignments, and credential metadata. Credential values themselves are encrypted at rest. The metadata (which client has access to which products, when credentials were issued, when they expire) is in MongoDB.

Audit records. Every API call through the gateway generates a structured audit record. Every configuration change made through the Management UI or Management API generates an audit record. These records include: actor identity, resource affected, change type, timestamp, and the before/after diff for configuration changes. These records are the evidence trail your compliance team uses for access reviews and incident investigation.

Metrics and observability data. Request volume, latency distributions, error rates, and traffic breakdowns by product, partner, and endpoint. The granularity and retention depend on your MongoDB capacity and your configuration.

User and session management data. Platform user accounts, role assignments, and session records for the management console.

None of this data leaves your environment. It does not travel to a Zerq-operated SaaS. It does not pass through a vendor-operated message bus. It is read and written by the Zerq services running inside your perimeter.

What Redis is used for

Redis is optional but recommended for production deployments. It serves two purposes:

Distributed rate limit state. When you run multiple gateway replicas (which you should in production), rate limits need to be evaluated against a shared counter, not per-replica counters that would allow a client to exceed their quota by spreading requests across replicas. Redis provides the atomic increment operations needed for distributed rate limiting. This is a performance and correctness concern, not a persistence concern — rate limit state in Redis does not need to be backed up or treated as a compliance asset.

Caching. Optional response caching for configured endpoints. Cache entries are short-lived and do not contain sensitive audit data.

Like MongoDB, Redis runs in your environment. It is not a managed service operated by Zerq.

The compliance implications

For regulated industries, the data residency question is not abstract.

GDPR and data residency requirements. Under GDPR, if your API calls process personal data, the audit records of those calls may contain personal data references (user IDs, email addresses in request parameters, IP addresses). Where those records are stored — and who can access them — is a compliance question. Because audit records go to your MongoDB instance in your region, you control the residency. You are the data controller. You are not relying on a vendor's data processing agreement to justify where your data goes.

Financial services — transaction audit requirements. PCI DSS, SOX, and various national banking regulations require audit trails to be maintained for specified periods with access controls on who can read and modify them. Because Zerq's audit data is in your MongoDB, you apply your existing database access controls to it. Your DBA team, your backup policy, and your retention configuration apply. There is no vendor process you need to evaluate.

Healthcare — PHI handling. If your APIs serve healthcare data and the audit records capture request parameters that include PHI, those audit records become PHI under HIPAA. Storing PHI in a vendor's SaaS requires a Business Associate Agreement and an evaluation of the vendor's security practices. Storing PHI in your own MongoDB instance puts you in control of the BAA landscape — it is your instance, your controls.

Air-gapped and classified environments. In environments where no data may leave the network boundary under any circumstances, a vendor SaaS control plane is not an option. Zerq's architecture works in fully offline environments because there is no required outbound connection to a vendor-operated service. The gateway reads config from MongoDB, writes audit records to MongoDB, and never makes a network call outside your perimeter for platform operations.

What happens when you run your own MongoDB

Running your own MongoDB instance for a production platform means a few things to plan for:

You own the backup. Zerq does not backup your data. Your MongoDB backup policy applies. For a platform with compliance requirements, this means your existing database backup and restore procedures apply to the gateway's configuration and audit data — consistent with how you treat other compliance-relevant data stores.

You choose the topology. Single-node for development. Replica set for production HA. Multi-region replica set for geographic redundancy. You can run MongoDB Atlas in your cloud tenant, MongoDB Atlas in a specific region, or a self-managed MongoDB cluster on your own infrastructure. Zerq supports all of these because it connects to MongoDB via a standard connection string.

You control access. Who can read the audit collection in MongoDB? You decide, using MongoDB's access control model. For compliance purposes, this is a feature: you can demonstrate to auditors that audit records are write-accessible only to the gateway service account and read-accessible only to your compliance team, using controls that are already in your security review scope.

You manage credentials. The connection string used by Zerq to connect to MongoDB is a secret you manage. Rotation, secret management via Vault or your preferred secrets manager, and access control on the connection string are your operational concerns — consistent with how you manage credentials for other services in your environment.

What Zerq does not have access to

To be explicit: Zerq as a company does not have a mechanism to access your configuration or audit data. There is no telemetry pipeline from your instance to Zerq's infrastructure. There is no support mode where a Zerq engineer can query your MongoDB. The gateway binary does not phone home with operational data.

This is not a promise that can be revoked by a future policy change — it is a consequence of the architecture. Data that does not leave your environment cannot be accessed from outside it.

The practical setup

Connecting Zerq to your MongoDB instance is a standard MongoDB connection string in your environment configuration:

MONGODB_URI=mongodb://user:password@your-host:27017/zerq

Or for a replica set:

MONGODB_URI=mongodb://user:password@host1:27017,host2:27017,host3:27017/zerq?replicaSet=rs0

Or for Atlas:

MONGODB_URI=mongodb+srv://user:[email protected]/zerq

The same pattern applies to managed MongoDB services from any provider: Atlas, Azure Cosmos DB for MongoDB, Amazon DocumentDB (with limitations — check compatibility), or self-managed clusters.

The database schema is created on first startup. Indexes are applied automatically. There is no separate migration tooling required for routine version upgrades.

See Zerq's architecture page for the full data layer overview and deployment options, or request a demo to walk through the data residency and compliance questions specific to your environment.