MongoDB hosting is a deployment model for running a MongoDB database on infrastructure your team operates or on a managed database service that operates more of the platform for you.
The database engine can be the same, but the operating responsibility is not. Self-hosted MongoDB gives your team control over the operating system, MongoDB configuration, replica-set topology, backups, upgrades, and recovery. Managed MongoDB shifts more of that platform work to the provider.
Raff Technologies supports more than 3,000 customers and 15,000 deployed VMs across cloud workloads. In our work with small teams, the main MongoDB hosting mistake is treating a single running mongod process as a production architecture. Production planning starts with recovery, replica-set design, security, monitoring, and the question of who owns database incidents.
This guide compares managed and self-hosted MongoDB hosting, explains when a VPS or VM makes sense, and shows how to plan production capacity. For the broader operating-model decision, see Managed Database vs Self-Hosted.
MongoDB hosting has two operating models
MongoDB can be hosted as a self-managed database on a VM or consumed as a managed service.
The important difference is the responsibility boundary.
| Responsibility | Self-hosted MongoDB | Managed MongoDB |
|---|---|---|
| VM or host operating system | Your team | Provider |
| MongoDB installation | Your team | Provider |
| Minor patching | Your team | Usually provider-managed |
| Replica-set deployment | Your team | Usually provider-managed |
| Backup platform | Your team | Included according to service scope |
| Restore workflow | Your team | Provider tooling plus customer validation |
| Monitoring platform | Your team | Usually included to a defined scope |
| Network controls | Your team | Shared responsibility |
| Schema and document design | Your team | Your team |
| Indexes and query behavior | Your team | Your team |
| Application credentials | Your team | Your team |
| Capacity planning | Your team | Your team |
A managed platform reduces database-platform work. It does not own document design, index choices, application queries, credential hygiene, or recovery validation.
Self-hosting provides deeper control, but every control becomes an operational task your team must perform repeatedly.
The decision framework starts with operational ownership
Choose the hosting model from the work your team can sustain after deployment.
| Decision signal | Self-hosted MongoDB usually fits | Managed MongoDB usually fits |
|---|---|---|
| Root or OS access is required | Yes | Usually no |
| Custom packages or host agents are required | Yes | Usually restricted |
| Custom replica-set topology is required | Strong fit | Depends on service limits |
| Team already runs database automation and on-call | Strong fit | Still useful, but less necessary |
| Team wants provider-operated backups and maintenance | More work | Strong fit |
| Standard MongoDB capabilities are sufficient | Possible | Strong fit |
| Exact patch timing is required | Strong fit | Depends on provider policy |
| Fast evaluation with minimal platform work matters | More setup | Strong fit |
| Managed product is unavailable in the required platform or region | Self-host | Not an option |
Choose self-hosted MongoDB when a documented requirement needs operating-system access, custom database topology, exact maintenance control, or an environment the managed provider does not offer.
Choose managed MongoDB when standard service capabilities fit and the team wants to spend less time on database hosts, backup infrastructure, patching, monitoring, and failover operations.
The decision rationale we use at Raff is simple: do not self-host MongoDB only because the first server is easy to create. Self-host when control is worth owning the complete lifecycle.
Self-hosted MongoDB fits control-heavy workloads
A VM is a practical MongoDB hosting model when the team needs direct control over the host and database service.
Common reasons include:
- custom operating-system packages;
- exact MongoDB version and upgrade timing;
- direct access to MongoDB configuration and logs;
- custom TLS or authentication integration;
- specific replica-set placement;
- custom monitoring agents;
- backup tooling controlled by the team;
- integration with private infrastructure;
- workloads that need a database version or topology outside a managed catalog.
A self-hosted production design should be treated as more than one server.
MongoDB's production documentation recommends replica sets for production deployments, and its replica-set deployment guidance says production members should run on separate machines. A replica set provides redundancy and automatic election behavior, but it also creates additional systems to monitor and recover.
A basic production pattern may look like:
Application -> private network MongoDB replica set -> node-1 -> node-2 -> node-3 Backup target -> separate failure domain
That does not mean every small development environment needs three VMs. A single node can be useful for development, testing, and early application work. The distinction is that a single node should not be confused with a highly available production design.
For installation, use How to Install MongoDB on Ubuntu 24.04, which keeps MongoDB off the public network and enables authentication.
Managed MongoDB fits teams that want less database-platform work
Managed MongoDB is useful when the product needs MongoDB but the team does not want to build and operate the supporting database platform.
A managed service can reduce work around:
- provisioning database nodes;
- replica-set deployment;
- host patching;
- routine maintenance;
- backup scheduling;
- restore tooling;
- metrics and alerting;
- storage expansion;
- failover operations;
- controlled upgrade workflows.
The application team still owns the workload.
That includes:
- document structure;
- embedding versus references;
- indexes;
- aggregation pipelines;
- query latency;
- transaction boundaries;
- credentials;
- data retention;
- application behavior during failover;
- validating restored data.
Managed MongoDB therefore solves an operating problem, not a data-model problem. If the application is actually relationship-heavy, moving it to a managed MongoDB service does not make the document model a better fit.
Before choosing MongoDB at all, compare MongoDB vs PostgreSQL or MongoDB vs MySQL if relational engines are still under consideration.
Production MongoDB requires recovery, security, and replica planning
Hosting becomes production-ready only when failure has an answer.
Replica sets improve availability but are not backups
Replica sets copy data between members and provide redundancy. They can also copy accidental deletes, destructive updates, and application mistakes.
Use replication for availability. Use backups for historical recovery.
MongoDB documents separate backup methods for self-managed deployments, including database tools and storage-level approaches. The correct method depends on topology, data size, recovery objectives, and whether the deployment is a standalone server, replica set, or sharded cluster.
Define:
- Recovery Point Objective (RPO);
- Recovery Time Objective (RTO);
- backup frequency;
- backup retention;
- backup storage location;
- restore procedure;
- restore-test schedule;
- recovery owner.
A backup that has never been restored is not sufficient evidence of recoverability.
MongoDB should not be broadly exposed to the public internet
MongoDB's security guidance emphasizes authentication, authorization, network restrictions, TLS, and secure configuration for self-managed deployments.
For self-hosted MongoDB:
- enable access control;
- use separate administrative and application users;
- apply least privilege;
- restrict port
27017to trusted network paths; - prefer private networking between the application and database;
- use TLS where traffic crosses networks that require encryption;
- rotate credentials and remove unused users;
- monitor authentication and database errors.
The installation tutorial in this cluster binds MongoDB to 127.0.0.1 for a same-VM application and explicitly blocks public port access.
MongoDB sizing starts with working set and storage growth
There is no universal MongoDB VM size that fits every application.
Sizing should start from the workload:
| Signal | Why it matters |
|---|---|
| Active working set | Determines how much frequently accessed data and indexes compete for memory |
| Index size | Large indexes increase memory and storage pressure |
| Document size | Influences storage, network transfer, and read/write behavior |
| Read/write ratio | Changes CPU, storage, and replica pressure |
| Connection count | Affects memory and application concurrency |
| Aggregation complexity | Can increase CPU and temporary working requirements |
| Storage growth | Determines resize and backup planning |
| Backup duration | Affects recovery design and operational windows |
| Replica count | Multiplies infrastructure and storage requirements |
A development MongoDB VM can start small because availability and large working sets may not matter yet. Production should be sized from observed memory use, storage growth, query latency, connection behavior, and recovery requirements.
On Raff, VM traffic runs on 3 Gbps unmetered bandwidth, so database planning should focus on the actual MongoDB workload rather than a per-GB VM egress budget. That does not remove the need to design private connectivity, storage capacity, and backup transfer carefully.
Do not solve every performance problem by resizing the VM. Missing indexes, unbounded document growth, expensive aggregation pipelines, poor schema boundaries, and application retry loops can waste larger infrastructure just as effectively as smaller infrastructure.
Raff supports self-hosted MongoDB today
Raff's current production path for MongoDB hosting is a self-hosted Raff VM.
A Raff VM provides root access, NVMe-backed storage, private networking options, firewall controls, snapshots, automated backups, resize support, and 3 Gbps unmetered VM bandwidth. Your team installs and operates MongoDB and remains responsible for database-aware backups, replica-set design, monitoring, patching, recovery, and security configuration.
A typical small-team architecture can separate the application and database over Raff VPC:
Public traffic -> application VM -> private VPC -> MongoDB VM or replica set
This keeps MongoDB off the public application path while preserving full operating-system control.
Raff's public Managed Databases page currently lists MongoDB 7.0 and 8.0 as rolling out. It should therefore not be treated as a deployable production dependency until the live Raff console confirms availability for the account.
That creates a clear current decision:
Need MongoDB on Raff today -> self-host on Raff VM Need managed MongoDB specifically -> verify live product availability first -> if unavailable, use the self-hosted VM path or another currently available managed provider
This product state may change, so the live console should remain the source of truth for managed MongoDB availability.
Conclusion: choose MongoDB hosting from the responsibility boundary
MongoDB hosting is not only a question of where the database runs. It determines who owns patching, backups, replica sets, monitoring, scaling, security, and recovery when something fails.
Choose self-hosted MongoDB when the workload needs host-level control or custom topology and your team can operate the database lifecycle. Choose managed MongoDB when standard service capabilities fit and reducing database-platform work is more valuable than unrestricted control.
On Raff today, the live MongoDB path is self-hosting on a Raff VM, while managed MongoDB is still rolling out. Start with a secure VM deployment, keep database traffic private, and design recovery before treating the workload as production-ready.