nginx keeps serving the old config after git checkout/git pull

Symptom

You change nginx.conf in the repo (git pull, git checkout <branch>, git apply, sed -i), run docker compose exec lb nginx -s reload, and nginx still behaves like the old file: new locations 404, old headers still sent. nginx -t inside the container says the syntax is fine — because it is testing the old file:

host:      grep -o 'v[0-9]' nginx.conf                         -> v2
container: docker exec lb grep -o 'v[0-9]' /etc/nginx/nginx.conf -> v1

When it happens

The config is mounted as a single file:

services:
  lb:
    image: nginx:1.30-alpine
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

and the file on the host is replaced by a tool that writes a new file and renames it over the old one. Measured which edits change the inode (Linux; the table was made with mount --bind, which is what Docker does for -v file:file):

Cause

A bind mount of a file binds the inode, not the path. When git replaces the file, the path on the host points to a new inode, but the container's mount still references the old one (still alive because it is mounted). Reloading nginx re-reads the old inode. Directory mounts do not have this problem: the directory inode stays, and lookups inside it resolve to the new file.

Fix

After any change to a single-file-mounted config, re-create the mount:

docker compose up -d --no-deps --force-recreate lb

--no-deps matters: without it Compose also recreates the services lb depends on (e.g. your API), which can drop runtime state you gave them. In the reproduction a plain docker restart lb also picked up the new file (the mount is re-established on start); nginx -s reload alone never did.

Better, mount the directory and point nginx at the file in it:

    volumes:
      - ./nginx:/etc/nginx/conf.d:ro          # contains default.conf / snippets

or for a full nginx.conf: mount ./lb:/etc/nginx/site:ro and start with nginx -c /etc/nginx/site/nginx.conf -g 'daemon off;'. Reproduced (with a directory mount --bind): git checkout + nginx -s reload served the new config immediately.

Verify

Compare what the container reads with what the repo has:

diff <(docker compose exec -T lb cat /etc/nginx/nginx.conf) nginx.conf && echo "container sees current file"

or compare inodes (on a Linux host):

stat -c %i nginx.conf
docker compose exec -T lb stat -c %i /etc/nginx/nginx.conf   # differs from host after git replaced it

Put the diff in your deploy script after the reload, and recreate the container when it fails.

Notes

• nginx -s reload, nginx -t, HUP — all operate on the stale file; they are not the problem.
• On Docker Desktop (Windows/macOS) with host paths shared into the VM, file-mount behaviour depends on the file-sharing layer; the reproduction above is Linux Docker Engine semantics. Deploy scripts that compute md5sum /etc/nginx/nginx.conf via docker exec from Git Bash on Windows can also have the path rewritten to C:/Program Files/Git/etc/... by MSYS path conversion — set MSYS_NO_PATHCONV=1 for that call.
• The same inode trap applies to any single-file mount: prometheus.yml, haproxy.cfg, .env files mounted into containers.