How to Install MongoDB on Ubuntu 24.04

MongoDB is a document database that stores records as BSON documents and is commonly used for APIs, catalogs, content-heavy applications, event data, and workloads that benefit from flexible document structures. On Ubuntu 24.04, MongoDB Inc. provides official Community Edition packages through its own APT repository rather than Ubuntu's default repository.

As of September 5, 2026, MongoDB 8.3 is the current self-managed minor release in MongoDB's documentation. MongoDB 8.0 remains a major release line, but this tutorial now follows the current 8.3 Community repository for a new Ubuntu 24.04 installation. MongoDB explicitly separates normal patch upgrades from major/minor release upgrades, so an existing 8.0 deployment should use the documented 8.0 → 8.3 upgrade procedure instead of simply replacing its repository file. citeturn127307view0turn137205search0

Raff Technologies is the VM platform used by the original tutorial. The saved test note remains Ubuntu 24.04 LTS on Raff 2 vCPU / 4 GB RAM VM; installation and security guidance reviewed in July 2026. This revision re-verifies the package path, localhost authentication bootstrap, RBAC, network exposure, TLS, logical backup/restore, and upgrade guidance against current MongoDB documentation without claiming a new end-to-end machine test.

The default design keeps MongoDB on loopback, enables authorization before the first user is created, and uses MongoDB's localhost exception only for the initial administrator bootstrap. Port 27017 is never opened publicly.

Prerequisites:

• Ubuntu 24.04 with SSH and sudo access
• A 64-bit x86_64 system or a MongoDB-supported ARM64 platform
• A tested recovery path before database or firewall changes
• Enough disk for the live dataset plus backup growth
• An off-server destination for production backup copies

Step 1 — Verify Ubuntu 24.04, architecture, and conflicting packages

Confirm the operating system and architecture:

. /etc/os-release
printf '%s | codename=%s | arch=%s\n' \
  "$PRETTY_NAME" "$VERSION_CODENAME" "$(dpkg --print-architecture)"

MongoDB Community supports Ubuntu 24.04 on x86_64 and supported ARM64 platforms. citeturn137205search4

Refresh APT metadata and install repository prerequisites:

sudo apt update
sudo apt install -y gnupg curl ca-certificates ufw

Check for old or conflicting MongoDB packages before adding the official repository:

dpkg -l | grep -E '^ii[[:space:]]+(mongodb|mongodb-server|mongodb-server-core|mongodb-org)' || true

The official MongoDB package family is mongodb-org. MongoDB's troubleshooting documentation warns that Ubuntu-provided mongodb/mongodb-server* packages can conflict with the official packages. Do not remove an existing database package until its data, configuration, version, and recovery path are understood. citeturn160945search0

Verify: The host should report Ubuntu 24.04/Noble, use a supported architecture, and have no unexplained conflicting MongoDB package or existing data directory that could be overwritten.

Step 2 — Add the official MongoDB 8.3 Community APT repository

Import MongoDB's current release signing key:

curl -fsSL https://pgp.mongodb.com/server-8.0.asc | \
  sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg \
  --dearmor

Create the Ubuntu 24.04 Noble Community repository for MongoDB 8.3:

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.3 multiverse" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-8.3.list >/dev/null

Refresh APT and inspect the package source:

sudo apt update
apt-cache policy mongodb-org | sed -n '1,20p'

MongoDB's current Community troubleshooting documentation references the mongodb-org/8.3 repository path, while the current manual identifies 8.3 as the latest minor release. citeturn160945search0turn127307view0

Do not hard-code a patch version in deployment automation unless you intentionally pin it. Let apt-cache policy show the current candidate available from the 8.3 repository.

Verify: apt-cache policy mongodb-org should show a non-empty candidate from repo.mongodb.org under the Noble mongodb-org/8.3 path.

Step 3 — Install MongoDB Community Edition and verify package ownership

Install the official MongoDB Community metapackage:

sudo apt install -y mongodb-org

Verify the installed components:

mongod --version | sed -n '1,8p'
mongosh --version
mongodump --version | sed -n '1,5p'
mongorestore --version | sed -n '1,5p'

Confirm package origin:

apt-cache policy mongodb-org mongodb-org-server mongodb-mongosh mongodb-database-tools | \
  sed -n '1,40p'

MongoDB's package-manager guidance recommends using the package manager for maintenance because it installs dependencies, configuration, and service integration consistently. citeturn137205search11

