Railway scaling is per-second metering on CPU and memory — the team pays for the actual usage, not the provisioned size. The right answer is vertical scaling (bigger instance) for a single-service app that needs more CPU or memory, horizontal scaling (more instances) for a multi-service app with independent scaling, autoscaling (variable instance count) for a workload with variable traffic. The mistake every team makes: the team over-provisions from the start and pays for capacity they do not use.
Table of contents
- The per-second metering — pay for what you use
- The vertical scaling — bigger instance
- The horizontal scaling — more instances
- The autoscaling — variable instance count
- The cost calculation — the actual monthly bill
- The free tier — $5/month of usage
- The right scaling strategy for each workload
- How this fits the rest of the stack
- FAQ
The per-second metering — pay for what you use
Railway’s pricing is per-second metering. The team’s service uses X vCPU-seconds and Y GB-seconds per month, the team is billed for X * vCPU_price + Y * GB_price. The right answer is to start with a small instance (0.5 vCPU, 512 MB) and scale up as the usage grows. The wrong answer is to start with a large instance (8 vCPU, 16 GB) and pay for capacity the team does not use.
The gotcha: the per-second metering means the cost is predictable for a stable workload, but the team that has a workload with spikes (a black-Friday e-commerce site, a product launch) needs to plan for the spike. The right answer is to set the upper limit on the autoscaling, not to over-provision for the spike.
The vertical scaling — bigger instance
Vertical scaling is increasing the CPU and memory of a single instance. The right answer is vertical scaling for a single-service app that needs more CPU or memory (a CPU-bound image processing pipeline, a memory-heavy caching layer). The right answer is to scale up by 0.5 vCPU at a time, the wrong answer is to scale to 8 vCPU on day one.
The horizontal scaling — more instances
Horizontal scaling is increasing the instance count. The right answer is horizontal scaling for a stateless service that can run in parallel (a web API, a worker, a queue consumer). The right answer is to add one instance at a time and watch the latency. The wrong answer is to add 10 instances on day one — the team is paying for the cost, and the team does not know if the service actually scales linearly.
The autoscaling — variable instance count
Railway’s autoscaling scales the instance count based on CPU utilization. The team sets a target CPU (e.g., 60%), the autoscaler adds instances when the CPU exceeds the target and removes instances when the CPU drops. The right answer is autoscaling for a workload with variable traffic (a marketing site with a viral spike, a SaaS dashboard with peak hours). The wrong answer is autoscaling for a steady-state workload — the team is paying for the autoscaling overhead (the scaling decisions) without the benefit.
The cost calculation — the actual monthly bill
The cost of a Railway service is instances * vCPU * seconds * vCPU_price + instances * GB * seconds * GB_price. For a small service (0.5 vCPU, 512 MB) running 24/7 for a month, the cost is roughly $5-10/month. For a medium service (2 vCPU, 4 GB) running 24/7, the cost is roughly $40-80/month. The right answer is to start small, monitor the actual usage, scale up as the usage grows.
The free tier — $5/month of usage
The Hobby plan is $5/month of usage. The right answer is the free tier for a team’s first project, a low-traffic app, or a personal project. The right answer for a production app is the Pro plan ($20/month + usage). The wrong answer is to start on the Pro plan before the team has a clear sense of the usage.
The right scaling strategy for each workload
The right answer is a function of the workload:
- Steady-state web API — vertical scaling, no autoscaling.
- Variable-traffic web API — vertical scaling + autoscaling on CPU.
- Background worker with bursts — vertical scaling, no autoscaling (the worker drains the queue, then idles).
- Stateless API with spikes — horizontal scaling + autoscaling on CPU.
- CPU-bound batch job — vertical scaling, scheduled run, no autoscaling.
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
How does Railway’s pricing work?
Per-second metering on CPU and memory. The team pays for the actual usage, not the provisioned size.
Is Railway cheaper than Render?
For variable workloads, yes — the per-second metering means the team only pays for what they use. For steady-state workloads, Render’s flat-rate pricing may be cheaper.
Does Railway support autoscaling?
Yes — the autoscaler scales the instance count based on CPU utilization. The team sets a target CPU, the autoscaler adds/removes instances.
What is the right instance size for a small service?
0.5 vCPU, 512 MB. The right answer is to start small and scale up as the usage grows.
How do I monitor my Railway usage?
The dashboard’s Usage tab shows the CPU and memory usage per service. The right answer is to check the usage weekly, scale up the instances that are consistently high.
What happens when a Railway service hits the memory limit?
The service restarts. The right answer is to set the memory limit above the actual usage, the wrong answer is to set the memory limit to the actual usage — the team is one memory spike away from a restart loop.
How do I add a database to Railway?
Add a Postgres service to the project, the team gets a DATABASE_URL variable. The right answer is the managed Postgres for a team that does not want to operate a database.
Can I use Railway for a SaaS app?
Yes — Railway is the right answer for a SaaS app with a web API, a database, and a worker. The per-second metering means the team only pays for the actual usage.