Why Your Cloud Bill Tripled Last Sprint (And How to Fix It)

The cloud billing model that sounds reasonable in the sales deck — "pay only for what you use" — has a hidden failure mode. It punishes sprints.

Picture this: your team just finished planning. Three engineers, two weeks, heads-down building. Everyone's pushing branches, opening PRs, spinning up preview environments so the designer and PM can click through real running code. The sprint goes well. Velocity is up. Morale is high.

Then the invoice lands and your DevTools line item tripled. The month your team was most productive was also the month your bill was highest. That's not a coincidence — it's a structural consequence of how usage-based pricing interacts with development workflows.

The math nobody shows you

Railway's pricing is per-resource, per-second. The numbers are public: $0.000772 per vCPU-second and $0.0000155 per MB of memory per second. A single container with 1 vCPU and 512 MB of memory costs roughly $2.78 per hour in compute and another $28.57 per hour in memory — call it about $31 per container-hour.

Now model a three-engineer team during a normal two-week sprint. Each engineer has two or three active branches at any time — feature work, a bugfix, maybe a refactor that's been sitting open since last week. Conservatively, that's 2.5 preview containers per engineer, or 7.5 containers running simultaneously.

If those containers run for the 8-hour workday and get shut down overnight (a best-case scenario most teams don't bother configuring), you're looking at:

7.5 containers × 8 hours × 20 working days = 1,200 container-hours per month

At roughly $31 per container-hour for a modest 512 MB preview, that's about $37,000 per month.

Let that sink in. A three-person team, doing nothing unusual — just shipping code like every startup does — could burn a bill that's larger than their combined office rent.

Even if you provision smaller containers (256 MB, which is tight for most real backends), or if containers sit idle much of the day (which they do — but you're still paying for them), a realistic range for a 3-engineer team on Railway is $300–$500 per month just for previews. That's before production hosting, before databases, before egress.

Compare that to flat pricing: $19/month for 5 concurrent previews, $79/month for 15 concurrent previews. Same number of engineers, same number of branches, same sprint — $19. Knowable before the month starts.

The sprint problem

Usage-based pricing is perverse for development tooling because your usage goes up exactly when your team is performing well.

More PRs equals more previews, which equals a higher bill. Ship a big feature that takes two weeks and generates 12 PRs? Bill goes up. Run a cleanup sprint with 20 small PRs? Bill goes up. Hire a fourth engineer and velocity increases? Bill goes up.

For production hosting this alignment is fine — more users means more traffic, which means more revenue, so a scaling bill tracks a scaling business. For a dev-tool like preview environments, it's backwards. You're not getting more users or more revenue during a sprint. You're getting the same number of users and the same amount of revenue, but your infrastructure cost just doubled because your team is doing their job.

The result is a quiet, corrosive incentive: engineers start thinking twice before pushing a branch. PMs stop asking for previews because someone mentioned the bill. Designers go back to waiting for staging deploys. The tool that was supposed to speed up review cycles ends up discouraging them — not by design, but by pricing.

This isn't theoretical. We've talked to teams who turned off Railway's PR previews specifically because the bill tripled during a sprint cycle. One lead told us: "We loved the feature. We just couldn't justify the invoice to finance."

What flat pricing actually buys you

When the price is fixed per workspace — $19/mo for Starter, $79/mo for Pro — something important changes: the price stops being a variable in the engineering equation.

Ten engineers pushing fifteen preview branches on a deadline week? Same $79. A junior engineer who leaves a preview running over the weekend because they forgot to close their PR? Same $79. The sprint where everything breaks and you spawn previews for twelve debug branches? Same $79.

The finance team never asks why DevTools spend tripled because it never triples. Engineers never weigh "is this PR worth a preview" because the answer is always yes — the marginal cost is zero. The conversation goes from "should we spin up a preview for this?" to "the preview is already up, here's the link."

Flat pricing also eliminates the forecasting game. With usage-based billing, nobody knows what the bill will be until it arrives. The CTO guesses, the finance team budgets a range, and everyone hopes they're close. With flat pricing, the number is on the pricing page. You put it in the spreadsheet once and you're done for the year.

When usage-based is the right answer

This isn't an argument against usage-based pricing everywhere. It's an argument about where it belongs.

For production hosting that scales with user traffic, usage-based pricing aligns incentives correctly. More users means more requests, more requests means more compute, and the bill grows in proportion to the business. Railway is genuinely a great general-purpose PaaS for production workloads — fast deploys, sensible defaults, good DX. If you're hosting your production API on Railway and paying for traffic-based scaling, that's a healthy dynamic.

The problem is specific to development tooling. When the thing you're using bills by the second and your team's output is measured in branches, not users, the pricing model punishes exactly the behavior you want to encourage.

Preview environments are ephemeral by nature. They spin up, serve three review cycles, get merged, and disappear. They're worth building, worth using, and worth paying for — but they're not worth $300/mo for a small team when a flat alternative exists.

The same logic applies to Render's preview environments, which are similarly per-resource. It applies to any platform where the pricing curve slopes up during your most productive weeks. If you're evaluating a preview tool and the calculator has a "per second" column, do the math for a busy sprint before you commit.

PreviewDrop is $0 to start, flat from there

We built PreviewDrop for exactly this reason. The free tier gives you 2 concurrent previews across 3 projects — no credit card, no trial expiration, no surprise invoice. When you need more, the Starter plan is $19/month per workspace for 5 concurrent previews and 3 team members. Pro is $79/month for 15 concurrent previews and 10 team members. No per-seat fees, no per-preview metering, no usage-based billing.

If your app has a Dockerfile, you push a branch and get a live URL. PR comments, commit status checks, password protection, automatic cleanup on merge — all included. The price doesn't change when your team ships faster.

See the full breakdown on the Pricing page, or read how we compare to Railway head-to-head on the PreviewDrop vs Railway comparison.

Start free with GitHub →