Railway Hosting: How Deployments, Environments and Pricing Work

What Railway is and how a project is organised

Everything on Railway lives in a project. Railway's basics guide describes a project as a capsule for composing infrastructure, comparable to an application stack, and every service inside a project is automatically joined to a private network scoped to that project.

A service is the deployment target. Its source is a code repository or a Docker image; when the source is a repository, Railway analyses it, builds a Docker image and deploys it to the service. Each service carries its own variables, metrics and settings, and its variables are not shared with other services unless you use a reference variable. A deployment is the built, deliverable unit of a service, and a volume is the persistent storage you attach to one.

The dashboard draws each project as a canvas, and the homepage notes that you can edit settings directly on it, with YAML optional. Railway's own comparison with Render contrasts that collaborative canvas with Render's traditional dashboard listing resources. If Render is on your shortlist too, the iThub guide to Render hosting services, limits and costs covers the other side of that decision.

How Railway deployments work

There are three ways to get code running on Railway:

• GitHub autodeploys. Services linked to a GitHub repository deploy automatically when new commits are pushed to the connected branch. An optional Wait for CI setting holds each deployment until your GitHub Actions workflows finish, and a failed workflow skips the deployment.
• Docker images. In the service settings, the source can be a GitHub repository with a specific branch or an image with optional registry credentials.
• The Railway CLI. The railway up command scans, compresses and uploads your project files and streams the build and deploy logs to your terminal. For CI pipelines, project tokens are scoped to one environment and can only perform deployment actions.

Builds: Railpack or your Dockerfile

When Railway builds from source, Railpack detects the language, installs dependencies and sets build and start commands without manual configuration. If the repository already contains a Dockerfile, Railway uses it automatically. Builds are not billed: the plans documentation states that Railway does not charge for build CPU, memory, base-image downloads, image exports or image storage. Build time is capped by plan, at 10 minutes on Free after the trial, 40 minutes on Hobby and 90 minutes on Pro.

Healthchecks, rollbacks and configuration files

A healthcheck endpoint gives you zero-downtime deploys: Railway queries it until it gets a 2xx response before the new deployment becomes active, with a default timeout of 300 seconds. Railway does not keep monitoring that endpoint once the deployment is live, so uptime monitoring is a separate job. A service with a volume still has a short downtime on every redeploy, because Railway prevents two deployments from mounting the same volume.

Railway keeps images of removed deployments for a retention period, so rolling back within that window restores the previous image, settings and variables without a rebuild.

If you keep settings in your repository, note the timing: Config as Code (railway.json or railway.toml) is deprecated in favour of Infrastructure as Code in .railway/railway.ts. Existing files keep working only until a hard cutoff on 2026-12-01, and new services cannot opt in to the old format.

Environments and PR preview environments

Railway environments are isolated instances of all the services in a project. Every project starts with a production environment, and a change to a service applies to one environment only. There are two kinds:

1. Persistent environments, such as a staging environment that auto-deploys from a staging branch with its own variables.
2. PR environments, created when a pull request is opened and deleted when it is merged or closed. You switch them on in Project Settings, under Environments.

For monorepos, Focused PR Environments deploy only the services affected by the files changed in the pull request. A separate toggle creates PR environments for bot pull requests, including Dependabot and Renovate. Railway will not deploy a PR branch from a user who is outside your workspace and not invited to the project.

Preview environments are not free. The billing guide points out that each PR environment runs real services, so five open pull requests can mean five times your normal workload. Environment RBAC, which hides production variables, logs and services from non-admin members, is an Enterprise feature.

Databases, volumes and storage on Railway

Railway maintains database templates for PostgreSQL, MySQL, Redis and MongoDB: it provisions them and ships security patches for their images. High availability, backups, point-in-time recovery (PostgreSQL and MySQL) and connection pooling (PostgreSQL) are switched on from the dashboard. Railway is clear about the boundary: schema, queries and data are always yours, alerting on database metrics is yours to set up, and Railway does not publish an uptime SLA for databases today. Any other database can run from a Docker image.

Databases and other stateful services store data on volumes. Points to check before relying on them:

• Volumes are mounted when the container starts, not at build time and not during the pre-deploy command.
• Railway's build places your app in /app, so an app that writes to ./data needs the volume mounted at /app/data.
• Paid plans can resize a volume live without downtime; a volume at 100% capacity gets an offline resize that restarts the service.
• Volume storage is capped by plan: 0.5 GB on Free, up to 5 GB on Hobby, up to 1 TB on Pro and up to 5 TB on Enterprise.

