What the customer provides
| Field | Purpose |
|---|---|
| Connection string | A mongodb:// or mongodb+srv:// URI for the cluster. The SRV form is typical for Atlas; the standard form is typical for self-hosted. |
| Database name | The database the appliance’s services should connect to. |
| Username | The MongoDB user the appliance authenticates as. |
| Password (or workload-identity reference) | The credential for the database user. Atlas Workload Identity is supported where the customer has it configured. |
| CA certificate (optional) | The trust anchor for the cluster’s TLS certificate. Atlas uses a public CA by default; customers using private peering or self-hosted MongoDB may need to supply a custom CA. |
What changes in the deployment stack
When customer-provided MongoDB is selected, the compiler:- Drops the default-shipped MongoDB instance from the deployment stack (no cluster provisioning, no automated backups, no scaling configuration).
- Wires the appliance’s services to the customer’s connection string and database.
- Injects the customer’s credentials as secrets the services read at startup.
What the customer takes on
When your customer brings their own MongoDB, they own:- Cluster provisioning and tier sizing.
- Network access configuration so the appliance can reach the cluster. For Atlas this is an IP allowlist, PrivateLink, or VPC peering. For self-hosted MongoDB this is typically VPC/security-group configuration.
- Backup configuration, including continuous backups and point-in-time recovery (Atlas tier feature, or the customer’s own backup tooling for self-hosted).
- Patching, version upgrades, and major-version migrations.
- High-availability, replica-set topology, and cross-region replication.
- Monitoring and alerting on the MongoDB side.
What stays your responsibility
- All application-level concerns: data model, query performance, application-managed migrations, index strategy.
- Your services continue to be observable through Tensor9’s normal mechanisms.
- Operations commands that operate on the appliance’s services still work normally. Operations commands cannot reach into your customer’s MongoDB.
Deployment notes
Atlas (public endpoint) - the path of least friction. The appliance reaches the Atlas cluster over the public internet, authenticated by user/password and gated by an Atlas IP allowlist that includes the appliance’s egress. Atlas + PrivateLink - the recommended production posture when the customer is on Atlas. PrivateLink removes the public-internet route to the cluster entirely; the appliance reaches Atlas via a private endpoint in the customer’s VPC. Self-hosted MongoDB - the customer runs MongoDB themselves (commonly on Kubernetes via the MongoDB Operator, or on VMs/bare metal). The appliance treats it like any other MongoDB endpoint - only the connection string changes. The customer owns operations, backup, and upgrades. In all three cases, read preferences and write concerns stay defined by your application; the customer’s deployment must support whatever your application requires.Authentication and rotation
The username and password (or workload-identity reference) are stored as Customer-Supplied Secrets - Tensor9 has no visibility into the underlying value. The appliance reads them at startup. Two rotation paths:- Static password: rotate the database-user password in Atlas (or the customer’s MongoDB) and update the secret in the customer’s secret store; restart the affected services.
- Atlas Workload Identity: the appliance authenticates to Atlas using a customer-supplied OIDC token; the underlying token is refreshed by the identity provider on its own cadence, so no service restart is needed for credential rotation.