MongoDB 7

Open Marketplace in the Azure Portal, search for MongoDB 7, and select the SecureAnyCloud publisher entry. Select Create to start the wizard.

On the Basics tab, choose your subscription, target resource group and region. The region must match the region that your Azure Compute Gallery exposes the image in. Set the virtual machine name. Choose SSH public key as the authentication type, enter a username of your choice, and paste your SSH public key.

Standard_D4s_v3 is the recommended starting size. MongoDB benefits substantially from memory for the WiredTiger cache. By default the storage engine sizes the cache at fifty percent of RAM above one gigabyte, so a sixteen-gigabyte D4s_v3 profile leaves roughly seven gigabytes for the cache. That leaves enough headroom for the rest of the process and the OS.

Scale up to Standard_D8s_v3 or Standard_E8s_v3 for write-heavy workloads, large working sets, or collections whose hot indexes exceed the default cache sizing.

On the Disks tab, the recommended OS disk type is Standard SSD. The MongoDB data directory lives at /var/lib/mongodb. If you expect to ingest more than a few gigabytes per day, or to keep more than forty gigabytes of documents plus indexes on disk, attach a separate Premium SSD data disk now. Plan to relocate the data directory before you ingest production traffic. MongoDB's IO profile is heavy on random access under normal write workloads, so premium-tier disks have a tangible effect on tail latency.

On the Networking tab, select your existing virtual network and subnet. Attach a network security group that allows inbound TCP 22 from your management IP range. Allow inbound TCP 27017 only from the virtual network CIDR or from the specific application server subnets that need to reach the database.

Do not expose 27017 to the public internet. SCRAM-SHA-256 is strong authentication, but an exposed database is a permanent target for compromise. There is no operational reason to open the listener publicly, because driver traffic flows privately from your application tier.

On the Management, Monitoring and Advanced tabs, the defaults are appropriate. Select Review + create, wait for validation to pass, then select Create. Deployment takes around two minutes.

If you prefer the command line, accept the Marketplace terms once, then deploy from the Marketplace image URN. The script creates the resource group, virtual network, NSG and VM:

RG="mongodb-prod" LOCATION="eastus" VM_NAME="mongodb-01" ADMIN_USER="dbadmin" IMAGE_URN="sac1647283583153:mongodb-7-ubuntu-22-04:standard:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create \
  --resource-group "$RG" \
  --name mongodb-vnet \
  --address-prefix 10.60.0.0/16 \
  --subnet-name mongodb-subnet \
  --subnet-prefix 10.60.1.0/24 az network nsg create --resource-group "$RG" --name mongodb-nsg az network nsg rule create \
  --resource-group "$RG" --nsg-name mongodb-nsg \
  --name allow-ssh-mgmt --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" \
  --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create \
  --resource-group "$RG" --nsg-name mongodb-nsg \
  --name allow-mongodb-vnet --priority 110 \
  --source-address-prefixes 10.60.0.0/16 \
  --destination-port-ranges 27017 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:mongodb-7-ubuntu-22-04:standard:latest
az vm create \
  --resource-group "$RG" \
  --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_D4s_v3 \
  --storage-sku StandardSSD_LRS \
  --admin-username "$ADMIN_USER" \
  --ssh-key-values "$SSH_KEY" \
  --vnet-name mongodb-vnet --subnet mongodb-subnet \
  --nsg mongodb-nsg \
  --public-ip-address "" \
  --os-disk-size-gb 32

The --public-ip-address "" flag keeps the server off the public internet. To reach it, use a bastion host or your existing private connectivity.

After deployment, find the private IP of the new virtual machine. From a host inside the same virtual network, connect over SSH:

ssh dbadmin@<vm-ip>

The first login can take a few seconds while cloud-init finalises. Once you have a shell, systemd has already started mongod, and the first-boot oneshot has already generated the per-VM SCRAM credentials.

The mongod-firstboot.service systemd oneshot writes two users the first time the virtual machine boots. The credentials live in a single file that only root can read. Print it with sudo:

sudo cat /stage/scripts/mongodb-credentials.log

The file contains, at a minimum, these fields:

