Docker Compose Working Directory: Set It Correctly

Updated 5 November 2026 · Standard formula, shown below

In Docker Compose, the working directory determines where relative paths in the Compose file are resolved and, separately, where commands start inside a container. Set the right directory for both jobs to avoid missing files, misplaced bind mounts, and commands running from an unexpected location. You will need Docker with the Compose plugin and a project directory containing a Compose file.

What You’ll Need

Docker installed and running, with the docker compose command available.
A project directory containing a Compose file, such as compose.yaml or docker-compose.yml.
A text editor and a terminal or command prompt.

Step-by-Step

Distinguish the two meanings of “working directory.” Compose has a project directory on your host, which affects how Compose locates files and interprets relative paths. A container has its own working directory, which affects where its process starts. The host and container filesystems are separate; setting one directory does not automatically set the other.
Choose how to set the Compose project directory. By default, Compose uses the directory associated with the Compose file it loads as the project directory. To specify a directory explicitly, run Compose with --project-directory:

docker compose --project-directory ./my-app -f ./my-app/compose.yaml up -d

Paths in this example are interpreted from the directory where you run the command, unless they are absolute. The project-directory option sets the base directory Compose uses for project-related relative paths. You can also use an absolute path if you need predictable behavior from different terminal locations.

Set the container’s working directory in the service. Add working_dir under the service in your Compose file. It should name a path inside the container, not a path on your computer:

services:
  app:
    image: node:22
    working_dir: /app
    command: npm start

Here, the container starts in /app, so npm start runs from that location. The directory must exist in the image or be created by a mounted volume or another setup step. For portable configurations, use an absolute container path such as /app.

Mount your project files at the same container path. A common development setup mounts the host project into the working directory:

services:
  app:
    image: node:22
    working_dir: /app
    volumes:
      - .:/app
    command: npm start

The dot on the left means the host-side project directory, resolved using Compose’s path rules. /app on the right is the mount location in the container. If Compose is launched with an unexpected project directory, the host-side dot may refer to a different folder. Use an explicit host path when needed.

Check the configuration before starting services. Run docker compose config from the intended project context. Review the rendered configuration for the service’s working_dir, volume source, and Compose file selection. This can reveal a wrong file or an unexpected relative path before a container starts.
Start the service and verify its directory. Run docker compose up -d, then check the running container:

docker compose exec app pwd

Replace app with the service name. The output should match the container path set in working_dir. To check the host directory mounted there, list its contents with docker compose exec app ls -la /app.

Use a consistent command when the Compose file is elsewhere. Specify the file and project directory explicitly, for example:

docker compose -f /work/my-app/compose.yaml --project-directory /work/my-app up -d

This avoids relying on whichever directory happens to be current in your terminal. Keep the paths consistent when using multiple Compose files; specify each with its own -f option.

Common Mistakes

Confusing host and container paths: working_dir: /app is a path inside the container. A host path such as ./src belongs on the source side of a volume mapping.
Assuming working_dir changes where Compose looks for files: It does not select the Compose file or set the project directory. Use -f to select a file and --project-directory to set the project base.
Using a relative bind-mount path without checking its base: The source may resolve to a different directory than expected. Check the result with docker compose config.
Setting a directory that does not exist: A command may fail if its expected files are absent. Make sure the image, mount, or startup process provides the directory and required files.
Expecting a container’s current directory to persist after it exits: Working directory is configuration for a container process, not a change to your host shell’s location.

Tips

Prefer a clear, stable container path such as /app, and use that same path for working_dir and the destination of the application volume.
Keep the Compose file near the project when practical. This makes relative paths easier to understand and share.
For scripts, set the service’s working directory in the Compose file rather than relying on each user to remember a particular shell location.
Use docker compose run --rm app pwd to check the configured directory with a one-off container. This runs the service configuration without requiring an already-running service.
Quote paths in shell commands if they contain spaces. In YAML, use quotes when they make a path or value clearer.

Troubleshooting

A relative volume mounts the wrong folder: Confirm which Compose file is being loaded and where you ran the command. Run docker compose config with the same -f and --project-directory options, then inspect the resolved volume. Use an absolute source path temporarily to confirm the intended host folder.

The command says a file or directory is missing: Check the container path with docker compose exec app pwd and inspect it with ls -la. Confirm that the volume is mounted to the location your command expects, and that the host source contains the required files.

The configured directory appears to be ignored: Verify that working_dir is indented under the correct service, not at the top level. Recreate the service after changing its configuration with docker compose up -d --force-recreate app. Then check again with pwd.

Compose cannot find the file: Provide the correct path using -f. If the Compose file is in a different project directory, also set --project-directory. Check spelling and capitalization; Linux container paths are case-sensitive.

Frequently Asked Questions

What does working_dir do in Docker Compose?
It sets the working directory inside the container for the service’s process. It does not set the host terminal’s directory or choose the Compose file.

How do I set the working directory for the Compose project?
Use docker compose --project-directory /path/to/project. Use -f as well if the Compose file is not selected automatically.

Is working_dir the same as WORKDIR in a Dockerfile?
Both set a container working directory. A Dockerfile’s WORKDIR sets it in the image; a Compose service’s working_dir sets or overrides it for that service.

Does the working directory need to exist?
Yes, the container must have the directory available when its process runs. Provide it through the image, a mounted volume, or suitable startup setup.

How can I see the directory a running service uses?
Run docker compose exec SERVICE pwd, replacing SERVICE with the service name. If it is not running, try docker compose run --rm SERVICE pwd.

Can I use a relative path for working_dir?
Use an absolute path inside the container for clarity and portability. Host-side relative paths belong in volume sources and depend on the Compose project context.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.