Verify: mongod should report an 8.3-series server, mongosh and Database Tools should be installed, and package policy should point to MongoDB's official repository.

Step 4 — Start MongoDB and verify the local listener

Start MongoDB and enable it at boot:

sudo systemctl enable --now mongod

Verify service state:

systemctl is-active mongod
systemctl is-enabled mongod
sudo systemctl status mongod --no-pager

Before authorization is enabled, confirm the fresh server responds locally:

mongosh --quiet --eval 'db.runCommand({ ping: 1 })'

Inspect the network listener:

sudo ss -lntp | grep ':27017' || true
sudo grep -nE '^[[:space:]]*(port|bindIp):' /etc/mongod.conf

MongoDB binds to localhost by default. Keep the instance on loopback while bootstrapping authentication. citeturn453062search2

Verify: mongod should be active and enabled, local ping should return { ok: 1 }, and the service should not listen on a public interface.

Step 5 — Enable authorization while MongoDB is still local-only

Back up the configuration before editing it:

sudo cp -a /etc/mongod.conf \
  "/etc/mongod.conf.$(date -u +%Y%m%dT%H%M%SZ).backup"

Open the configuration:

sudo nano /etc/mongod.conf

Keep the local bind and enable authorization:

net:
  port: 27017
  bindIp: 127.0.0.1

security:
  authorization: enabled

MongoDB documents security.authorization: enabled as the setting that turns on role-based access control. citeturn741727search1

Restart MongoDB:

sudo systemctl restart mongod
systemctl is-active mongod

At this moment there are no users, so MongoDB's localhost exception allows a client connected over localhost to create the first user. That exception exists only while there are no users or roles. citeturn453062search0

Verify: MongoDB should restart successfully with authorization enabled, remain bound to 127.0.0.1, and still have no user accounts before the next step.

Step 6 — Create the first administrator through the localhost exception

Generate a strong administrator password and store it securely:

MONGO_ADMIN_PASSWORD="$(openssl rand -hex 32)"
printf 'Store this MongoDB admin password securely: %s\n' "$MONGO_ADMIN_PASSWORD"
export MONGO_ADMIN_PASSWORD

Use the localhost exception to create the first user in the admin database:

mongosh --quiet --host 127.0.0.1 --eval '
const adminDb = db.getSiblingDB("admin");
adminDb.createUser({
  user: "raffadmin",
  pwd: process.env.MONGO_ADMIN_PASSWORD,
  roles: [ { role: "root", db: "admin" } ]
});
printjson(adminDb.getUser("raffadmin"));
'

Creating the first user closes the localhost exception. MongoDB's documentation requires that this first user have enough privilege to create and manage subsequent users. citeturn453062search0turn453062search1

Remove the password from the shell variable after it has been stored:

unset MONGO_ADMIN_PASSWORD

Confirm unauthenticated administrative access is now rejected:

mongosh --quiet --host 127.0.0.1 \
  --eval 'db.getSiblingDB("admin").getUsers()'

Then authenticate as the administrator; --password without a value prompts securely:

mongosh --quiet \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --eval 'printjson(db.runCommand({ connectionStatus: 1 }).authInfo.authenticatedUsers)'

Verify: Unauthenticated user-management commands should fail, while raffadmin should authenticate successfully against the admin database.

Step 7 — Create a database-scoped application user

Generate a separate application password:

MONGO_APP_PASSWORD="$(openssl rand -hex 32)"
printf 'Store this MongoDB application password securely: %s\n' "$MONGO_APP_PASSWORD"
export MONGO_APP_PASSWORD

Create raffappuser in the application database with only readWrite on that database:

mongosh --quiet \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --eval '
const appDb = db.getSiblingDB("raffapp");
appDb.createUser({
  user: "raffappuser",
  pwd: process.env.MONGO_APP_PASSWORD,
  roles: [ { role: "readWrite", db: "raffapp" } ]
});
printjson(appDb.getUser("raffappuser"));
'

Remove the password from the environment after storing it:

unset MONGO_APP_PASSWORD

Do not put the administrator credential in application configuration. The application should authenticate to the database where its user was created (raffapp).

Verify: raffappuser should exist in the raffapp database with readWrite on raffapp only and no administrative role.

Step 8 — Complete an authenticated CRUD test

Connect as the application user and run a disposable CRUD test:

mongosh "mongodb://127.0.0.1:27017/raffapp" \
  --quiet \
  --username raffappuser \
  --authenticationDatabase raffapp \
  --password \
  --eval '
