Skip to main content

Choosing Your MongoDB Deployment

Monk supports multiple MongoDB deployment options - from local development containers to enterprise-grade managed clusters. Choose based on your needs, budget, and scale.

Option 1: Self-Hosted (Development & Testing)

Best for: Local development, testing, proof-of-concept How it works: When deploying an app that uses MongoDB, Monk detects it and defaults to self-hosted:
Monk: “I detected MongoDB in your code. Use self-hosted container for development?” Features:
  • Free (runs on your infrastructure)
  • Quick setup (< 1 minute)
  • Full control over version and configuration
  • Persistent storage automatically configured
Backup: Manual procedures (mongodump/mongorestore)

Option 2: Cloud-Managed Databases

Best for: Production deployments, simplified operations

DigitalOcean Managed MongoDB (4.4-7.0)

Features:
  • Automated daily backups (7-day retention)
  • Automatic security updates
  • High availability options
  • Vertical scaling (resize anytime)

Option 3: MongoDB Atlas (Enterprise Features)

MongoDB Atlas offers different tiers for different needs: Free Tier (M0) - 512MB:
  • Perfect for prototypes and learning
  • Shared cluster
  • No backup API support
  • No credit card required
Dedicated Clusters (M10, M20, M30):
  • Production workloads
  • Automated backups with point-in-time restore
  • Performance optimization tools
  • Advanced security features
  • Dedicated resources
Serverless (Flex):
  • Pay only for what you use
  • Automatic scaling
  • No capacity planning needed

Before You Start

Your application must already use MongoDB in its code - Monk deploys and configures the database, but your application needs to have MongoDB drivers/ODM integrated. What Monk detects:
  • MongoDB drivers in your dependencies (mongoose, mongodb, pymongo, etc.)
  • MongoDB connection strings in your code
  • Database configuration files
If your app doesn’t use MongoDB yet, you’ll need to add the integration to your code first.

Deploying Self-Hosted MongoDB

When Monk Detects MongoDB

During deployment, Monk analyzes your code:
If Monk finds MongoDB in your code, it will ask: “I detected your app uses MongoDB. How would you like to deploy it?”
  • Self-hosted (container)
  • Cloud-managed (DigitalOcean)
  • MongoDB Atlas
Choose self-hosted for development or testing. What Monk does:
  1. Creates containerized MongoDB instance
  2. Generates unique credentials
  3. Wires connection to your application
  4. Sets up persistent storage
  5. Injects connection details as environment variables
Connection details: Monk automatically configures your application with:
  • Database host and port
  • Username and password
  • Database name
  • Connection string (MONGODB_URI or DATABASE_URL)
Your existing MongoDB code works without changes - Monk just provides the database.

Security

Monk applies security best practices automatically:
  • Unique credentials - Each deployment gets unique username/password
  • Network isolation - Database not publicly accessible
  • Internal-only access - Only your application can connect
  • Persistent storage - Data survives container restarts

Customization

Need specific MongoDB configuration?
Monk understands MongoDB-specific parameters.

Deploying MongoDB Atlas

Setting Up Credentials

Before deploying to Atlas, you’ll need credentials. See MongoDB Atlas Integration for detailed setup instructions. Quick summary:
  1. Create Organization API Key in Atlas
  2. Grant permissions: Project Creator, Cluster Manager, User Admin
  3. Save Public Key (Client ID) and Private Key (Client Secret)
  4. Note your Organization Name

Deploying

When deploying an app that uses MongoDB, tell Monk you want Atlas:
Monk: “I detected MongoDB. How should I deploy it?”
Or be specific upfront:
Monk will request:
  • Your Atlas credentials (if not already configured)
  • Which tier you want (M0, M10, M20, M30, Flex)
  • Preferred cloud provider and region for the cluster

Choosing Your Tier

For development/testing:
→ M0 (512MB, shared, free) For production:
→ Dedicated cluster with backups (starts ~$57/month) For serverless:
→ Pay-per-use, automatic scaling

What Monk Manages

When deploying to Atlas, Monk:
  • ✅ Creates Atlas project in your organization
  • ✅ Provisions cluster with your specifications
  • ✅ Creates database user with appropriate permissions
  • ✅ Configures IP whitelist (automatically allows your application)
  • ✅ Generates connection string
  • ✅ Injects credentials into your application
Security:
  • Project-level isolation
  • Role-based database users (readWrite by default)
  • Automatic IP whitelisting for your cluster
  • TLS encryption enforced

Backups (M10+ Only)

Dedicated clusters (M10 and above) support backups:
→ See Backup & Restore Guide for complete backup operations
M0 free tier does not support backup API. For production data, use M10+ dedicated clusters which include automated daily backups and point-in-time restore.

Deploying Cloud-Managed MongoDB

DigitalOcean Managed MongoDB

When deploying to DigitalOcean with a MongoDB app:
Monk: “Your app uses MongoDB. Should I use DigitalOcean managed MongoDB?” Or specify upfront:
Monk will ask:
  • Your DigitalOcean API token (if not configured)
  • MongoDB version (4.4, 5.0, 6.0, 7.0)
  • Node count (1, 2, or 3)
  • Instance size
What you get:
  • Automated daily backups
  • 7-day retention
  • Automated security patches
  • High availability (with 2+ nodes)
→ See DigitalOcean Databases for details

Comparing Deployment Options

Not sure which to choose? Ask Monk:
General guidance:

Switching Between Deployment Types

From Self-Hosted to Managed

Already deployed with self-hosted MongoDB? Tell Monk you want to switch:
What Monk does:
  1. Provisions new MongoDB (Atlas/managed service)
  2. Updates application configuration with new connection details
  3. Redeploys application with updated config
Data migration is manual. Monk updates connection configuration but doesn’t automatically transfer data. You’ll need to: 1. Export from current MongoDB (mongodump) 2. Import to new MongoDB (mongorestore) 3. Verify data integrity 4. Switch application over (Monk handles config) 5. Decommission old database

From One Managed Service to Another

Same process - Monk provisions new database, updates config, you migrate data manually.

Security Best Practices

Monk automatically applies these security practices across all deployment types:

All Deployments

  • Unique credentials - Each deployment gets unique database credentials
  • Network isolation - Database not exposed to public internet
  • Encrypted connections - TLS enabled for data in transit
  • Least privilege - Application users have minimal required permissions

Managed Deployments (Atlas, DO)

  • Automatic IP whitelisting - Monk adds your application’s IP automatically
  • Firewall rules - Provider-managed network security
  • Security patches - Automatic updates managed by provider
  • Encryption at rest - Data encrypted on disk (provider-managed)

MongoDB Atlas Specific

  • Project-level isolation - Each deployment in separate Atlas project
  • Role-based users - Database users created with specific roles (readWrite, not admin)
  • Audit logging - Available on M10+ clusters
  • Network peering - Available for private connectivity (M10+)
  • Customer-managed keys - Encryption key management (M10+)

Verify Security Configuration

Ask Monk to check your MongoDB security:
Monk verifies firewall rules, access controls, and encryption settings.

Troubleshooting

Connection Issues

Monk verifies:
  • Credentials are correct
  • Network connectivity from application
  • Database is running and accepting connections
  • Firewall/IP whitelist configuration

Performance Issues

Monk checks:
  • Slow queries and indexes
  • Connection pool saturation
  • Resource usage (CPU, memory, disk)
  • Network latency

Version Compatibility

Monk analyzes your code and MongoDB driver version to verify compatibility.

Cost Optimization

Check MongoDB Costs

Optimize Spending

Monk analyzes your usage patterns and suggests appropriate sizing.