How can I run NodeJS in Docker with MongoDB and RabbitMQ?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
Running a Node.js service with MongoDB and RabbitMQ in Docker is a common local-development setup for API and worker applications. The key is to let Docker Compose provide service discovery, persistent storage, and startup coordination so your app connects to mongo and rabbitmq by container name instead of hard-coded host addresses.
Use Compose To Define The Whole Stack
A small compose.yaml file is the simplest way to run the three services together:
This gives you:
- '
appfor the Node.js service' - '
mongofor the database' - '
rabbitmqfor the message broker'
The hostnames inside the Docker network are the service names, so the Node app should connect to mongo and rabbitmq, not localhost.
Build A Node Image That Starts Cleanly
The Node image can stay minimal:
Using npm ci instead of npm install is generally preferable in container builds when a lockfile exists, because it produces a more reproducible dependency tree.
Connect To MongoDB And RabbitMQ From Node
Inside the application, use the container hostnames from the environment variables:
This example connects once at startup, creates a durable queue, and publishes a simple message on each request.
Expect Startup Timing Issues
depends_on controls container startup order, but it does not guarantee MongoDB or RabbitMQ are fully ready for connections by the time Node starts. In real stacks, add retry logic:
Use that wrapper around database and broker initialization so the app survives short warm-up delays.
Running The Stack
From the project directory:
Once it is running:
- the Node app is reachable on port
3000 - MongoDB is reachable on port
27017 - RabbitMQ's management UI is reachable on port
15672
That is enough for local development, simple demos, and integration testing.
Common Pitfalls
One common mistake is using localhost inside the Node container. From one container, localhost means that same container, not MongoDB or RabbitMQ.
Another issue is assuming depends_on means "ready for queries." It only controls startup ordering unless you add readiness handling yourself.
A third problem is forgetting to persist MongoDB data in a volume, which makes the database look empty after the stack is recreated.
Finally, teams often hard-code secrets in the compose file and then copy the same pattern to production. For real deployments, move credentials into environment management or secret storage.
Summary
- Use Docker Compose to run Node.js, MongoDB, and RabbitMQ as one networked stack.
- Connect to
mongoandrabbitmqby service name, notlocalhost. - Keep the Node image simple and reproducible with
npm ci. - Add retry logic because startup order is not the same as service readiness.
- Use volumes for MongoDB data and treat local-development credentials separately from production.
Related reading
- How can I send data without schema to kafka - confluent jdbc - sink usage?
- How can I send large messages with Kafka over 15MB?
- How can I set unlimited retention for an compacted topic in Kafka?
- How can I show a end-to-end transaction over RabbitMQ in Application Insights?
- How can I run script automatically after Docker container startup
- How can I start spring boot application in docker with profile?
- How can I Scan an index in reverse in DynamoDB?
- How can I search case-insensitive in a column using LIKE wildcard?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.