What is Nexo?

Nexo is a policy enforcement proxy for MongoDB. Applications connect to Nexo instead of directly to MongoDB, and an ordered, protocol-aware pipeline can observe, allow, modify, cache, route, or reject database traffic before it reaches the upstream server.

This makes policy and operational controls reusable across applications without requiring every service to implement them independently.

:::info Release accuracy

Nexo is in Private Preview. Entitlement, CRD admission, Operator reconciliation, and runtime execution are separate claims. Always check the component catalog and the selected release bundle before relying on a capability.

:::

The problems Nexo addresses

MongoDB estates commonly accumulate concerns that are difficult to solve consistently inside every application:

• Driver and server compatibility: coordinated driver upgrades can become a long migration involving libraries, tests, and many services.
• Wire-level observability: application telemetry does not always identify the exact commands, namespaces, response sizes, or proxy processing stages involved.
• Traffic control: changing embedded connection strings is a poor mechanism for migrations, shadowing, canaries, or backend selection.
• Governance and audit: identity, query policy, masking, and audit evidence become inconsistent when implemented separately by each service.
• Multi-tenant safety: application bugs can omit tenant filters or route requests to an unintended backend.
• Performance controls: connection pooling, query limits, caching, and request shaping otherwise require repeated application changes.

These concerns share a common need: a programmable layer in the database traffic path.

How Nexo works

Nexo accepts MongoDB client connections and forwards permitted traffic to an upstream MongoDB deployment. It understands MongoDB wire messages and BSON rather than treating the connection as an opaque TCP stream.

Clients continue using a standard MongoDB connection string. No Nexo-specific database driver or application SDK is required.

Request lifecycle

1. Connection admission: the listener accepts TCP/TLS connections and applies the configured connection, identity, authentication, and capacity controls.
2. Protocol decoding: Nexo parses supported MongoDB wire messages, correlates request IDs, and identifies the command and namespace.
3. Request pipeline: ordered request steps inspect the message. A step may observe, modify, reject, route, or short-circuit it.
4. Upstream dispatch: an accepted request is sent through the selected MongoDB connection.
5. Response pipeline: the response is correlated and processed through response steps, which may measure, mask, transform, cache, or audit it.
6. Client response: the final MongoDB response is returned over the original connection.

See How Nexo works and the pipeline model for the exact phase model.

Key capability areas

Area	Examples	Important boundary
Connection management	TLS, authentication strategy, limits, pooling	Confirm the selected bundle's connection contract
Compatibility	Handshake and wire-version compatibility behavior	Compatibility is scoped; it is not arbitrary protocol translation
Observability	Logging, metrics, audit, query analysis	Captured data can be sensitive and requires retention/access controls
Request policy	Access rules, size limits, rate limits, query guard	A listed entitlement does not prove runtime enforcement
Transformation	Query rewrite, PII masking, field encryption	Validate BSON semantics and key-management requirements
Traffic	Read/write selection, weighted traffic, shadowing	Router-phase support is release-dependent
Performance	Pooling and response caching	Preserve authorization scope and invalidation correctness

Detailed behavior, examples, limitations, and diagrams are available in the component reference.

Architecture

Nexo separates customer data traffic from management and reconciliation:

• Nexo Proxy runtime handles MongoDB connections and executes the active pipeline.
• Nexo Operator reconciles Kubernetes custom resources and workloads.
• Nexo Manager connects an environment to the management plane and performs approved lifecycle operations.
• Nexo Control Plane stores product configuration, revisions, environment state, entitlement, and rollout intent.
• nexoctl provides supported diagnostics and development workflows.

The customer-facing release bundle is the compatibility unit. Individual component versions remain visible for diagnostics, but arbitrary combinations are not implied to be supported.

Explore the control and data plane architecture.

Deployment models

The documented production model is Manager-managed Kubernetes: install Nexo Edge in a cluster and let the Manager and Operator reconcile the selected release bundle and Proxy workloads.

Shared Proxy pools are possible when centralized policy and independent scaling are appropriate. Other legacy deployment claims, including public standalone installers, Docker Compose quickstarts, sidecars, and air-gapped distributions, are unavailable unless a release-specific guide explicitly publishes them.

See installation and modes and deployment topologies.

Common use cases

Centralized MongoDB policy

Apply request limits, rate controls, access decisions, audit, and masking in one managed traffic layer. Database-native authorization remains foundational; Proxy policy is an additional control and must be verified as active.

Safer upgrades and migrations

Use published compatibility behavior to decouple selected client/server upgrade steps. Where supported, traffic and shadow components can help compare backends or staged changes. Do not assume router execution from CRD presence alone.

Wire-level observability

Record command, namespace, latency, result, and connection measurements without adding instrumentation to every service. Avoid collecting full payloads unless necessary and protect logs as sensitive data.

Multi-tenant controls

Use authenticated, non-spoofable identity and fail-closed policy. Tenant Isolation is not a substitute for database authorization, application validation, or data modeling, and its execution status must be checked for the deployed release.

Performance protection

Bound connections and request rates, apply query budgets, identify expensive query shapes, and use authorization-scoped caching where the consistency model allows it. Legacy performance percentages are not benchmarks or guarantees.

How Nexo differs

Product	Primary role	Difference from Nexo
ProxySQL	MySQL-aware proxy	Targets MySQL rather than MongoDB
PgBouncer	PostgreSQL connection pooler	Focuses on PostgreSQL pooling, not MongoDB policy pipelines
Envoy	General-purpose network/application proxy	Broad proxy platform; Nexo is purpose-built around MongoDB messages and pipeline contracts
mongos	MongoDB sharded-cluster router	Core MongoDB routing infrastructure, not a customer-extensible policy gateway

Nexo can sit in front of a supported MongoDB endpoint, including a mongos, but it does not replace MongoDB topology, authorization, replication, or sharding responsibilities.

Start evaluating

1. Review protocol maturity and compatibility.
2. Choose only components marked executable for your release.
3. Follow the MongoDB quickstart.
4. Validate behavior in a disposable environment before production traffic.
5. Review the production checklist and security architecture.

For plans and limits, see Pricing.