Regression: Dockerfile build context defaults to the Dockerfile's own directory again (PR #5271 reverted the fix from #5231)

[nheggoe]

To Reproduce

1. Have a repo where a Dockerfile lives in a subdirectory and references a file that lives elsewhere in the repo, e.g.:

   .
   ├── shared/
   │   └── config.json
   └── docker/
       └── api/
           └── Dockerfile
   

   with docker/api/Dockerfile containing:

   FROM alpine
   COPY shared/config.json /app/config.json

2. In Dokploy, create a Dockerfile-type application and set the Dockerfile path to docker/api/Dockerfile.
3. Leave the Docker Context Path field empty (its placeholder implies the default is ., i.e. the repo root).
4. Deploy.
5. The build fails because shared/config.json isn't present in the build context — Dokploy used docker/api/ as the context instead of the repo root:

   #5 [2/2] COPY shared/config.json /app/config.json
   #5 ERROR: failed to calculate checksum of ref ...: "/shared/config.json": not found
   

For comparison, an equivalent Compose-type app with compose.yaml declaring context: . and dockerfile: docker/api/Dockerfile builds the same Dockerfile correctly, since it actually uses the repo root as context.

Current vs. Expected behavior

Expected: with Docker Context Path left empty, the build context defaults to the application's code root ., matching the field's own placeholder and matching how docker compose build resolves the same Dockerfile.

Actual: the build context defaults to the Dockerfile's own directory instead, so any file reference outside that directory 404s during the build.

Provide environment information

Operating System:
  OS: Ubuntu (self-hosted VPS)
  Arch: amd64
Dokploy version: 0.30.6
VPS Provider: (self-hosted / on-prem)
What applications/services are you trying to deploy?
  Dockerfile-type applications in a monorepo, where the Dockerfile lives in a
  subdirectory (e.g. docker/<service>/Dockerfile) and COPYs files from the repo
  root, matching the context: . setting used by the equivalent compose.yaml.

Which area(s) are affected? (Select all that apply)

Docker, Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

No response

Will you send a PR to fix it?

Maybe, need help

[linear-code]

DOK-765

[Hayyan612]

I hit this on a monorepo in production, so I went looking for why it came back. The history is a bit more subtle than a straight revert, and I think it explains why it slipped through.

#5231 removed the || defaultContextPath fallback and made getDockerContextPath always return a path (dockerContextPath || "."). But its commandArgs still passed a literal "." as the build context, so the context was the repo root regardless of what the function returned.

#5271 then did two things. It made commandArgs use dockerContextPath instead of the hardcoded ".", which is correct and an improvement. But it also restored return null in getDockerContextPath along with defaultContextPath = dockerFilePath.substring(0, lastIndexOf("/") + 1). Those two together mean an empty context field now resolves to the Dockerfile's own directory and that value actually reaches docker build.

So both PRs were individually reasonable; the regression is in the combination.

If that reading is right, the fix keeps #5271's improvement and restores #5231's default:

// directory.ts
export const getDockerContextPath = (application: Application) => {
	const { APPLICATIONS_PATH } = paths(!!application.serverId);
	const { appName, dockerContextPath } = application;

	return path.join(APPLICATIONS_PATH, appName, "code", dockerContextPath || ".");
};

// docker-file.ts
const dockerContextPath = getDockerContextPath(application);

const commandArgs = ["build", "-t", image, "-f", dockerFilePath, dockerContextPath];

getDockerContextPath has only one caller, so nothing else depends on the null. I would want to check application.real.test.ts still passes, since that was the CI failure #5271 was addressing.

Happy to open a PR with a regression test covering the monorepo case from this issue. Want me to?