root.user=marketplaceAdmin root.password=<generated> root.authSource=admin app.user=marketplace app.password=<generated> app.database=appdb app.authSource=appdb host=<private-ip> port=27017 mechanism=SCRAM-SHA-256

For scripted use, extract a specific field with awk:

sudo awk -F= '/^root\.password=/ {print $2}' /stage/scripts/mongodb-credentials.log

Copy both passwords somewhere safe. The credentials file is not backed up anywhere else. If you lose it, Step 11 covers password rotation through the running server. If the file is gone and neither user can authenticate, the fastest recovery is to redeploy from the same image and migrate your data.

mongosh is already installed on the image. Confirm that the server is live:

sudo systemctl status mongod.service --no-pager | head -20

Confirm that it is listening on port 27017:

ss -ltn | grep ':27017 '

Confirm that the installed version is MongoDB 7.0:

mongod --version | head -2

Connect with mongosh as the admin user and list the databases. The one-liner below reads the password from the credentials file at runtime, so the password never appears in your shell history:

ROOT_PW=$(sudo awk -F= '/^root\.password=/ {print $2}' /stage/scripts/mongodb-credentials.log) mongosh --quiet --host 127.0.0.1 --port 27017 \
  -u marketplaceAdmin -p "$ROOT_PW" --authenticationDatabase admin \
  --eval 'db.adminCommand({listDatabases:1}).databases.forEach(d => print(d.name))'

A minimal deployment prints admin, config and local. Next, confirm that authentication is enforced. An unauthenticated connection must fail:

mongosh --quiet --host 127.0.0.1 --port 27017 \
  --eval 'db.adminCommand({listDatabases:1}).databases.length' 2>&1 | grep -E "Unauthorized|requires authentication" | head -1

A line containing requires authentication (or Unauthorized) confirms that security.authorization: enabled from /etc/mongod.conf is in effect.

This minimal end-to-end exercise authenticates as the application user. It inserts three documents and queries them:

APP_PW=$(sudo awk -F= '/^app\.password=/ {print $2}' /stage/scripts/mongodb-credentials.log) mongosh --quiet --host 127.0.0.1 --port 27017 \
  -u marketplace -p "$APP_PW" --authenticationDatabase appdb appdb <<'EOS' db.devices.insertMany([ { serial: "A001", model: "sensor-pro", firmware: "1.4.0", registeredAt: new Date() }, { serial: "A002", model: "sensor-pro", firmware: "1.4.1", registeredAt: new Date() }, { serial: "A003", model: "sensor-lite", firmware: "1.1.0", registeredAt: new Date() } ]); print("inserted:", db.devices.countDocuments({})); print("--- firmware 1.4.x ---"); db.devices.find({ firmware: { $regex: /^1\.4\./ } }).forEach(d => printjson(d)); EOS

MongoDB creates the database and the collection on the first write. Re-running the block on a clean collection is the fastest sanity test after any server change.

Without indexes, any predicate on a collection scans every document. Every production collection should have indexes that support its hot query shapes.

MongoDB 7.0 introduces compound wildcard indexes, which are valuable for applications whose schemas have many optional or unpredictable field names. For the devices collection above, run:

APP_PW=$(sudo awk -F= '/^app\.password=/ {print $2}' /stage/scripts/mongodb-credentials.log) mongosh --quiet --host 127.0.0.1 --port 27017 \
  -u marketplace -p "$APP_PW" --authenticationDatabase appdb appdb <<'EOS' db.devices.createIndex({ serial: 1 }, { unique: true }); db.devices.createIndex({ model: 1, firmware: 1 }); print("--- indexes ---"); db.devices.getIndexes().forEach(i => printjson(i)); print("--- explain for model+firmware filter ---"); var plan = db.devices.find({ model: "sensor-pro", firmware: "1.4.1" }).explain("queryPlanner"); print("winning stage:", plan.queryPlanner.winningPlan.inputStage ? plan.queryPlanner.winningPlan.inputStage.stage : plan.queryPlanner.winningPlan.stage); EOS

winningPlan.inputStage.stage of IXSCAN confirms that the new compound index is used rather than a full COLLSCAN.

Unique indexes enforce uniqueness on write, so the server rejects any later insert with a duplicate serial. This is a common way to protect the natural key of a tenant or device registry.

