Deploying FastAPI on Railway
How I containerized a FastAPI optimization API, deployed it from GitHub to Railway, exposed `/solve`, and connected a separate frontend to the public endpoint.
This deployment serves an optimization backend from the public POST /solve endpoint. The API code lives in app/, the repository includes a Dockerfile, and Railway builds that container after each GitHub deployment. A separate frontend sends the model input to the public API URL and renders the solution.
I had already deployed FastAPI on ECS and Lambda. For this small, continuously available API, Railway reduced the amount of infrastructure I needed to operate while keeping the container boundary explicit.
From local process to public container
The deployment path is short, but every boundary is testable:
- Start
app.main:applocally withuvicorn app.main:app --reload. - Exercise
GET /,GET /docs, andPOST /solve. - Push the repository to GitHub.
- Let Railway detect the root
Dockerfileand build the image. - Generate a public domain and repeat the endpoint tests against it.
The OpenAPI page at /docs is especially useful here because it verifies request validation and the deployed route before the frontend is connected.
Runtime and cost are deployment settings
Railway can stop an idle service when serverless mode is enabled. That reduces compute usage for a demonstration API, but the first request after sleep can take longer. An always-active service removes that cold-start tradeoff and consumes resources continuously.
My small instance was around $1 per month at the time of measurement. That number is not part of the architecture and is not a forecast. Request volume, memory, CPU time, egress, plan rules, and current Railway pricing determine the real bill.
What I monitor after deployment
A successful build is only the first check. I use Railway's service view to inspect application logs, CPU, memory, restarts, and resource estimates. I then call /docs and /solve from outside Railway so the test covers the public domain, TLS termination, container process, FastAPI validation, and solver response.
Connect the frontend through configuration
The frontend should not contain a hard-coded production hostname. It reads the solver endpoint from an environment variable:
NEXT_PUBLIC_API_URL=https://your-railway-domain/solve
For local development, the same client can target:
http://127.0.0.1:8000/solve
This keeps frontend builds environment-specific without changing application code. If you adapt the project, update the request schema on both sides and configure FastAPI CORS for the exact frontend origins you deploy.
What this project demonstrates
The useful part of this example is the complete connection between a model, an HTTP contract, a reproducible container, a public runtime, and a separately deployed frontend. Railway removes several infrastructure steps, but the deployment still depends on correct process binding, environment configuration, CORS, endpoint validation, logs, and cost monitoring.
Inspect or reuse the deployment
- Open the FastAPI backend on GitHub to inspect
app/,Dockerfile, dependencies, and the/solveimplementation. - Open the frontend on GitHub to see how the client calls the API.
- Run the live optimization demo and inspect the request through your browser's network panel.
- Read the PostgreSQL deployment guide for the database side of the platform.
- Start Railway with $20 in credits if you are eligible. The referral link does not increase your price.