12.1.1.2 Dev Hot Reload
A focused guide to Dev Hot Reload, connecting core concepts with practical Docker and container operations.
Dev hot reload is the development server behavior, running inside a container, that automatically detects a source code change (made possible by a source bind mount) and reloads or rebuilds the running application without requiring a manual restart, providing the fast, iterative feedback loop central to productive development.
Configuring a Development Server With Hot Reload Inside a Container
A development command, run as the container's process, watches for file changes and automatically reloads.
services:
app:
build: .
volumes:
- .:/app
command: npm run dev
{
"scripts": {
"dev": "nodemon src/index.js"
}
}
A tool like nodemon, running as part of this dev script, watches for source changes (made visible through the bind mount) and automatically restarts the application process when one occurs.
Why Both the Bind Mount and the Watching Tool Are Necessary
The bind mount alone provides visibility into current source files; the watching tool's role is to actually detect changes and trigger the corresponding reload — both pieces are necessary for the complete hot reload experience.
echo "// change" >> src/index.js
docker compose logs -f app
Watching the logs after a change like this should reveal the development server automatically detecting and reacting to it.
Addressing File-Watching Reliability Across Platforms
Certain file-watching mechanisms can be less reliable across a bind mount on non-Linux hosts, sometimes requiring a fallback to polling-based detection.
CHOKIDAR_USEPOLLING=true npm run dev
Why Hot Reload Specifically Matters for Productive Development
Without hot reload, even with a working source bind, a developer would still need to manually restart the application after every change — hot reload removes this remaining friction, delivering the fully automatic, immediate feedback loop developers have come to expect.
docker compose up -d
Why Dev Hot Reload Matters
Hot reload, built on top of a working source bind mount, is what actually completes the fast, iterative development experience containerized development aims to provide, and getting this configuration right is essential to a genuinely productive containerized workflow.