const c = db.getSiblingDB("raffapp").tutorial_check;

c.deleteMany({ name: "raff-mongodb-test" });

const inserted = c.insertOne({
  name: "raff-mongodb-test",
  status: "created",
  createdAt: new Date()
});

const created = c.findOne({ name: "raff-mongodb-test" });
const updated = c.updateOne(
  { name: "raff-mongodb-test" },
  { $set: { status: "verified" } }
);
const verified = c.findOne({ name: "raff-mongodb-test" });
const deleted = c.deleteOne({ name: "raff-mongodb-test" });

printjson({
  insertedId: inserted.insertedId,
  createdStatus: created.status,
  modifiedCount: updated.modifiedCount,
  verifiedStatus: verified.status,
  deletedCount: deleted.deletedCount
});
'

Expected fields include:

createdStatus: 'created'
modifiedCount: 1
verifiedStatus: 'verified'
deletedCount: 1

Verify: The non-admin application user should authenticate and complete create/read/update/delete operations only within its assigned database.

Step 9 — Keep port 27017 private and make firewall changes safely

Confirm the configured bind and active listener:

sudo grep -nE '^[[:space:]]*(port|bindIp):' /etc/mongod.conf
sudo ss -lntp | grep ':27017' || true

For a same-VM application, keep:

net:
  port: 27017
  bindIp: 127.0.0.1

Do not change the bind address to 0.0.0.0 to make Compass or another client convenient.

Before changing UFW from a remote shell, open a second SSH session and inspect current rules:

sudo ufw status numbered

If UFW is already active, add a deny rule if necessary:

sudo ufw deny 27017/tcp

If UFW is inactive, follow Set Up UFW Firewall on Ubuntu 24.04 instead of blindly enabling it from a single SSH session.

Verify: MongoDB should listen only on loopback for the default deployment, no public 27017 allow rule should exist, and SSH access should remain available.

Step 10 — Create a logical backup with mongodump

MongoDB Database Tools provide mongodump and mongorestore for logical BSON backups. Current Database Tools documentation supports compressed archives with --archive and --gzip. citeturn741727search3

For a standalone server, mongodump does not create a transactionally consistent multi-collection point-in-time snapshot while application writes continue. For important standalone data, quiesce application writes or take the backup during a maintenance window. Replica sets can use oplog-aware backup strategies.

Create a protected backup directory:

sudo install -d -m 700 /var/backups/mongodb
STAMP="$(date -u +%Y%m%d-%H%M%S)"

Create a compressed archive of the application database. Omitting a password value keeps it out of command history/process arguments and lets the tool prompt:

mongodump \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --db raffapp \
  --archive="/var/backups/mongodb/raffapp-${STAMP}.archive.gz" \
  --gzip

Restrict the file and verify that it exists:

sudo chmod 600 "/var/backups/mongodb/raffapp-${STAMP}.archive.gz"
ls -lh "/var/backups/mongodb/raffapp-${STAMP}.archive.gz"

Back up the server configuration separately:

sudo cp /etc/mongod.conf \
  "/var/backups/mongodb/mongod.conf-${STAMP}"
sudo chmod 600 "/var/backups/mongodb/mongod.conf-${STAMP}"

Copy production backup sets off-server. Raff Data Protection can add VM-level recovery, while Object Storage can be used by S3-compatible backup tooling.

Verify: The archive and configuration backup should exist with restricted permissions, application writes should have been controlled appropriately for a standalone consistency requirement, and a production copy should exist off-server.

Step 11 — Restore-test the backup into an isolated namespace

Do not prove a backup by overwriting raffapp.

Select the latest archive:

LATEST_BACKUP="$(ls -1t /var/backups/mongodb/raffapp-*.archive.gz | head -n 1)"
printf '%s\n' "$LATEST_BACKUP"

Restore the raffapp.* namespace into a disposable raffapp_restore_test.* namespace:

mongorestore \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --archive="$LATEST_BACKUP" \
  --gzip \
  --nsFrom='raffapp.*' \
  --nsTo='raffapp_restore_test.*'

MongoDB documents namespace remapping with --nsFrom and --nsTo, and current mongorestore supports compressed archives created by mongodump. citeturn741727search0turn741727search4

Inspect the restored collections:

mongosh --quiet \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --eval '
const restoreDb = db.getSiblingDB("raffapp_restore_test");
printjson(restoreDb.getCollectionNames());
'

For production recovery rehearsals, verify representative documents, indexes, and application-level invariants.

Remove the disposable restore database:

