BuildKit executing wrong Dockerfile despite correct root directory and NO_CACHE=1

chicogonzales

HOBBYOP

2 months ago

I have a monorepo with two services. Service A (agent-runtime) has been running fine. Service B (mcp-gateway) is new, with root directory set to services/mcp-gateway.

Build log confirms "found 'Dockerfile' at 'services/mcp-gateway/Dockerfile'" but then executes instructions from Service A's Dockerfile instead.

My gateway Dockerfile contains FROM node:20-slim but build shows node:20-alpine. My Dockerfile has zero COPY agents/ lines but build copies 15+ agent files. NO_CACHE=1 is set, log shows "Caching Disabled", yet every layer says "cached".

Tried: NO_CACHE=1, RAILWAY_DOCKERFILE_PATH env var, clearing/setting Dockerfile Path in Settings, renaming Dockerfile, changing base image, ARG CACHE_BUST, LABEL, unique stage names, deleting and recreating the service.

Is there a way to purge the BuildKit cache for a specific service/builder?

$10 Bounty

2 Replies

Status changed to Open Railway • 2 months ago

chicogonzales

HOBBYOP

2 months ago

Update: Root cause confirmed and resolved.

We added diagnostic RUN echo lines to both Dockerfiles. The build log printed the agent-runtime echo, not the gateway's — proving BuildKit parsed the root Dockerfile, not the gateway's.

The root cause: Railway's root directory setting controls Dockerfile discovery but not the build context sent to BuildKit. Our gateway directory is ~46KB but the build snapshot was 1.4MB (full repo). With the full repo as context, BuildKit finds the root Dockerfile and uses that — despite RAILWAY_DOCKERFILE_PATH being set to services/mcp-gateway/Dockerfile.

What worked:

railway up --service mcp-gateway --path-as-root services/mcp-gateway — sends only the gateway directory as build context (46KB snapshot). BuildKit finds the correct Dockerfile, builds with the correct base image and instructions.

What did NOT work (11 attempts):

NO_CACHE=1, RAILWAY_DOCKERFILE_PATH, ARG/LABEL cache busting, renaming Dockerfile, changing base image, deleting/recreating service, separate project. None of these change the build context scope.

Suggestions for Railway:

Ensure RAILWAY_DOCKERFILE_PATH results in BuildKit actually using the specified file, even when a root Dockerfile exists in the context
Scope build context to the root directory setting — not just Dockerfile discovery
Log the actual build command dispatched to BuildKit so users can debug path resolution

kadioko

HOBBY

a month ago

This is usually a build-context issue, not a Docker cache issue.

If the service lives in a monorepo, try deploying with the service folder as the build context:

railway up --service mcp-gateway --path-as-root services/mcp-gateway

Replace mcp-gateway and services/mcp-gateway with your actual service name/path.

The important bit is --path-as-root: it sends that folder as the root build context, so BuildKit will see the Dockerfile in that folder instead of accidentally resolving the root repo Dockerfile. NO_CACHE=1 will not fix it if the wrong context/Dockerfile is being selected.

Welcome!