mongodump and mongorestore ship with the image as part of the mongodb-database-tools package. They produce a BSON archive that is portable across MongoDB versions within the 6.x to 7.x band. This is the recommended backup mechanism for single-node deployments. For larger clusters, consider MongoDB Ops Manager or Cloud Manager for incremental block-level snapshots.

To take a full dump of the appdb database, authenticate as the admin user:

ROOT_PW=$(sudo awk -F= '/^root\.password=/ {print $2}' /stage/scripts/mongodb-credentials.log)
sudo mkdir -p /var/backups/mongodb
sudo chown $(id -u):$(id -g) /var/backups/mongodb mongodump --host 127.0.0.1 --port 27017 \
  -u marketplaceAdmin -p "$ROOT_PW" --authenticationDatabase admin \
  --db appdb --out /var/backups/mongodb/$(date -u +%Y%m%dT%H%M%S)
ls -la /var/backups/mongodb/

The dump creates a directory named with today's UTC timestamp. It contains appdb/ with BSON and metadata files for each collection.

Restoration reverses the flow. See https://www.mongodb.com/docs/database-tools/mongorestore/ for the full flag reference, including --drop for destructive restores and --nsInclude for selective restores.

In production, schedule mongodump under cron or a systemd timer. Push the archive directory to Azure Blob Storage or another durable location, and retain it according to your recovery point objective.

A single-node MongoDB server has no automatic failover. For high availability in production, run a replica set of at least three mongod members spread across availability zones. A replica set elects a primary and replicates writes to secondaries. If the primary fails, a secondary is promoted automatically and drivers reconnect transparently.

The image is configured for standalone operation, so replication.replSetName is not set in /etc/mongod.conf. To extend it to a replica set, follow these steps:

• Deploy two additional virtual machines from the same gallery image.
• Set a shared replication.replSetName in /etc/mongod.conf on all three.
• Configure net.bindIp to include the internal hostnames.
• Restart each mongod.
• Run rs.initiate() once from mongosh on the intended primary.

The full procedure, including keyfile-based inter-node authentication, is documented at https://www.mongodb.com/docs/manual/tutorial/deploy-replica-set/.

Plan node placement before provisioning. Inter-node latency drives replication lag and election time, so the same region with different availability zones is the right posture for most deployments.

Replica sets are also a prerequisite for MongoDB's change streams feature, which received significant improvements in MongoDB 7.0, including support for pre-images and post-images on change events. If you expect to publish MongoDB writes to a downstream system such as Kafka or an internal event bus, plan the replica set before you wire up the integration, not after.

MongoDB 7.0 supports TLS termination natively at the mongod listener. Enable it in three steps.

First, obtain or create a server certificate. For production, use a certificate from your internal certificate authority, or an ACME-issued certificate with a SAN for the private DNS name. Second, concatenate the certificate and key into a PEM bundle that mongod can read. Third, update /etc/mongod.conf with the following block:

net: port: 27017 bindIp: 0.0.0.0 tls: mode: requireTLS certificateKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/internal-ca.pem

requireTLS rejects any plain wire protocol connection, so drivers must connect with tls=true.

Restart the service with sudo systemctl restart mongod. Then verify that connections require TLS with mongosh --tls --tlsCAFile /etc/ssl/internal-ca.pem --host <private-dns-name>.

For a deeper treatment of MongoDB TLS options, including preferTLS (soft migration mode), client certificate authentication and cipher suite restrictions, see https://www.mongodb.com/docs/manual/tutorial/configure-ssl/.

Before you put a real workload through the server, tighten the security posture in the following ways.

Rotate the generated passwords. The bootstrap passwords are strong random SCRAM credentials, but your organisation's policy may require scheduled rotation. To rotate marketplaceAdmin, connect with mongosh and run:

ROOT_PW=$(sudo awk -F= '/^root\.password=/ {print $2}' /stage/scripts/mongodb-credentials.log)
NEW_ROOT_PW=$(openssl rand -base64 48 | tr -d '=+/' | cut -c1-32) mongosh --quiet --host 127.0.0.1 --port 27017 \
  -u marketplaceAdmin -p "$ROOT_PW" --authenticationDatabase admin \
  admin --eval "db.changeUserPassword('marketplaceAdmin', '$NEW_ROOT_PW')" echo "new root password: $NEW_ROOT_PW"
