27017 MongoDB TCP Flagship

What it's for

Port 27017 is the default port for MongoDB, the most widely used document-oriented NoSQL database. Instead of rows and tables, MongoDB stores flexible JSON-like documents (BSON internally), which made it a popular choice for applications with evolving or less rigidly structured data models. Application drivers and the mongosh shell connect to port 27017 to read and write data.

MongoDB's flexible schema and horizontal scalability model made it a default pick for a lot of early-2010s startups, and while relational databases have caught up substantially on JSON support, MongoDB remains extremely common for content stores, catalogs, and applications where document flexibility is a core requirement.

Protocol basics

• Protocol: TCP, for reliable ordered request/response exchange with the database.
• BSON wire format. MongoDB communicates using BSON (Binary JSON), a binary-encoded superset of JSON that supports additional types (dates, binary data) not present in plain JSON.
• Replica sets use the same port per node. A MongoDB replica set (multiple nodes for redundancy/failover) typically has each node listening on 27017, with drivers configured to know about all members and automatically handle failover to the current primary.
• Sharded clusters add additional ports. In a sharded deployment, mongos router processes (which clients actually connect to) commonly also use 27017, while the underlying shard servers and config servers use separate ports (27018/27019) behind the scenes.

Security considerations

• Unauthenticated, internet-exposed MongoDB instances have been a recurring, large-scale security incident — several years running, security researchers have found tens of thousands of exposed MongoDB databases with no authentication at all, leading to mass data breaches and "ransomware" style extortion where attackers wipe and hold data for ransom.
• Enable authentication (--auth) and role-based access control — MongoDB does not require authentication by default in many self-hosted setups, which is the root cause of the exposure incidents above.
• Never bind MongoDB to a public IP without a firewall/security group restricting access — this is the single most important, most commonly skipped step.
• Enable TLS for connections crossing any untrusted network, and use MongoDB's built-in encryption-at-rest options for sensitive data where applicable.

Troubleshooting

"MongoServerSelectionError: connect ECONNREFUSED":

• MongoDB isn't running, or is bound only to 127.0.0.1 rather than the network interface the client is connecting from (bindIp setting)

"Authentication failed":

• Wrong credentials, or the user isn't authorized against the specific database being targeted — MongoDB scopes users to specific databases unless explicitly given broader roles

Can connect via mongosh locally but app can't connect from another host/container:

• Check bindIp configuration and firewall/security group rules — the same class of issue as most other database connectivity problems

Replica set connection issues ("not master and slaveOk=false"):

• The driver is trying to write to a secondary node — ensure your connection string correctly identifies the replica set so the driver can locate and write to the current primary automatically

Comparison / FAQ

Why did so many MongoDB databases get hacked/ransomed in past incidents?

Because MongoDB historically didn't require authentication by default, and a large number of self-hosted instances were bound to public IPs without a firewall restricting access — attackers ran automated scans, found these open databases, and in many cases wiped the data while leaving a ransom note.

Is MongoDB still a good choice compared to a relational database in 2026?

It depends on the use case — MongoDB remains strong for genuinely flexible/document-shaped data and horizontal scaling patterns, but PostgreSQL's mature JSON/JSONB support has narrowed the gap significantly for use cases that used to be MongoDB's clearest advantage.

What's the difference between port 27017 and 27018/27019?

27017 is what application clients (and mongos routers in a sharded setup) connect to. 27018 and 27019 are internal ports used by shard servers and config servers respectively in a sharded cluster — application code typically never connects to these directly.

Should I use MongoDB Atlas (managed) instead of self-hosting?

For most teams without dedicated database operations expertise, a managed service like MongoDB Atlas removes an entire category of the security misconfiguration risk described above, since authentication, network access, and patching are handled by the provider by default.