Railway for persistent backends.
When the workload needs a long-running process, persistent connections, or a container that stays alive, Railway hosts it.
railway.com ↗Railway handles the backend workloads that don't fit the serverless model. WebSocket servers, background job processors, real-time communication services, and AI agent runtimes all need processes that stay alive between requests. Railway gives us container-based hosting with automatic deploys from git, built-in databases, and straightforward scaling. We use it alongside Vercel: the frontend and API routes deploy on Vercel, and long-running backend services deploy on Railway. Each platform handles what it does best.
Railway is the simplest path from a Dockerfile to a running service. No Kubernetes configuration, no infrastructure-as-code boilerplate, no multi-step CI pipeline. Push to git, it deploys. Need a Postgres database? Click a button. Need Redis? Same. For the backend services that don't fit into serverless functions (WebSocket servers, background workers, AI agent processes), Railway provides the persistent compute without the operational overhead of managing EC2 instances or container orchestration.
Railway hosting for production backends
Railway hosting is where we put the parts of an application that need to stay running. A serverless function spins up, answers one request, and dies, which is perfect for an API route and wrong for a WebSocket server, a background worker, or an AI agent that holds state across a conversation. Railway gives those workloads a real container that stays alive, deployed straight from a Dockerfile or Nixpacks with no Kubernetes to babysit. For production we lean on what makes it boring in the best way: managed Postgres and Redis a click away, private networking between services, environment-based config, and logs and metrics in the same dashboard. We run it next to Vercel rather than instead of it (the front end and stateless API routes stay on Vercel's edge, and the long-lived processes live on Railway) so each side of the app runs where it actually belongs.
Railway vs serverless: when a process needs to stay on
The honest version of the serverless-versus-Railway question is that it is rarely either/or. Serverless is the right default: it scales to zero, costs nothing at idle, and handles bursty request-response traffic without any capacity planning. It falls down when a process needs to stay on: a WebSocket connection that lasts minutes, a job queue draining in the background, an AI agent maintaining context, or anything that exceeds a function execution-time limit. Those workloads want a persistent container, and forcing them into serverless means fighting cold starts, timeouts, and connection churn. Our rule is simple: if the work is a short reply to a request, it stays serverless on Vercel; if it needs to live between requests, hold a connection, or run continuously, it moves to a Railway container. Most production apps we ship end up with some of each, and Railway hosts the half that has to stay alive.
How we deploy on Railway
-
Containerize
We define the service in a Dockerfile or let Railway's Nixpacks detect and build it. Pinning the runtime and dependencies at the container level means the service runs identically in development, in a preview environment, and in production.
-
Connect
We link the git repository so every push triggers a build and deploy automatically. Pull requests get their own environments, so a backend change can be reviewed running live before it reaches production, the same workflow we use on the front end.
-
Provision
We add the managed pieces the service needs (Postgres, Redis, environment variables, and private networking between services) from Railway's dashboard instead of standing up and securing our own database servers. Secrets stay in environment config, never in the repository.
-
Scale and observe
We tune replicas and resource limits to real traffic, then watch logs and metrics in the same place to catch memory leaks, slow queries, or restart loops. Scaling is adjusting numbers, not re-architecting the deployment.
Real-Time Services
WebSocket servers and Socket.io backends for live chat, notifications, and collaborative features.
AI Agent Runtimes
Long-running AI agent processes that maintain state across conversations and need persistent connections.
Background Workers
Job queues, scheduled tasks, and data processing pipelines that run continuously outside the request-response cycle.
Systems we pair Railway with
Vercel
The other half of most of our deployments. Vercel hosts the front end and stateless API routes on its edge while Railway runs the persistent services, and the two talk over standard HTTPS and shared environment config.
Node.js
Most of the long-running services we put on Railway are Node: WebSocket servers, job processors, and webhook handlers. Railway builds them straight from the repository with no separate server to provision.
Python
For AI and data workloads we deploy FastAPI services and processing pipelines to Railway, where a Python process can hold model connections and run continuously instead of cold-starting on every request.
AWS
When a Railway service needs durable object storage or model inference, we reach into AWS for S3 and Bedrock while the compute itself stays on Railway. Each platform does the part it is best at.
Postgres
Railway's managed Postgres gives a service a production database in one click, with backups and private networking handled. We use it for app data that has to persist between deploys and restarts.
Redis
We add managed Redis on Railway for caching, session storage, rate limiting, and job-queue backends. Co-located with the service over private networking, lookups stay fast and never cross the public internet.
