Set RAILWAY_DOCKERFILE_PATH=apps/api/Dockerfile in your service variables, and redeploy.

I followed your recommendation and set RAILWAY_DOCKERFILE_PATH=apps/api/Dockerfile on the @fortress-fund/api production service, then redeployed.

New deployment: a0a4646e-7744-4c8d-81d6-bc5da12ff6f2

The deployment snapshot still resolves the builder as RAILPACK, despite the service configuration being DOCKERFILE and the variable being present. It again fails at BUILD_IMAGE, with no build logs exposed.

This appears to confirm that the deployment snapshot is not honoring either the service's Dockerfile builder configuration or RAILWAY_DOCKERFILE_PATH. Could you please investigate the deployment/source configuration resolution for this service?

Thanks. I followed the RAILWAY_DOCKERFILE_PATH recommendation.

I set the following service variable on @fortress-fund/api in the production environment:

RAILWAY_DOCKERFILE_PATH=apps/api/Dockerfile

I then manually redeployed the existing service.

Result: the problem persists.

The new deployment was:

a0a4646e-7744-4c8d-81d6-bc5da12ff6f2

Railway's deployment diagnosis reports:

Status: FAILED
Builder: RAILPACK
Dockerfile: apps/api/Dockerfile
Root directory: /
Failure stage: BUILD_IMAGE
Error: Failed to build an image. Please check the build logs for more details.

The service configuration still reports the builder as DOCKERFILE, with:

Repository: mustardir/rentable-
Branch: main
Root: /
Dockerfile: apps/api/Dockerfile
Build command: pnpm --filter @fortress-fund/api build

The build-log query for the deployment returned no build log entries.

This means the suggested variable did not change the builder selected in the deployment snapshot: it still resolves to RAILPACK even though the service configuration is DOCKERFILE and RAILWAY_DOCKERFILE_PATH is set.

For comparison, the immediately preceding deployment was also affected:

2445ea82-7d59-4ace-8bf5-e282f1906af4

It likewise resolved to RAILPACK and failed at BUILD_IMAGE.

Could you please advise what Railway-side configuration or deployment state determines the builder shown in the deployment snapshot, and why it is resolving to RAILPACK despite the service configuration and RAILWAY_DOCKERFILE_PATH both specifying the Dockerfile?

I have not made any further repository changes or database changes. The application commit being deployed is still:

3fa6aca39ecb515931cd07856c9d77ca22fb2266

At this point, the remaining blocker is understanding why the deployment snapshot is not honoring the configured Dockerfile builder.

Have you applied the changes after adding the variable? It should auto redeploy when you apply changes, instead of you manually redeploying.

Three different config changes — re-saving the Dockerfile settings, reconnecting the source, adding RAILWAY_DOCKERFILE_PATH — all produced identical results. That pattern is the most informative thing in your report: when nothing you change in the dashboard has any effect, something outside the dashboard is deciding.

First thing to check: railway.json or railway.toml in the repo. Look at the repo root and apps/api/. Config-as-code overrides dashboard settings without updating what the dashboard displays — which is precisely your symptom, service config reporting DOCKERFILE while the deployment snapshot resolves otherwise. In the deployment details pane, values sourced from a config file are marked with a file icon; that tells you where each setting actually came from. If such a file exists and declares a builder, or sets build.buildCommand without build.dockerfilePath, that's the whole explanation and it accounts for all three interventions failing.

Second: clear the build command. You have a Dockerfile builder and pnpm --filter @fortress-fund/api build set as the build command. Those belong to different build paths — with a Dockerfile, your RUN layers do the building and the build-command field should be empty. A service carrying both is in a mixed state, and the presence of a Railpack-era build command is a plausible reason resolution drifts toward Railpack. Same for the start command, unless your Dockerfile has no CMD.

On the empty build logs, I'd read your evidence differently. You concluded the Dockerfile isn't being executed. I think the stronger reading is that no build is executing. If Railpack were genuinely running and failing, you'd see Railpack's own output — provider detection, install phase, something before the failure. Zero log entries across four deployments means the builder died before emitting a single line. That reframes the question from "why Railpack instead of Docker" to "why does the build process fail before initialising," and the builder shown in the snapshot may simply be the default displayed when resolution never completed. Your diagnostic Dockerfile step not running is consistent with this too — it's not evidence the Dockerfile was bypassed, it's evidence nothing ran.

Monorepo detail worth confirming: with root directory /, the Docker build context is the entire repo, so apps/api/Dockerfile must address paths from the repo root — COPY pnpm-lock.yaml ./ and COPY apps/api ./apps/api, never ../../. Your GitHub CI passing on the same commit doesn't rule this out; CI almost certainly builds with -f apps/api/Dockerfile from a different working directory, so a context mismatch would pass there and fail here. If you've been developing the Dockerfile against a local docker build apps/api, that's the same mismatch.

Order: check for the config file (one look, explains everything if present), clear the build command, redeploy. If the logs are still empty after both, it's Railway-side and the deployment IDs you've already posted are what staff need.

One question that would narrow this a lot: did this service ever deploy successfully, or is this the first deploy on it? A service that used to work and then stopped points at drift — a config file added to the repo, or a builder migration. A service that has never deployed points at the Dockerfile or the context. Your report doesn't say, and the two paths diverge completely.

The test failed again.

Exact result:

• Deployment: 6e26364d-037c-45d1-ac59-bf49ab6b373b
• Status: FAILED
• Failure stage: BUILD_IMAGE
• Snapshot still reports RAILPACK
• Dockerfile still reports apps/api/Dockerfile
• Root: /
• Generic error: Failed to build an image
• Diagnosis: none

So clearing the build command did not resolve the builder-resolution problem.

Next exact action

Do not change another Railway setting yet.

We should now check the repository itself for railway.json / railway.toml at:

• /railway.json
• /railway.toml
• /apps/api/railway.json
• /apps/api/railway.toml

That is the next diagnostic because the dashboard is still showing Dockerfile while the deployment snapshot resolves RAILPACK.

Latest test result:

I cleared the Railway service build command and redeployed. The deployment still failed:

• Deployment: 6e26364d-037c-45d1-ac59-bf49ab6b373b
• Commit: 3fa6aca39ecb515931cd07856c9d77ca22fb2266
• Failure stage: BUILD_IMAGE
• Deployment snapshot builder: RAILPACK
• Dockerfile path: apps/api/Dockerfile
• Root directory: /
• Build command: empty
• Start command: pnpm --filter @fortress-fund/api start

I also checked the repository on main. There is no railway.json or railway.toml at the repo root or under apps/api/.

So the service has no Railway config-as-code file declaring the builder, and the build command is now empty, but the deployment snapshot still resolves to RAILPACK while the service configuration reports Dockerfile.

Please investigate the builder-resolution/deployment initialization for deployment 6e26364d-037c-45d1-ac59-bf49ab6b373b and provide the exact underlying diagnostic/build logs, including why RAILPACK is being selected and why the build fails at BUILD_IMAGE.

The next thing we need from Support is why that configuration is turning into RAILPACK during deployment

Can you share the screenshot of your Build Logs?