MongoDB Homebrew Tap: packaging the Community Server for macOS

A package source for MongoDB, not a MongoDB product

A Homebrew tap is a repository of formulae that Homebrew can install from, and mongodb/brew is the official MongoDB one. The README describes it plainly as a custom Homebrew tap for official MongoDB software, with a link to the MongoDB site and the Homebrew logo side by side at the top of the page.

The audience is a developer who wants a MongoDB server running locally, or who wants the shell and the command line tools without downloading installers from a browser. Everything the tap installs is the Community edition. There is no Atlas cluster here, no replica set deployment, no configuration of a hosted environment. The output of a successful install is binaries on your machine and a configuration file describing where they should write.

That framing matters for expectations. The tap is a packaging layer maintained by MongoDB, so what lands on disk is the official Community Server build, and what you do with it afterwards is your business. The tap also carries a support boundary that is worth stating early: MongoDB routes server bugs to the SERVER project on JIRA, and points general usage questions at community support resources, because the tap itself has no support surface of its own.

Formula, Aliases and tap_migrations.json shape the version map

The repository is small in structure and that structure is the whole design. The top level holds Formula/, Aliases/, a tap_migrations.json file, the README, the LICENSE and a .github/ directory. There is no server code, no packaging script written in Ruby that does anything clever, and no build pipeline for MongoDB itself. The formulae download artifacts that MongoDB already publishes.

Formula/ holds the installable definitions, which is where the plain mongodb-community, mongosh and mongodb-database-tools entries live. Aliases/ is the mechanism Homebrew provides for pointing an old or alternative name at a canonical formula, so that a user typing a familiar name gets redirected to the right one instead of an error. The tap_migrations.json file at the root records how formulas were migrated, which matters because a tap has to be able to move a formula to a new name or a new versioned file without stranding the users who already asked for the old one.

Versioned formulas such as [email protected] are ordinary formulae with a version suffix, which is how Homebrew lets several major series of the same product coexist on one machine.

Tapping and installing the Community Server

The setup step is one command, and the README says to run it in a MacOS terminal session:

brew tap mongodb/brew

After that, a single install pulls in the server and the toolchain around it:

brew install mongodb-community

According to the README this installs the latest available production release of the MongoDB Community Server, currently MongoDB Server 8.0.x, and it bundles more than the daemon. The formula includes the server processes mongod and mongos, the MongoDB Database Tools, and an install_compass script that installs MongoDB Compass separately.

If you only need one piece, there are separate formulae. The mongosh shell for connecting to remote instances:

brew install mongosh

and the command line tools, a suite that the README names as mongoimport, mongoexport and mongodump among others:

brew install mongodb-database-tools

Both are documented as unnecessary if you installed the community server first, since the server formula already brought them along. The tap also offers version specific installs for the latest 8.0.x and the latest 7.0.x production releases:

brew install [email protected]

brew install [email protected]

That last pair is the practical reason to use a tap rather than a download. A developer who needs to reproduce an issue against a 7.0 series server can keep both installed side by side.

Intel and M1 resolve to different prefixes

The mongodb-community formula creates three paths, and they all hang off the Homebrew prefix rather than a fixed location:

$(brew --prefix)/etc/mongod.conf
$(brew --prefix)/var/log/mongodb
$(brew --prefix)/var/mongodb

The first is the configuration file, the second the log directory, the third the data directory. The prefix itself differs by CPU architecture, and the README lists both values: Intel machines resolve brew --prefix to /usr/local, while M1 machines resolve it to /opt/homebrew.

This is the detail that trips people up, and it propagates into the commands you run later. A configuration path written by hand as /usr/local/etc/mongod.conf is correct on an Intel Mac and wrong on Apple silicon, where the same file sits under /opt/homebrew/etc/mongod.conf. Anything you script against the tap should therefore resolve the prefix rather than hard code it, and the README's own manual start example uses the Intel path.

The good news is that the service route sidesteps the issue entirely, because a launchd managed mongod uses the default paths listed above rather than a path you supply.

Running mongod under launchd or starting it by hand

There are two documented ways to have a server running, and they differ in more than ergonomics.

The service route uses Homebrew's own integration with launchd:

brew services start mongodb-community

The README states that this makes launchd start mongod immediately and restart it at login, and that a mongod managed this way uses the default paths above. Stopping it is the mirror command:

brew services stop mongodb-community

The manual route is a direct invocation with an explicit configuration file:

mongod --config /usr/local/etc/mongod.conf

The README carries an explicit warning about what happens when you leave out --config: the MongoDB server then has no default configuration file and no log directory path, and falls back to a data directory path of /data/db. That fallback is a classic source of confusion on macOS, where the process may lack permission for the root level directory and the failure looks nothing like a configuration problem.

Shutting a manually started server down is done through the admin database rather than a signal:

mongosh admin --eval "db.shutdownServer()"

That command needs the shell to be installed and to be able to reach the running instance.

Uninstalling the server leaves the Database Tools in place

Removal is straightforward for the server:

brew uninstall mongodb-community

But the README draws attention to a residue that surprises people. Uninstalling mongodb-community does not remove the bundled Database Tools, because the tools were installed as their own formula and Homebrew tracks them separately. To clear them out as well:

brew uninstall mongodb-database-tools

Two further points are implicit in the design rather than stated. The data directory the formula creates lives under the Homebrew prefix, and the README's uninstall instructions say nothing about it, so a clean removal of the server does not necessarily mean the files are gone from disk. And since the versioned formulae exist alongside the main one, uninstalling mongodb-community will not remove a separately installed [email protected] or [email protected], each of which is its own formula.

None of this is a defect so much as a consequence of Homebrew's model, where a formula's files and its directory layout are separable. It does mean that a migration between formula names needs an explicit uninstall step rather than an upgrade.

Tap updates and the licensing boundary

This repository publishes no GitHub releases. Its activity is measured in commits, and the last push was on 2026-10-13, with the repository not archived. Version tracking for the tap is therefore not something a release page tells you; it lives in the formula definitions and in tap_migrations.json.

The README also spells out who is expected to change the tap. If you are a MongoDB employee updating it, there is internal documentation linked from the project, and the reference to how to create and maintain a tap points at the Homebrew documentation the tap was built from. In other words, the tap is maintained by the vendor, not by the community, and the commit history is the place to look when you want to know what changed.

The licence is Apache-2.0, which covers the tap's own Ruby files and lets you read, modify and redistribute them under the standard Apache terms with the notice retained. It does not reach the software the formulae install. The MongoDB Community Server and the Database Tools arrive under their own licensing, and anyone using them commercially should read those terms rather than assume the tap's licence carries over.

Editorial conclusion

Use the mongodb/brew tap if you want MongoDB Community Server on a developer Mac through Homebrew, especially if you need a pinned series such as [email protected] alongside the current release. Do not use it as your production deployment method, since the tap is a package source, not a cluster installer, and it provides no upgrade path for an existing data directory. Before you install, verify two things in your own environment: which prefix your machine uses, since Intel resolves brew --prefix to /usr/local and M1 to /opt/homebrew, and whether you want mongod managed by launchd through brew services or started by hand with an explicit --config path.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. mongodb/homebrew-brew on GitHub
4. Project website
5. README