absolute-workdir

WORKDIR app doesn't mean /app — it means "app relative to wherever the previous WORKDIR (or the base image's default) left us". The directory your files actually land in depends on instruction order and on the base image, and both can change under you. This rule flags WORKDIR instructions with relative paths.

What the rule catches

FROM node:22-slim
WORKDIR app
COPY . .

Scanning this file reports:

⚠ WARN [docker-doctor/absolute-workdir]
  WORKDIR specifies a relative path 'app'. For clarity and reliability, always use absolute paths.

Why it matters

Relative WORKDIRs compound: WORKDIR app after an inherited WORKDIR /usr/src puts you in /usr/src/app, and a later refactor or base-image bump silently moves every COPY, RUN, and CMD that follows. That failure mode — files in an unexpected directory, runtime MODULE_NOT_FOUND errors, nothing obviously wrong in the diff — costs an afternoon. WORKDIR /app costs one character and can never mean anything else.

How to fix it

Always specify absolute paths for WORKDIR instructions (e.g. WORKDIR /app).

FROM node:22-slim
WORKDIR /app
COPY . .

WORKDIR also creates the directory if it doesn't exist, so there's never a need for RUN mkdir -p /app before it. Use WORKDIR for all directory context instead of cd inside RUN — that half of the pattern is covered by avoid-run-cd.

Rule details

• Rule key — docker-doctor/absolute-workdir
• Category — Best Practices
• Default severity — warning
• Applies to — Dockerfiles

Explain this rule from the CLI:

npx @docker-doctor/cli@latest rules explain docker-doctor/absolute-workdir

Change its severity — or turn it off — in your config file:

// docker-doctor.config.ts
export default {
  rules: {
    "docker-doctor/absolute-workdir": "off",
  },
};

Severity affects the health score: error findings cost more points than warning, and info costs the least.