sudo sed -i "s|^root\.password=.*|root.password=$NEW_ROOT_PW|" /stage/scripts/mongodb-credentials.log

Re-authenticate with the new password to confirm that the change took effect. Then clear your shell history or the NEW_ROOT_PW variable. Rotate the application user the same way. Update app.password= in the credentials file, and redeploy any applications that cached the old value.

Restrict 27017 at the network edge. The network security group rule in Step 2 limits inbound 27017 to the virtual network CIDR. Tighten it further to specific application subnet CIDRs, or to an Azure Private Link endpoint, so unrelated subnets on the same VNet cannot reach the listener. The database should be a deliberate backend hop, never a default one.

Limit the admin user's scope. The marketplaceAdmin user holds the root role on the admin database, which is the full cluster privilege set. For day-to-day application operations, use the marketplace application user, which holds only readWrite and dbAdmin on appdb. As your application footprint grows, create additional application users scoped to their own databases. Reserve the marketplaceAdmin credential for administrative work.

Turn on audit logging. MongoDB 7.0 Community does not include the Enterprise audit subsystem. However, the standard mongod log at /var/log/mongodb/mongod.log records authentication attempts, schema changes and slow operations. Ship the log to Azure Monitor or your existing SIEM with the Azure Monitor agent, so failed login attempts and privileged operations are visible outside the VM.

Plan for upgrades. MongoDB 7.0 patch-level updates (7.0.1, 7.0.2 and so on) arrive through the mongodb-org apt repository that is already configured on the image. Run sudo apt-get update && sudo apt-get upgrade mongodb-org monthly, and restart the service in a maintenance window. Major version upgrades (7.0 to 8.0) require following the MongoDB upgrade procedure, including the compatibility setting changes documented at https://www.mongodb.com/docs/manual/release-notes/.

Drop the application user if you do not use it. If your workload does not use the seeded marketplace user, for example because you create per-tenant or per-service users programmatically, drop it to reduce the attack surface:

ROOT_PW=$(sudo awk -F= '/^root\.password=/ {print $2}' /stage/scripts/mongodb-credentials.log) mongosh --quiet --host 127.0.0.1 --port 27017 \
  -u marketplaceAdmin -p "$ROOT_PW" --authenticationDatabase admin \
  appdb --eval 'db.dropUser("marketplace")'

Then remove the app.* lines from the credentials file to match the running server.

Driver integration. Every mainstream language has a native MongoDB driver that supports the 7.0 wire protocol. Examples include Node.js (mongodb on npm), Python (pymongo), Go (go.mongodb.org/mongo-driver), Java (mongodb-driver-sync), C# (MongoDB.Driver) and Rust (mongodb on crates.io). Each reads a standard mongodb://user:pw@host:27017/db?authSource=db connection string and supports TLS, replica set connection strings and retryable writes.

Observability. MongoDB emits Prometheus-compatible metrics through the community mongodb_exporter. Scrape it from your existing Prometheus stack or from Azure Monitor managed Prometheus. Alert on replication lag (once the replica set from Step 9 is in place), connection count, oplog window, slow query count and disk use.

MongoDB Compass. Compass is the official GUI client. Install it on a jump host or your workstation and connect with the same mongodb:// URI. It is particularly useful for ad hoc aggregation pipeline authoring and for visualising schemas inferred from a sample of documents.

Extended reading. The official MongoDB 7.0 release notes at https://www.mongodb.com/docs/manual/release-notes/7.0/ cover every query optimizer change, every new server parameter and every removed feature. Read the upgrade notes before you roll out any MongoDB 7.0 code to production that previously ran against 6.0 or earlier.

This guide covers the first mile of a MongoDB 7.0 deployment on Azure with the SecureAnyCloud image. For ongoing operations, see the official MongoDB manual at https://www.mongodb.com/docs/manual/. For image-specific questions, use the SecureAnyCloud support portal.

Deploy on Azure

Launch MongoDB 7 Community on Ubuntu 22.04 on Azure with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com