The service is currently building via Railpack, not the Dockerfile builder. Our records show builder=RAILPACK with no Dockerfile in use, which explains why no Docker/BuildKit output appears in failed builds and why the automated diagnosis referenced Python 3.13. Your local Docker build is testing a code path the service is not taking. To correct this, verify the builder is set to DOCKERFILE in the service's build settings (Settings > Build), and confirm the railway.toml nests the key correctly under [build] as builder = "DOCKERFILE" per the config-as-code reference.

Thanks. I still need help because this response reveals the exact contradiction I need Railway to investigate.

Your internal records reportedly show:

builder=RAILPACK and no Dockerfile in use.

However, the service UI currently shows:

Builder: Dockerfile

Automatically Detected

“The value is set in /railway.toml”

Dockerfile Path: Dockerfile

And the exact origin/main configuration at commit 2eb953a0c380b144574a0e178fc39a335aed7eae is:

[build]

builder = "dockerfile"

The repository has exactly one Dockerfile, beginning with:

FROM python:3.11-slim

I also built an exact pristine archive of that same commit locally. The build succeeded and the resulting image runs Python 3.11.16; asyncpg 0.29.0 and pydantic-core 2.18.2 install successfully as CPython 3.11 wheels.

So the key question is:

Why does Railway's effective deployment record say RAILPACK while both the repository config and Railway Settings UI say Dockerfile?

Please have a Railway engineer inspect the effective builder/config used for deployment 9465d481, including whether there is stale deployment configuration, a config parsing issue, cached service metadata, or an unexpected fallback from Dockerfile to Railpack.

Please also confirm which builder actually handled the successful redeploy versus the failed redeploy.

I do not want to change dependencies or the Dockerfile until this configuration mismatch is explained.

The earlier reply got it wrong, and your config is fine.

Your failed builds died before we ever fetched your code. When that happens railway.toml is never read, so the deployment record falls back to a default of Railpack, and that default is what the previous reply quoted. Nothing was ever built with Railpack. There was no fallback build, and there's no Docker output on those deploys because the build never started at all.

The failures line up with the deployment incidents on the evening of Aug 18: https://status.railway.com/incident/7M7CBL9X and https://status.railway.com/incident/YYU63JUO. Your deploy this morning at 10:17 UTC read railway.toml and finished in seconds because it reused the image already built from your Dockerfile. Your last full build, on Aug 18 at 20:33 UTC, ran the Dockerfile itself: python:3.11-slim, pip install, all five steps, exactly as your UI shows. The two failures this morning (08:40 and 10:18 UTC) were both redeploys of a deployment that broke during the incident window (commit 67acfc6), and a redeploy replays that same broken attempt.

Fresh commits, or redeploys of a deployment that previously succeeded, will build normally.

Thank you. This fully explains the discrepancy and matches our local Docker reproduction. We now understand why the failed deployment records showed RAILPACK even though our configured builder is Dockerfile. This resolves the builder issue for us.