I'd try removing ENTRYPOINT in your Dockerfile. Also, I'd recommend choosing either using CMD or specifying the start command in your CaC file. Not 100% sure but it may be fighting each other.

Another note, if your service is truly online, it should say "Online" instead of "Completed."

▎ The clue that jumps out most from your post is earlier deploys today showed migration logs, the latest one doesnt — same

▎ commit, same Dockerfile, no code change between em. That points at Railway-side config drift (start command / env vars)

▎ more than the image itself.

▎

▎ Exit 0 + "Completed" status + no log output + no outbound traffic is the signature of a start command that silently no-ops,

▎ which can happen a handful of ways. worth checking in this order:

▎

▎ 1. Custom Start Command in the dashboard. Settings → Deploy → Custom Start Command. Open an older successful deploy from

▎ the history and compare its config to the current one. silent-fail patterns:

▎ - Field got cleared → tini -- runs with nothing → exits 0 immediately

▎ - Backgrounded process (python main.py &) → shell returns 0, container ends

▎ - Typo'd module / path → Python can exit before stdout is flushed

▎

▎ 2. PYTHONUNBUFFERED=1 env var. If its not set Python buffers stdout, so a crash + exit before flush gives you exactly what

▎ your seeing: "Starting Container" then nothing. Add it regardless — even if its not the root cause you stop flying blind on

▎ the next deplyo.

▎

▎ 3. Variables history. Same dashboard, Variables tab — diff env vars on the last good deploy vs current. Common pattern: a

▎ config validator does sys.exit(0) when an expected env var is missing and the app dies cleanly with no error.

▎

▎ 4. Healthcheck path. 502/000 on /health is a consequence of nothing listening, not the cause. Worth a quick glance to

▎ confirm /health is what the app actually exposes, but its not where the bug lives.

▎

▎ On the suggestion from @0x5b62656e5d about removing the tini ENTRYPOINT — fair instinct and worth keeping in the back

▎ pocket. Railway's Custom Start Command overrides Docker's CMD but ENTRYPOINT ["/tini", "--"] still wraps whatever runs, so

▎ tini should be exec-ing your start command transparently. Id rule out the four items above first since dropping tini costs

▎ you signal handling + zombie reaping — but if none of those land then yeah, trying without the ENTRYPOINT is a reasonable

▎ next step.

▎

▎ A diagnostic that narrows it down in one deploy — temporarily paste this as Custom Start Command:

▎

▎ sh -c "echo BOOT_OK && env | sort && exec python -u main.py"

▎

▎ Three outcomes:

▎ - BOOT_OK + env dump + your normal logs → stdout buffering + a bad normal start command. diff against the working deploy.

▎ - BOOT_OK + env dump, then silent exit 0 → main.py is exiting early. look at top-of-file config checks / sys.exit calls.

▎ - No BOOT_OK at all → cached / corrupt image layer, or the entrypoint angle the mod raised. Trigger a clean rebuild (small

▎ Dockerfile edit + redeploy without cache) and reassess.