You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A flexible NoSQL database for scalable, real-time data management.
Description
This Helm chart provides a complete MongoDB StatefulSet deployment solution with persistent storage, authentication, health checks, and security configurations. It uses the official mongo Docker image and supports various deployment scenarios from development to production environments.
Features
Official MongoDB Image: Uses the official mongo Docker image from Docker Hub
Authentication: Configurable MongoDB authentication with root user credentials
Custom User: Optional custom user creation at initialisation with configurable credentials and database — works in both standalone and sharded cluster modes
Persistent Storage: Automatic persistent volume management through StatefulSet volumeClaimTemplates
Security: Non-root container execution with proper security contexts
Health Checks: Liveness and readiness probes using mongosh
Flexible Configuration: Comprehensive configuration options for various deployment needs
Service Account: RBAC-ready with configurable service account
Resource Management: Configurable CPU and memory limits/requests
Sharded Cluster: Full sharded cluster support with config servers, mongos routers, and shard servers including automated initialisation, replica set setup, balancer configuration, and auto-sharding
Installing the Chart
To install the chart with the release name my-mongodb:
This Helm chart is cryptographically signed with Cosign to ensure authenticity and prevent tampering.
Public Key:
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE5U+rM2d3hDjgP5T3cLShuuQIU9vR
Z4/G+Nug6q5vRa+C3qUA1wXjbaJFAfcIrv5VjmYAYOj13shnPpp3Zh4fnQ==
-----END PUBLIC KEY-----
To verify the helm chart before installation, copy the public key to the file cosign.pub and run cosign:
Name of an existing Configmap to use instead of creating one
""
config.existingConfigmapKey
Name of the key in the Configmap that should be used
""
Custom User Configuration
Multiple users can be created at initialisation time via the customUsers array. Each user gets the specified roles on their database. This works in standalone, replica set, and sharded cluster modes (in sharded mode users are created via the mongos router after cluster initialisation).
Each entry supports either inline credentials (name + optional password/database) or an existing Kubernetes secret (existingSecret).
Parameter
Description
Default
customUsers[].name
Username. A secret named <release>-custom-user-<i>-secret is auto-generated when no existingSecret
""
customUsers[].database
Database to create the user in. Defaults to name if not set
""
customUsers[].password
Password. A random 32-char password is generated if not set
""
customUsers[].existingSecret
Name of an existing secret. Supports Helm template strings
""
customUsers[].secretKeys.name
Key in existingSecret holding the username
CUSTOM_USER
customUsers[].secretKeys.password
Key in existingSecret holding the password
CUSTOM_PASSWORD
customUsers[].secretKeys.database
Key in existingSecret holding the database name
CUSTOM_DB
customUsers[].roles
MongoDB roles to grant. Plain strings apply to the user's own database; use {role, db} for cross-database roles
Set persistentVolumeClaimRetentionPolicy to explicitly control how PVCs are managed when a stateful set is scaled or deleted. (new feature in k8s 1.32)
Set persistentVolumeClaimRetentionPolicy to explicitly control how PVCs are managed when a stateful set is scaled or deleted. (new feature in k8s 1.32)
replicaSet.arbiter.storage.volumeName
Internal volume name and prefix of a created PVC
"mongodb-arbiter-volume"
replicaSet.arbiter.storage.requestedSize
Alternative set requestedSize to define a size for a dynamically created PVC
replicaSet.arbiter.storage.className
The storage class name
replicaSet.arbiter.storage.accessModes
Default access mode (ReadWriteOnce)
ReadWriteOnce
replicaSet.arbiter.storage.annotations
Additional storage annotations
{}
replicaSet.arbiter.storage.labels
Additional storage labels
{}
replicaSet.arbiter.extraArgs
Additional arguments for the arbiter container
[]
Replica Set Extra Init Parameters
Parameter
Description
Default
replicaSet.extraInit.retries
Number of retries to detect whether mongod is fully up and running in background
10
replicaSet.extraInit.delay
Seconds to wait between retries
3
replicaSet.extraInit.initDelay
Seconds to wait after mongod is running to give it time for internal initialization
5
Replica Set Shutdown Parameters
Parameter
Description
Default
replicaSet.shutdown.delay
Delay until termination request is forwarded to mongod process to give ReplicaSet time for electing a new primary instance
10
Sharded Cluster Parameters
For MongoDB sharded cluster deployments, enable shardedCluster.enabled instead of replicaSet.enabled. Sharded clusters consist of config servers, mongos routers, and shard servers. Cluster initialisation (replica set setup, shard registration, balancer configuration, and custom user creation) is handled automatically by a post-install Job.
General
Parameter
Description
Default
shardedCluster.enabled
Enable sharded cluster deployment (mutually exclusive with replicaSet.enabled)
false
shardedCluster.keyFile
Plain-text keyfile string (6-1024 chars) for internal cluster authentication
""
shardedCluster.keySecretName
Name of an existing secret with a file named keyfile containing the keyfile string
""
shardedCluster.shards
Number of shards (minimum 2)
2
Config Servers
Parameter
Description
Default
shardedCluster.configsvr.replicaCount
Number of config server replicas (minimum 1, recommended 3 for production)
3
shardedCluster.configsvr.enableConfigShard
Enable config shard mode (MongoDB 8.0+): config servers also store user data via transitionFromDedicatedConfigServer
false
shardedCluster.configsvr.priorityClassName
Priority class name for config server pods
""
shardedCluster.configsvr.resources
Resource limits and requests for config server pods
Node selector for shard data node pods (overrides shardsvr.nodeSelector)
{}
shardedCluster.shardsvr.dataNode.tolerations
Tolerations for shard data node pods (overrides shardsvr.tolerations)
[]
shardedCluster.shardsvr.dataNode.affinity
Affinity rules for shard data node pods (overrides shardsvr.affinity)
{}
Shard Arbiters
WARNING: MongoDB does NOT recommend using arbiters (shardedCluster.shardsvr.arbiter.replicaCount > 0) in sharded cluster deployments. Arbiters do not hold data and can lead to consistency issues in sharded environments. Use data-bearing replica set members for high availability instead.
See: Replica Set Arbiter - Sharded Cluster Considerations
Parameter
Description
Default
shardedCluster.shardsvr.arbiter.replicaCount
Number of arbiter replicas per shard (0 to disable, recommended 0)
Start time of the balancer window (format: HH:MM, empty = always)
""
shardedCluster.balancer.window.stop
Stop time of the balancer window (format: HH:MM, empty = always)
""
shardedCluster.balancer.autoSplitEnabled
Enable automatic chunk splitting (MongoDB 6.0+)
true
Extra Objects
You can use the extraObjects array to deploy additional Kubernetes resources (such as NetworkPolicies, ConfigMaps, etc.) alongside the release. This is useful for customizing your deployment with extra manifests that are not covered by the default chart options.
Helm templating is supported in any field, but all template expressions must be quoted. For example, to use the release namespace, write namespace: "{{ .Release.Namespace }}".
All objects in extraObjects will be rendered and deployed with the release. You can use any valid Kubernetes manifest, and reference Helm values or built-in objects as needed (just remember to quote template expressions).