a month ago
I need Railway engineering assistance with what appears to be a Railway-side deployment/runtime provisioning issue affecting my account/workspace.
This has been isolated extensively and is reproducible across multiple independent Railway projects/services.
EXPECTED BEHAVIOUR
A successfully built container should start, bind to Railway's assigned PORT, pass the health check, and become reachable.
ACTUAL BEHAVIOUR
Docker build succeeds.
Container starts.
Application preflight executes successfully and prints:
"All checks passed"
After that, the deployment produces no meaningful application activity.
There is:
- no Python traceback
- no application crash
- no dependency failure
- no OOM
- near-zero CPU/memory usage
- no HTTP requests reaching the application
- no successful health-check response
The deployment remains in this state until Railway's approximately 5-minute health-check window expires.
ISOLATION ALREADY PERFORMED
The same behaviour was reproduced across 3 separate services in 2 separate Railway projects:
PROJECT 1: unique-healing
Services:
- unique-healing
- oxxon-rc2-fresh
PROJECT 2: oxxon-platform-rc2-v2
Service:
- oxxon-platform-rc2
All failed in the same manner.
Most importantly, I replaced the production application with a trivial two-line hello-world ASGI application.
The trivial ASGI application failed in exactly the same way.
Therefore the issue is not specific to:
- my OXXON application
- product.composition
- FastAPI/Starlette application construction
- application dependencies
- the production business logic
- the original Docker startup configuration
Builds succeed and containers are provisioned far enough to execute Python/preflight, but the service never becomes reachable.
OTHER ISSUES FOUND AND ALREADY CORRECTED
During diagnosis we found two unrelated configuration issues:
- Nixpacks had selected Python 3.12, while the application requires Python 3.14 because it uses stdlib uuid.uuid7().
This has been corrected by using a Dockerfile pinned to:
python:3.14-slim
- FAST_DATA_DIR had previously been corrupted by Git Bash path auto-conversion while setting Railway variables.
This has also been corrected.
Neither correction resolved the deployment/runtime problem.
SSH / DIAGNOSTICS
An SSH key has already been registered with Railway and host trust configured.
The intended runtime diagnostic is:
railway ssh -s oxxon-platform-rc2 -e production "ps aux; env | grep -i port"
This needs to be executed while a deployment is still inside its health-check window.
Railway's own automated diagnosis did not identify the cause.
PLEASE INVESTIGATE RAILWAY-SIDE STATE
Please inspect the affected workspace/account/projects for:
- container scheduling/provisioning state
- runtime allocation
- PORT injection and container networking
- health-check routing
- Railway proxy → container connectivity
- service networking configuration
- deployment/replica state
- stuck or corrupted project/service state
- account/workspace-level compute allocation
- region/runtime host allocation
- whether containers are actually entering the expected start command after preflight
- whether the container can bind/listen on Railway's assigned PORT
- why a fresh service in a fresh project reproduces the same behaviour
- why a trivial hello-world ASGI application also fails
Because the same failure occurs with a minimal application, on fresh services, and across separate projects, please escalate this to Railway infrastructure/runtime engineering rather than treating it as application debugging.
IMPORTANT PRODUCTION SAFETY
My existing production service is in:
Project: surprising-radiance
It currently serves:
DO NOT modify, redeploy, restart, delete, change variables, change domains, or otherwise alter surprising-radiance as part of this investigation.
The failed test projects/services can be inspected.
I intentionally have not attached a public domain to the replacement services.
Please tell me if you need:
- Railway account/workspace identifier
- project IDs
- service IDs
- environment IDs
- deployment IDs
- build/deploy logs
- Dockerfile
- railway.toml
- exact timestamps of failed deployments
I can provide these.
I am a paying Railway customer and currently cannot deploy the replacement production application because of this issue.
3 Replies
a month ago
Having looked into this, the issue appears to be in your application code or configuration rather than the Railway platform itself, which puts it outside what Railway support can resolve directly.
This is exactly the kind of problem the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.
Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.
- Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
- Keep it private and close the thread - Nothing becomes public. The thread closes, since this isn't something Railway support can take further.
Status changed to Awaiting User Response Railway • 27 days ago
a month ago
Subject: Service reports 0 GB memory limit and deployments terminate after preflight
I have two Railway services that behave differently at the infrastructure/resource level.
WORKING SERVICE:
- Service/project: unique-healing
- Railway metrics consistently report MEMORY_LIMIT_GB at approximately 1 GB.
- Application runs normally.
FAILING SERVICE:
- Service/project: oxxon-platform-rc2
- Railway metrics report MEMORY_LIMIT_GB = 0.000000 consistently throughout the deployment.
- Deployment starts and successfully completes the initial lightweight preflight step.
- Immediately afterwards, subsequent commands/process startup fail or terminate without the application successfully starting.
- Repeated deployments show the same behaviour.
The key observation is:
Working service:
MEMORY_LIMIT_GB ≈ 1 GB
Failing service:
MEMORY_LIMIT_GB = 0.000000 GB
This appears to be a Railway resource provisioning/configuration issue rather than an application error.
Please investigate:
- Why is MEMORY_LIMIT_GB reported as exactly 0.000000 for oxxon-platform-rc2?
- Does the service actually have a memory limit/allocation assigned?
- Is the container being provisioned with the correct memory and CPU resources?
- Is there a project/service-level resource configuration that is missing, corrupted, or stuck at zero?
- Can you compare the resource provisioning of oxxon-platform-rc2 with the working unique-healing service?
- If 0.000000 is only a metrics/telemetry value rather than the actual container limit, please confirm the real memory limit and investigate why processes terminate immediately after preflight.
I do not want to change application code or memory-optimize the application until the 0 GB resource reading is explained.
Please check the service's underlying resource allocation/provisioning and advise whether the service needs to be reprovisioned or have its resource limits reset.
Status changed to Awaiting Railway Response Railway • 27 days ago
a month ago
This still looks like an application-level problem, so Railway support can't take it further, but the community can. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.
Status changed to Awaiting User Response Railway • 27 days ago
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 27 days ago