Node.js on Railway
Railway publishes its own guide for deploying Node.js.
JavaScript runtime used to run servers and build tooling outside the browser.
What Node.js needs.
Every host claims to run Node.js, so the claim on its own decides nothing. These are the things Node.js actually requires from the platform underneath it, and what Railway publishes about each. Railway documents 4 of the 4.
Persistent processes
Supported
A long-running process is the point: WebSocket connections, in-memory caches and job queues all die with it. A host that only runs functions cannot keep one alive.
Sources (1) →Sources ↓
- Services — Railway Docs ↗
“Types of services Persistent services Services that are always running. Examples include web applications, backend APIs, message queues, database services, etc.”
Read 2026-09-13 · official docs
Max request duration
15 minutes while data keeps transferring; closed after 5 minutes with no data transferred. Websocket connections are exempt and can stay open indefinitely.
Anything the process does inside a request — a large upload, a slow query, a streamed response — is bounded by this ceiling.
Sources (1) →Sources ↓
- Specs & Limits — Railway Docs ↗
“HTTP requests can run for up to 15 minutes if data keeps transferring (for example, keep-alive heartbeats), and are otherwise closed after 5 minutes with no data transferred. [...] Websocket connections are exempt from these duration and inactivity limits, and can stay open indefinitely, even while idle.”
Read 2026-09-05 · official docs
Docker deployment
Supported
Node apps routinely need a system binary the platform's buildpack does not ship. A Dockerfile is the escape hatch when they do.
Sources (1) →Sources ↓
- Railway Dockerfiles ↗
“Use a Dockerfile to instruct Railway how to build a service.”
Read 2026-09-05 · official docs
Scales to zero
Limited — Serverless sleeps an idle service, but a slept service still holds a slot and is de-prioritised.
An always-on process bills while idle. Scaling to zero removes that cost and adds a cold start to the next request instead.
Sources (1) →Sources ↓
- App Sleeping — Railway Docs ↗
“The first request made to a slept service wakes it. [...] For Railway to put a service to sleep, a service must not send outbound traffic for at least 5 minutes. [...] Slept services still consume a slot on Railway's infrastructure, enabling Serverless de-prioritizes your workload”
Read 2026-09-13 · official docs
What Railway documents.
Railway publishes its own guide for deploying Node.js.
In this guide, you'll learn how to deploy a Node.js and Express.js API to production using Railway.
Sources (1) →Sources ↓
- Deploy Node.js & Express API with Autoscaling, Secrets, and Zero Downtime | Railway Guides ↗
“In this guide, you'll learn how to deploy a Node.js and Express.js API to production using Railway.”
Read 2026-09-05 · official docs
Node.js features on Railway
Capabilities Railway documents specifically for Node.js, with the constraint it documents alongside each.
websockets
Supported
Support for websockets over HTTP/1.1. [...] Websocket connections are exempt from these duration and inactivity limits, and can stay open indefinitely, even while idle.
background_workers
Supported
A background worker is an always-on service that processes work continuously. Unlike a cron job, it does not exit after completing a task. [...] On Railway, deploy a worker as a separate service in the same project as your API.
ssh_shell_access
Supported
Open an interactive shell session inside a deployed Railway service container, or manage the SSH keys registered with your Railway account.
Sources (3) →Sources ↓
- Specs & Limits | Railway Docs ↗
“Support for websockets over HTTP/1.1. [...] Websocket connections are exempt from these duration and inactivity limits, and can stay open indefinitely, even while idle.”
Read 2026-09-13 · official docs
- Choose Between Cron Jobs, Background Workers, and Queues | Railway Guides ↗
“A background worker is an always-on service that processes work continuously. Unlike a cron job, it does not exit after completing a task. [...] On Railway, deploy a worker as a separate service in the same project as your API.”
Read 2026-09-13 · official docs
- railway ssh | Railway Docs ↗
“Open an interactive shell session inside a deployed Railway service container, or manage the SSH keys registered with your Railway account.”
Read 2026-09-13 · official docs
What it costs to run there.
- Entry paid plan
- $5 / month (Hobby)
- Pricing model
- A base subscription fee that goes towards usage, with the plan's own credit included; anything beyond the credit is billed as resource usage.
- When you exceed a cap
- Billed automatically: on the Hobby plan ($5/month, includes $5 of resource usage) usage above the included amount is charged as a delta on top of the subscription — no throttling or suspension is documented
- Regions
- 4 regions: California, Virginia, Amsterdam, Singapore
Sources (3) →Sources ↓
- Plans — Railway Docs ↗
“Plan Price Free $0 / month Hobby $5 / month Pro $20 / month Enterprise Custom”
Read 2026-09-13 · official pricing
- Pricing Plans | Railway Docs ↗
“If your total resource usage exceeds $5 in any given billing period, you will be charged the delta”
Read 2026-09-05 · official docs
- Regions — Railway Docs ↗
“Name Location Region Identifier US West Metal California, USA us-west2 US East Metal Virginia, USA us-east4-eqdc4a EU West Metal Amsterdam, Netherlands europe-west4-drams3a Southeast Asia Metal Singapore asia-southeast1-eqsg3a”
Read 2026-09-13 · official docs
Whether it suits you.
Teams that want a plan fee which doubles as usage credit, and deploy services straight from a Dockerfile without managing servers. The $5 Hobby fee comes back as $5 of resource usage.
Consider something else if…
You need to run in a region outside California, Virginia, Amsterdam or Singapore.
Visit Railway documentation