Volume backups are incremental and copy-on-write, and Railway only charges for the data exclusive to a backup.

Networking, regions and scaling

Services in the same project talk over private networking: encrypted WireGuard tunnels with internal DNS names in the form SERVICE_NAME.railway.internal, and each environment gets its own isolated network. Private traffic also matters for cost, because an app that reaches its Railway database through the public URL pays egress on all of that traffic.

Railway lists four deploy regions: US West (California), US East (Virginia), EU West (Amsterdam) and Southeast Asia (Singapore). You can change a service's region without downtime unless it has a volume attached; then the volume has to migrate, and the service is down while it moves.

For scaling, Railway lets a service use resources up to the vCPU and memory limits of your plan, and you scale horizontally by raising the replica count in the service settings. On Pro, each replica can use up to 24 vCPU and 24 GB of memory. Replicas can sit in different regions; Railway routes public traffic to the nearest region, then distributes requests randomly among the replicas there. Sticky sessions are not supported.

How Railway pricing works

Railway bills in two parts: a subscription that works as a minimum commitment, and resource usage. In the words of the billing guide, the $5 Hobby or $20 Pro fee covers your first $5 or $20 of resource usage each month, and you pay the difference only when usage goes over. Included usage resets every billing cycle and does not roll over.

Resource rates on the plans page:

• RAM: $10 per GB per month
• CPU: $20 per vCPU per month
• Network egress: $0.05 per GB
• Volume storage: $0.15 per GB per month

The pricing page shows the same compute rates per second ($0.00000386 per GB of memory, $0.00000772 per vCPU) and lists object storage at $0.015 per GB-month with free egress. The worked example in the docs: on Hobby, $3 of usage produces a $5 bill, and $7 of usage produces a $7 bill. At these rates, a service that keeps 1 GB of RAM allocated for a full month accounts for about $10 of memory before any CPU.

Free trial and Free plan

New accounts start on a free trial that lasts up to 30 days with a one-time $5 grant, and no credit card is needed to sign up. After 30 days, or once the $5 is spent, the account reverts to the Free plan with $1 of credit per month. If Railway cannot verify your GitHub account, you land on a Limited Trial with restricted outbound network access and a limited set of ports. Railway deletes stateful volumes created by trial accounts 30 days after the credits expire.

Why an idle app still costs money

Railway bills allocated resources, not traffic: a running service consumes CPU and RAM whether or not it is handling requests. Two settings reduce that. Serverless, formerly called App Sleeping, stops a service once it has sent no outbound traffic for 5 minutes; the trade-off is a cold start, and the first request may return a 502. Usage limits let you set an email alert and a hard limit. At the hard limit Railway takes all workloads offline, so set it as a ceiling, not as a budget.

Railway limits to check before you commit

The pricing page feature table lists these plan limits:

• Custom domains None on Free after the trial, 2 on Hobby, 20 on Pro.
• Log retention 7 days on Hobby, 30 days on Pro, 90 days on Enterprise.
• Availability targets 99.9% on Hobby and 99.99% on Pro; these are targets, and databases have no published uptime SLA.
• Team size Hobby is a single developer workspace; Pro includes unlimited workspace seats.
• Payment Credit cards for subscriptions and usage; invoices only on Enterprise.
• Compliance features HIPAA BAAs start at a $1,000 monthly spend commitment, and SSO, role-based access and longer audit logs at $2,000.

Add the platform behaviours covered above: no sticky sessions, healthchecks only at deploy time, and downtime on redeploys and region moves for services with volumes. Enterprise adds dedicated VMs and a bring-your-own-cloud option.

Who Railway fits, and who should look elsewhere

Railway suits developers and small teams who want a git-push workflow with per-second billing, and projects made of several services (an app, a worker, PostgreSQL, Redis) on one private network. Cron services fit too, since scheduled services only bill for the time they run.

It fits less well if finance needs a fixed monthly invoice; Railway's Render comparison frames the difference as resource-usage billing against instance tiers. It is also a weaker match if you need a database SLA without Enterprise, sticky sessions, or regions beyond the four listed.

To evaluate it, deploy a real service on the trial with GitHub connected, set a usage alert and hard limit on day one, and read your first invoice against the rate list. Railway's tool profile on iThub and the wider PaaS and app deployment category list alternatives to compare against.