If your origin stack uses MongoDB as its document store, your customer can supply their own MongoDB Atlas cluster (or other MongoDB deployment) and the compiler will emit a deployment stack that talks to it instead of provisioning a default-shipped MongoDB.Documentation Index
Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
Use this file to discover all available pages before exploring further.
What the customer provides
| Field | Purpose |
|---|---|
| Connection string (SRV URI) | The mongodb+srv://... URI for the Atlas cluster. Includes the cluster hostname; database and credentials are supplied separately. |
| Database name | The database the appliance’s services should connect to. |
| Username | The Atlas database user the appliance authenticates as. |
| Password (or Atlas Workload Identity reference) | The credential for the database user. |
| TLS settings (optional) | Atlas uses TLS by default with a public CA; customers using private peering or self-hosted MongoDB may need to supply a custom CA. |
What changes at compile time
When customer-provided Mongo Atlas 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 Atlas cluster, they own:- Atlas project, cluster, and tier sizing.
- Atlas network access configuration (IP allowlist, PrivateLink, or VPC peering) so the appliance can reach the cluster.
- Backup configuration, including continuous backups and point-in-time recovery (Atlas features the customer enables on their tier).
- Patching, version upgrades, and major-version migrations.
- High-availability and cross-region replication (Atlas features the customer configures on their tier).
- Monitoring and alerting on the Atlas side (Atlas’s built-in dashboards plus any external observability the customer wires in).
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 Atlas cluster.
Atlas-specific considerations
- Network access must be configured on the Atlas side before the appliance can connect. PrivateLink is the recommended path for production deployments because it removes the public-internet route to the cluster entirely.
- Read preferences and write concerns stay defined by your application; the customer’s Atlas tier must support whatever your application requires.
- Backup and PITR are Atlas-tier features. Customers on free or shared tiers may not have the same backup guarantees as customers on dedicated tiers.