Introduction

When ng serve works on your host machine but not inside Docker, the problem is usually not Angular itself. It is almost always one of three issues: the dev server is only listening on localhost, the container port is not published correctly, or file watching does not work through the mounted volume. Fix those first before chasing anything more exotic.

Bind the Dev Server to All Interfaces

Inside a container, localhost means the container itself. If Angular listens only on 127.0.0.1, the host machine cannot reach it even if Docker publishes the port.

Start the dev server like this:

ng serve --host 0.0.0.0 --port 4200

That tells Angular to listen on every network interface inside the container.

Publish the Port from Docker

Exposing the port in the image is not enough by itself. You also need to publish the container port to the host.

docker run --rm -it -p 4200:4200 my-angular-dev

A minimal development Dockerfile looks like this:

1FROM node:20
2WORKDIR /app
3COPY package*.json ./
4RUN npm install
5COPY . .
6CMD ["npx", "ng", "serve", "--host", "0.0.0.0", "--port", "4200"]

If you use Docker Compose, the same idea applies:

1services:
2  web:
3    build: .
4    ports:
5      - "4200:4200"
6    volumes:
7      - .:/app
8      - /app/node_modules

Fix File Watching for Bind Mounts

On macOS, Windows, and some Linux setups, file system notifications may not propagate cleanly from the host into the container. The result is that the server starts, but source edits do not trigger rebuilds.

In that case, polling is often the practical fix.

ng serve --host 0.0.0.0 --poll 2000

Or set an environment variable for watch libraries that rely on polling:

environment:
  CHOKIDAR_USEPOLLING: "true"

Polling is less efficient than native file watching, but it is reliable for local container-based development.

Keep node_modules Inside the Container

A frequent source of broken Angular container setups is mounting the project directory from the host and accidentally overwriting container-installed dependencies. The anonymous volume entry for /app/node_modules in the Compose example prevents that.

Without it, host and container dependency trees can conflict, especially when host and container operating systems differ.

Check the Container Command and Install Step

If the container exits immediately, inspect whether Angular CLI is actually installed and whether the container command is invoking it correctly. In many projects, npx ng serve is safer than assuming a global ng binary exists.

Also confirm that npm install or npm ci ran successfully during image build. A published port cannot help if the dev server never started.

Confirm the Failure Mode Before Changing More Settings

Check these symptoms in order:

• page is unreachable from the host, which usually means host binding or port publishing is wrong
• page loads but code changes do not rebuild, which usually means file watching is wrong
• container exits immediately, which usually means the command failed or dependencies are missing

This sequence keeps debugging focused and prevents random configuration changes.

Common Pitfalls

• Running ng serve without --host 0.0.0.0 inside the container.
• Forgetting to publish port 4200 from the container to the host.
• Bind-mounting the project and unintentionally replacing container node_modules.
• Assuming file watching will work without polling on every host platform.
• Using ng serve as if it were a production web server.

Summary

• Make Angular listen on 0.0.0.0, not only on localhost.
• Publish the dev-server port with Docker.
• Use polling when file changes are not detected through mounted volumes.
• Keep node_modules managed inside the container.
• Diagnose the exact failure mode before changing unrelated Docker or Angular settings.