Copy files into a Docker container

Use docker cp LOCAL_PATH CONTAINER:/path to put a file into an existing container. It works with running and stopped containers. For temporary debugging, it can be convenient to replace a configuration file without rebuilding the image immediately.

docker cp ./app.conf myapp:/etc/app/app.conf
docker cp ./conf/. myapp:/etc/app/

The /. suffix means “copy this directory's contents.” Create or confirm the destination's parent directories first: Docker can create the final directory in supported directory-copy cases, but it does not create an arbitrary missing parent hierarchy. An existing destination file may be overwritten.

Validate before reloading

A copied file is not automatically reread by the application. For an Nginx container, validate its configuration before requesting a reload:

docker exec myapp nginx -t
docker exec myapp nginx -s reload

Only run the reload after validation succeeds. These commands assume the container actually runs Nginx and contains its executable. Other applications have different reload procedures; some require a restart.

docker restart myapp stops and starts the same container. Its writable-layer changes normally remain. Deleting and recreating the container discards that layer; an application entrypoint can also regenerate configuration on startup.

Decide where the change belongs

A copy into a mounted path changes that mount's backing storage if it is writable. It is therefore inaccurate to assume every copied file lives only in the container layer.

For an emergency image snapshot, docker commit myapp myapp:patched can preserve applicable filesystem changes, but it excludes mounted volume data. Reproduce the intended change in your build or configuration source afterward; do not treat a snapshot as a complete deployment backup.

FAQ

Who owns copied files?

Files copied into a container are normally created as root-owned. docker cp -a preserves source UID/GID information; it is not merely a permission-bit switch. Verify the application's required ownership and adjust it deliberately if necessary.

Why does copying fail on a writable-looking path?

Check missing parents, read-only mounts, the container's read-only root filesystem, and daemon-side permissions. Running the CLI with elevated privileges is not a general fix for these different cases.

Does COPY make a file permanent?

It puts the file in the image, so new containers based on that image receive it unless a mount obscures it. Tags can change and images can be removed; keep the Dockerfile and source files in version control.

See docker cp and container commit.