mongosh --quiet \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --eval 'printjson(db.getSiblingDB("raffapp_restore_test").dropDatabase())'

Verify: The archive should restore into the renamed test namespace, expected collections/documents should be readable, and the original raffapp database should remain untouched.

Step 12 — Optionally allow one private application VM with TLS

Use this only when the application and MongoDB run on separate private-network VMs. Authorization alone does not encrypt traffic.

Example network design:

MongoDB private IP: 10.0.0.5
Application private IP: 10.0.0.10
Private DNS name in certificate SAN: mongo.internal.example

Use a CA you control to issue a MongoDB server certificate. Combine the server certificate and its private key into a PEM file that mongod can read, and copy the CA certificate separately:

/etc/mongodb/tls/server.pem
/etc/mongodb/tls/ca.pem

Protect the files:

sudo chown -R root:mongodb /etc/mongodb/tls
sudo chmod 750 /etc/mongodb/tls
sudo chmod 640 /etc/mongodb/tls/server.pem
sudo chmod 644 /etc/mongodb/tls/ca.pem

Edit /etc/mongod.conf:

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.5
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/tls/server.pem
    CAFile: /etc/mongodb/tls/ca.pem

security:
  authorization: enabled

net.tls.mode: requireTLS makes MongoDB accept only TLS-encrypted network connections. citeturn741727search1

Restart and verify the private listener:

sudo systemctl restart mongod
systemctl is-active mongod
sudo ss -lntp | grep ':27017'

If UFW is active, allow only the application VM's exact private source address:

sudo ufw allow from 10.0.0.10 to 10.0.0.5 port 27017 proto tcp
sudo ufw status numbered

Copy only the CA certificate to the application VM. Test with the private DNS name that matches the server certificate:

mongosh "mongodb://mongo.internal.example:27017/raffapp" \
  --tls \
  --tlsCAFile /path/to/ca.pem \
  --username raffappuser \
  --authenticationDatabase raffapp \
  --password \
  --eval 'db.runCommand({ ping: 1 })'

Do not use --tlsAllowInvalidCertificates or --tlsAllowInvalidHostnames as a production shortcut.

After enabling requireTLS, local administrative commands must also use TLS and a hostname/address that can be validated by the certificate, or use a correctly issued certificate that covers the local administrative name.

Verify: MongoDB should listen only on loopback plus the intended private interface, UFW should allow only the application VM, and the client should connect with certificate validation rather than TLS-bypass flags.

Step 13 — Apply patch updates and treat 8.0 → 8.3 as a release upgrade

For the installed 8.3 repository, inspect pending MongoDB updates:

apt list --upgradable 2>/dev/null | grep -E '^mongodb-' || true

Before patching an important deployment:

1. create a fresh logical backup;
2. verify an off-server copy;
3. review MongoDB patch release notes;
4. check disk headroom and service health;
5. use an appropriate maintenance window.

Apply normal package updates within the configured 8.3 repository:

sudo apt update
sudo apt upgrade

Verify afterward:

systemctl is-active mongod
mongod --version | sed -n '1,8p'
apt-cache policy mongodb-org | sed -n '1,14p'

MongoDB's installation guidance says package-manager patch updates are normal, but major and minor release changes must follow the corresponding upgrade procedure. citeturn137205search11

For an existing 8.0 deployment, do not silently replace mongodb-org/8.0 with mongodb-org/8.3 and call that a patch. MongoDB's current upgrade documentation requires reviewing the 8.0 → 8.3 path and Feature Compatibility Version (FCV). citeturn137205search0turn137205search5

Check the current FCV as an authenticated administrator:

mongosh --quiet \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --eval 'printjson(db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }))'

After a release upgrade, MongoDB recommends a burn-in period before enabling backwards-incompatible features through a higher FCV because doing so can complicate downgrade. citeturn137205search7

Verify: Patch updates should remain inside the intended repository line, mongod should restart cleanly, and any 8.0 → 8.3 change should have a documented upgrade/FCV/rollback plan rather than an ad-hoc repo edit.

Step 14 — Run the final MongoDB security and recovery audit

Check package, service, listener, and firewall state:

echo 'Package:'
apt-cache policy mongodb-org | sed -n '1,14p'

echo 'Service:'
systemctl is-active mongod
systemctl is-enabled mongod

echo 'Listener:'
sudo ss -lntp | grep ':27017' || true

echo 'Firewall:'
sudo ufw status numbered

Check authorization and authenticated users:

