Deploy a Standalone MongoDB Instance


At any place on this page that says Ops Manager, you can substitute Cloud Manager.


  • You can use the Kubernetes Operator to deploy MongoDB resources with Ops Manager version 4.0.11 or later and Cloud Manager.
  • You can’t use the Kubernetes Operator to deploy MongoDB resources to Atlas.

You can deploy a standalone MongoDB instance for Ops Manager to manage. Use standalone instances for testing and development. Do not use these deployments for production systems as they lack replication and high availability. For all production deployments use replica sets. To learn about replica sets, see Deploy a Replica Set.


To deploy a standalone using an object, you need to complete the following procedures:

Alternatively, for MongoDB Cloud Manager, after installing the Kubernetes Operator, you can use the Cloud Manager UI to automatically generate the ConfigMap and Kubernetes secret YAML files, which you can then apply to your Kubernetes environment.


Starting in Kubernetes Operator version 1.11.0, you must migrate all deployed MongoDBOpsManager custom resources to a specified MongoDB version.



Configure kubectl to default to your namespace.

If you have not already, run the following command to execute all kubectl commands in the namespace you created:

kubectl config set-context $(kubectl config current-context) --namespace=<namespace>

Copy the following example standalone Kubernetes object.

This is a YAML file that you can modify to meet your desired configuration. Change the highlighted settings to match your desired standalone configuration.

kind: MongoDB
  name: <my-standalone>
  version: "4.2.2-ent"
      name: <>
            # Must match in ConfigMap file
  credentials: <mycredentials>
  type: Standalone
  persistent: true

Open your preferred text editor and paste the object specification into a new text file.


Configure the settings highlighted in the preceeding step as follows.

Key Type Description Example string

Label for this Kubernetes standalone object.

Resource names must be 44 characters or less.

See also

spec.version string

Version of MongoDB that is installed on this standalone.

The format should be X.Y.Z for the Community edition and X.Y.Z-ent for the Enterprise edition.


Ensure that you choose a compatible MongoDB Server version.

Compatible versions differ depending on the base image that the MongoDB database resource uses.

To learn more about MongoDB versioning, see MongoDB Versioning in the MongoDB Manual.

For best results, use the latest available enterprise MongoDB version that is compatible with your Ops Manager version.

Name of the ConfigMap with the Ops Manager connection configuration. The setting is an alias for this setting and can be used in its place.


This value must exist on the same namespace as the resource you want to create.

spec.credentials string

Name of the Kubernetes secret you created as Ops Manager API authentication credentials for the Kubernetes Operator to communicate with Ops Manager.

The Ops Manager Kubernetes Secret object holding the Credentials must exist on the same Namespace as the resource you want to create.

Operator manages changes to the Secret

The Kubernetes Operator tracks any changes to the Secret and reconciles the state of the MongoDB Kubernetes resource.

spec.type string Type of MongoDB Kubernetes resource to create. Standalone
spec.persistent string


If this value is true, then spec.podSpec.persistence.single is set to its default value of 16Gi.

To change your Persistent Volume Claims configuration, configure the following collections to meet your deployment requirements:


Your containers must have permissions to write to your Persistent Volume. The Kubernetes Operator sets fsGroup = 2000 in securityContext This makes Kubernetes try to fix write permissions for the Persistent Volume. If redeploying the deployment item does not fix issues with your Persistent Volumes, contact MongoDB Support.


If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment.


Save this file with a .yaml file extension.


Start your Standalone deployment.

Invoke the following Kubernetes command to create your standalone:

kubectl apply -f <standalone-conf>.yaml

Track the status of your standalone deployment.

To check the status of your MongoDB Kubernetes resource, invoke the following command:

kubectl get mdb <resource-name> -o yaml -w

The -w flag means “watch”. With the “watch” flag set, the output refreshes immediately when the configuration changes until the status phase achieves the Running state.

See Troubleshoot the Kubernetes Operator for information about the resource deployment statuses.

To troubleshoot your sharded cluster, see: