2 hours ago
Hi, my FastAPI application in project marvelous-rebirth (production environment) is experiencing a critical issue where the container process is terminated before the application can start, resulting in 502 responses.
The Problem
After Alembic migrations complete successfully, the process is killed immediately before Uvicorn can start. There is zero output — no error, no signal, nothing. Just silence, then the container stops.
Evidence This Is a Platform Issue
I've ruled out every application-side cause:
1. Migrations work perfectly (confirmed via logs):
-DIAG: engine disposed, run_async_migrations complete
-DIAG: env.py module finished executing
-[process killed here — no Uvicorn startup, no logs after this point]
2. Identical code runs flawlessly locally:
-Same Docker image, built identically
-Same start command: alembic upgrade head && uvicorn app.main:app --host 0.0.0.0 --port 8000 --workers 1
-Same repo, same branch, same environment variables
-Works perfectly locally. Tested with hard memory cap at 512MB — still works.
3. Even a bare Uvicorn process (no app logic) fails identically on Railway:
-Confirmed it's not application code
-Confirmed it's not memory or resource constraints
-Confirmed it's not the Dockerfile or port config
Deployment Details
-Service: ai-interview-simulator
-Repo: olarip224/ai-interview-simulator (branch: master)
-Last working commit: b971717d89a5c830456b9d0151173efa105bf581
-Region: us-west2 (sfo)
-Replicas: 1
-HTTP Response: 502 Bad Gateway with "connection dial timeout"
What I Need
Please investigate why the process is being terminated silently without any error output. Since migrations complete successfully and the exact same image works locally, this appears to be a platform-level container/runner issue rather than an application problem.
This has been blocking development since early morning today (July 28, 2026).
1 Replies
2 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 2 hours ago
2 hours ago
The most likely cause is that Railway is killing the container because the start command never execs into a PID 1 foreground process. In your current command, alembic upgrade head && uvicorn ... runs both steps under the same shell process. When Alembic finishes, the shell may exit before Uvicorn properly takes over, especially if shell signal handling differs in Railway's runner. Locally it may work by accident, but Railway's container lifecycle can treat the shell as the PID 1 process and terminate it once the left-hand side of && completes.
A common fix is to ensure the final command is PID 1 in the container, or at least avoid relying on && chaining in the start command. Try one of these:
-
Move the migration into the application startup path, e.g. run migrations from Python before starting Uvicorn, so the start command is just a single foreground process.
-
If you must keep it in one command, use
execso Uvicorn replaces the shell:alembic upgrade head && exec uvicorn app.main:app --host 0.0.0.0 --port 8000 --workers 1 -
Or use a small entrypoint script that runs migrations and then execs Uvicorn.
Also check whether Railway has a "Run Command" override or a separate "Pre-deploy" field configured. If a pre-deploy command is set and the main start command exits after migrations, Railway can stop the container before Uvicorn binds the port.