Model notes · July 18, 2026
How we turn peak users into a Railway estimate
The calculator is a transparent starting hypothesis for a solo founder—not a quote and not a substitute for measuring the application. This page publishes every assumption so it can be criticized, replaced, and tested.
What “users/hour” means
One user is one modeled visit or product session arriving during the busiest hour. It is not a registered account or a monthly active user. We convert that peak into a month using an active-hours window and an average-to-peak ratio for each product shape.
The four starter workloads
These are deliberately small, legible scenarios for common Railway projects. The request counts and CPU times are assumptions, not industry averages. Their job is to make a first estimate falsifiable before a repository has been profiled.
Landing or portfolio
Most work is cacheable page delivery plus a small CMS and lead form. CPU stays close to the service baseline; public origin bytes become the first meaningful cost driver. Browser caching—and an external CDN when one is present—can lower this curve substantially.
- 1k users/hour
- $20.00
- 10k users/hour
- $47.77
SaaS application
A session combines authentication, API reads, mutations, and retained database state. CPU grows with completed request work, while memory steps up when peak CPU calls for another application replica. This is the balanced profile: no single resource is assumed to do all the scaling.
- 1k users/hour
- $20.00
- 10k users/hour
- $66.28
Online store
Catalog, search, cart, and checkout make this the busiest origin workload. Product media pushes public egress first, while transactional request work adds replicas earlier than the other profiles. Moving media away from the app origin changes this estimate materially.
- 1k users/hour
- $36.04
- 10k users/hour
- $251.84
AI application
This profile assumes model inference stays with an external provider. Railway carries the streaming application, session state, and queueing—not the model itself. Long-lived sessions add memory pressure, while token and inference charges remain outside the chart.
- 1k users/hour
- $20.00
- 10k users/hour
- $32.72
| Product | Origin requests/user | CPU ms/request | Active min/user | Origin MB/user | Retained KB/user |
|---|---|---|---|---|---|
| Landing | 4 | 12 | 3 | 0.55 | 0.5 |
| SaaS | 18 | 22 | 10 | 0.75 | 2.5 |
| Store | 28 | 28 | 9 | 2.4 | 5 |
| AI app | 10 | 20 | 7 | 0.3 | 4 |
| Product | Active hours/day | Average / peak | Replica CPU target | Replica memory |
|---|---|---|---|---|
| Landing | 12 | 45% | 0.65 vCPU | 0.2 GB |
| SaaS | 8 | 55% | 0.65 vCPU | 0.35 GB |
| Store | 10 | 60% | 0.6 vCPU | 0.5 GB |
| AI app | 8 | 55% | 0.6 vCPU | 0.45 GB |
How the curves are calculated
CPU, stored data, and public transfer grow with completed work. Memory also changes when peak CPU requires another replica, so its curve has visible steps. We do not invent a nonlinear “scaling penalty”: queueing, database saturation, cache misses, and slow dependencies are application-specific and belong in a load test.
- Monthly sessions
peak users/hour × active hours/day × 30 × average-to-peak ratio- CPU
origin requests/second × CPU seconds/request, averaged over the monthly traffic shape- Concurrent users
users/second × active session duration- Memory
base working set + replica steps + concurrent-user working set- Disk
base volume + monthly sessions × retained KB/session- Egress
monthly sessions × public origin MB/session
Concurrency uses Little’s Law: arrival rate multiplied by time in the system. For memory we apply it to active product sessions, then add the base working set and replica working sets.
What comes from public data
Railway publishes usage prices of $20.00/vCPU-month, $10.00/GB-month, $0.15/GB-month for volumes, and $0.05/GB for public egress. The calculator uses that snapshot exactly.
The 2025 HTTP Archive reports median home-page weight of roughly 2.6 MB on mobile and 2.9 MB on desktop. Our public-origin assumptions are lower because navigation within a session can reuse the browser cache, and some projects add an external CDN. The chosen cache effect is a scenario assumption, not a measured universal hit rate.
What the estimate leaves out
LLM tokens, object storage, third-party APIs, taxes, and provider-specific database plans are excluded. A real application may do more work per user, keep data longer, miss its cache, leak memory, or hit a database limit long before the modeled CPU target.
That is the boundary between the calculator and CapacityLab: the calculator supplies a reviewable hypothesis; a repository profile and controlled run replace assumptions with observed request mixes, resource series, bottlenecks, and a signed capacity decision.
Try the model