mongosh --quiet \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --eval '
printjson({
  admin: db.getSiblingDB("admin").getUser("raffadmin"),
  app: db.getSiblingDB("raffapp").getUser("raffappuser"),
  fcv: db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
});
'

If Step 12 enabled requireTLS, run the same checks with the appropriate --tls, --tlsCAFile, and certificate-valid hostname.

Confirm all of the following:

• MongoDB comes from the intended official mongodb-org/8.3 repository;
• mongod is active and enabled;
• authorization is enabled;
• the localhost exception has closed after first-user creation;
• the administrator and application accounts are separate;
• the application user is scoped to raffapp;
• public 27017 access is blocked;
• any private remote connection uses exact source-IP filtering and validated TLS;
• a logical backup exists off-server;
• a namespace-remapped restore test has succeeded;
• normal patch updates stay within the configured release line;
• release upgrades follow MongoDB's documented version/FCV path.

Verify: There should be no public unauthenticated MongoDB path, no application use of the root administrator, no TLS verification bypass, and no backup or release-upgrade plan that has never been tested.

Troubleshooting

mongodb-org has no installation candidate

Check the release file and repository:

. /etc/os-release
echo "$VERSION_CODENAME"
cat /etc/apt/sources.list.d/mongodb-org-8.3.list
sudo apt update
apt-cache policy mongodb-org

Expected signals include noble, repo.mongodb.org, and a non-empty candidate.

mongod does not start

Inspect systemd and MongoDB's log:

sudo systemctl status mongod --no-pager
sudo journalctl -u mongod --no-pager -n 100
sudo tail -n 100 /var/log/mongodb/mongod.log

If the failure followed a configuration edit, compare against the timestamped /etc/mongod.conf.*.backup file before changing data files.

Authentication fails after the first user is created

The localhost exception closes immediately after the first user or role is created. Authenticate with the database where the user was created:

mongosh --quiet \
  --host 127.0.0.1 \
  --username raffadmin \
  --authenticationDatabase admin \
  --password \
  --eval 'printjson(db.runCommand({ connectionStatus: 1 }).authInfo)'

For raffappuser, use --authenticationDatabase raffapp.

MongoDB listens on a public interface

Restore a local-only network configuration:

net:
  port: 27017
  bindIp: 127.0.0.1

Restart and verify:

sudo systemctl restart mongod
sudo ss -lntp | grep ':27017'

Do not rely on authorization alone to protect a public database listener.

mongodump succeeds but the backup may be inconsistent

On a standalone server, coordinate a maintenance window or pause application writes when a cross-collection consistent logical backup matters. For higher availability and point-in-time recovery requirements, use a replica-set-aware backup design rather than treating a live standalone dump as a transactional snapshot.

mongorestore asks to overwrite production data

Stop and verify --nsFrom/--nsTo. A recovery rehearsal should target raffapp_restore_test.*, not raffapp.*. Avoid --drop against production during a backup test.

TLS connections fail after enabling requireTLS

Check the certificate/key permissions, certificate SAN, listener, and logs:

sudo ls -l /etc/mongodb/tls
sudo ss -lntp | grep ':27017'
sudo journalctl -u mongod --no-pager -n 100

Use the hostname represented in the server certificate and the correct CA file. Do not bypass validation to hide a certificate-name or trust-chain problem.

Conclusion

You now have MongoDB 8.3 Community Edition on Ubuntu 24.04 from MongoDB's official repository, authorization enabled before first-user creation, separate administrator and application identities, authenticated CRUD verification, private-by-default networking, logical backup and isolated restore testing, and an optional validated-TLS path for a separate application VM.

The key 2026 maintenance rule is to distinguish patch updates from release upgrades. Routine APT updates inside the configured 8.3 repository are not the same operation as moving an existing 8.0 deployment to 8.3; release upgrades require MongoDB's documented version and FCV procedure. citeturn137205search11turn137205search0

Continue with Install PostgreSQL on Ubuntu 24.04, Install MySQL on Ubuntu 24.04, and Set Up UFW Firewall on Ubuntu 24.04.

Sources

• MongoDB Community installation
• MongoDB Community Ubuntu troubleshooting
• MongoDB 8.0 Ubuntu installation
• MongoDB localhost exception
• MongoDB SCRAM authentication
• MongoDB configuration options
• MongoDB 8.0 to 8.3 upgrade
• mongodump examples
• mongorestore
• Package, security, backup, and upgrade guidance re-verified: 2026-09-05