Applications

The repository builds three primary deployable binaries plus a small embedded library variant. They share most of src/mongo/ and differ mainly in their main() and the registered service entry point.

Pages

• mongod — the database server.
• mongos — the sharding router.
• jstestshell — the in-tree JavaScript shell used by jstests/.

Other binaries and embedded forms

• mongo_embedded / stitch_support — a library form of MongoDB intended for embedding in other applications. Lives at src/mongo/embedded/ and src/mongo/embedded/stitch_support/.
• op_msg_fuzzer_router / op_msg_fuzzer_shard — fuzz-test harnesses for the wire-protocol parser; see src/mongo/db/op_msg_fuzzer_*.cpp.
• mongocryptd and OCSP/Kerberos helpers — small auxiliary binaries built from src/mongo/ for security and field-level encryption.
• Replay tooling — src/mongo/replay/ builds a binary that replays captured traffic.

The full list of cc_binary targets can be enumerated with:

bazel query 'kind(cc_binary, //src/mongo/...)'

Shared infrastructure

All binaries link against the same core libraries:

• src/mongo/base/ — error codes, status, basic types.
• src/mongo/bson/ — BSON.
• src/mongo/util/ — futures, decorations, time, strings, processes.
• src/mongo/transport/ — wire protocol and gRPC.
• src/mongo/rpc/ — message framing and metadata.
• src/mongo/logv2/ — structured logging.
• src/mongo/idl/ — runtime support for IDL-generated code.
• src/mongo/executor/ — task executors and connection pools.
• src/mongo/scripting/ — JavaScript engine integration (used by jstestshell and by server-side $function/$accumulator).

The split between mongod and mongos is largely about which service is registered: a Service::shardRole() that handles data, or a Service::routerRole() that fans out to shards. Modern releases can run both roles in the same process — see src/mongo/db/service_entry_point_shard_role.cpp and src/mongo/s/service_entry_point_router_role.cpp, plus the Architecture page.