Skip to main content
Version: Next (Private Preview)

Deployment topologies

The supported Private Preview path is a customer-managed Kubernetes environment installed from an authenticated, version-pinned command supplied by the Nexo console. Applications connect to a customer-controlled Service; Proxy workloads connect to the customer's MongoDB endpoint.

Logical components

ComponentPlacementResponsibility
Control PlaneHosted management serviceIdentity, projects, environments, revisions, release metadata, orchestration, licensing, and status
ManagerCustomer Kubernetes clusterOutbound management connection, inventory, command execution, and acknowledgement
OperatorCustomer Kubernetes clusterResolve supported custom resources and reconcile generated workloads
ProxyCustomer Kubernetes clusterAccept MongoDB traffic and execute the supported pipeline
MongoDBCustomer-selected upstreamAuthentication, authorization, storage, durability, and database behavior

Connection lifecycle

  1. Accept the client connection.
  2. Establish configured TLS where supported.
  3. Process the MongoDB handshake and authentication passthrough.
  4. Select the validated active pipeline.
  5. Execute supported request components.
  6. Connect to the configured upstream and forward permitted operations.
  7. Execute supported response components and return the reply.
  8. Close or drain the connection during client disconnect or runtime shutdown.

The exact authentication, discovery, transaction, retry, compression, and drain behavior is release-specific.

Available topology

Manager-managed Kubernetes

One environment identity binds a Manager installation to a registered Kubernetes environment. Manager applies approved desired state, Operator reconciles namespaced resources, and the Proxy remains in the application traffic path. The management path is separate from MongoDB traffic.

Use this topology for both isolated evaluation and any production-readiness work. Obtain the install command from the console; do not reconstruct repository URLs, image tags, or credentials from legacy examples.

Shared Proxy service

Multiple applications can connect to a shared Nexo Service when their network, availability, identity, and policy requirements are compatible. Scale Proxy replicas and upstream capacity together, and avoid combining workloads whose blast-radius or data handling requirements require isolation.

Unavailable or contract-dependent topologies

Legacy topologyCurrent status
Standalone binary on VM or bare metalNo public supported distribution or installation contract
Docker or Docker ComposeNo public supported distribution
Manual application sidecarNo supported installation or lifecycle contract
Automatic sidecar injectionUnavailable
Public Helm repositoryUnavailable; use the authenticated console command
Self-hosted Control PlaneContract-dependent and not published as an available path
Air-gapped operationContract-dependent and not published as an available path
Nexo-managed database traffic serviceUnavailable; the data plane is customer-hosted

Configuration and rollout model

  1. Author and validate a project revision.
  2. Resolve it against the target environment and release bundle.
  3. Deliver an authorized operation to Manager.
  4. Reconcile the supported custom-resource graph.
  5. Observe rollout status and verify the active graph revision.

A successful save or deploy request proves desired-state acceptance, not runtime activation. Do not manually patch generated workloads as a normal rollout mechanism.

Ownership model

  • Platform teams operate clusters, networks, releases, and shared guardrails.
  • Application teams select supported pipelines and validate workload behavior.
  • Security teams review identity, data handling, admission, audit, and exception controls.
  • Database teams remain responsible for MongoDB availability, authorization, backups, topology, and capacity.

Next steps

Search Nexo documentation

Type to search titles, headings, and page content.