Render's April 2026 repricing: no more per-seat fees, a lot less included bandwidth

On April 23, 2026, Render replaced its per-seat pricing with a flat workspace fee: $0 a month for Hobby, $25 a month for Pro, $499 a month for Scale, confirmed directly on Render’s own pricing announcement. Existing workspaces had until August 1, 2026 to move onto the new plans. In the same change, Render cut the bandwidth included with those plans substantially, Hobby’s included egress dropped from 100GB to 5GB, and reporting on the change describes a comparable cut on Pro, with overage now billed at a flat $0.15 per gigabyte instead of the old practice of billing in 100GB blocks. Render’s own announcement states that 75% of paying customers would see their bill decrease or stay the same under the new structure. For a specific, common kind of workload, though, the math runs the other way, and it’s worth working through exactly why.

What actually changed, in Render’s own words

The headline change is the one Render chose to lead with: no more per-seat fee. Under the old model, a Pro workspace paid somewhere in the range of $19 to $29 per team member per month, meaning a five-person team’s base platform fee alone could run $95 to $145 before a single service was even running. Under the new model, that’s replaced with one flat fee per workspace, $25 a month for Pro, regardless of whether the workspace has one person or twenty. For any team bigger than a solo developer, that part of the change is a straightforward improvement, and it’s the part that justifies Render’s own claim that most paying customers come out ahead or flat.

The second change got much less top billing: included bandwidth per plan dropped sharply. Hobby’s egress allowance fell from 100GB to 5GB, a 20x cut. Reporting on the Pro plan describes a similarly steep reduction, down to 25GB included, with the specific prior allowance reported inconsistently across coverage of the change (some accounts put the old Pro allowance at 100GB, others higher), so the exact “before” number is worth treating as reported rather than independently confirmed here. What’s consistent across every account, including Render’s own current plan pages, is the after number: 25GB included on Pro, 1TB on Scale, and a flat $0.15 per gigabyte for anything over the included amount.

Why did Render cut included bandwidth and drop per-seat fees?

These two changes look unrelated but they’re not. A per-seat fee is a bill that scales with how many people use the product, which has almost nothing to do with how much it costs Render to actually run a customer’s infrastructure. Egress, the data a running app sends back to its users, is a real, metered cost Render itself pays to its own upstream providers, and it scales with exactly one thing: how much traffic a customer’s app actually serves. Moving from “charge per person” to “charge per gigabyte actually used” is, mechanically, a move toward billing closer to Render’s own real cost structure, and away from a number (team headcount) that was only ever a rough proxy for usage.

That’s a coherent business reason to make the change, and it’s consistent with Render’s broader trajectory: the company raised $100 million in February 2026 at a reported $1.5 billion valuation on more than 100% year-over-year growth, which is a funding story that depends on a cost structure that scales predictably with usage rather than one where a handful of high-traffic customers quietly subsidize themselves on a flat seat-based plan priced for a different kind of workload. None of that makes the change a bad one on its merits. It does mean the customers most exposed to the downside are a specific, identifiable group: workloads with real sustained bandwidth, video, file downloads, API responses with large payloads, webhooks firing at volume, that previously fit comfortably inside a generous flat allowance and now hit a meter.

What this costs for an actual workload

Take a fairly ordinary Pro-tier setup: one web service, one background worker, both on a standard instance size, plus a small managed Postgres database. Before egress is counted at all, that’s roughly $95 a month under the new pricing, workspace fee included. At low traffic, under the 25GB included allowance, that’s the whole bill, and it’s a real improvement over the old per-seat Pro pricing for a team of more than one or two people.

The number moves fast past that point. At 500GB of monthly egress, a reasonable number for an app serving images, video thumbnails, or a modest amount of API traffic to a few thousand users, the overage is 475GB past the included amount, at $0.15 a gigabyte that’s roughly $71 added to the base, for a total near $166 a month. At 1TB of monthly egress, the overage climbs to around $150, pushing the total past $245. At 2TB, a workload that isn’t unusual for a media-heavy consumer app, the egress line alone approaches $300, more than triple the base platform fee. The pattern is straightforward: bandwidth, not compute or the workspace fee, becomes the dominant line on the invoice for anything beyond a lightly-trafficked app, and it keeps climbing with no ceiling until a customer moves to the $499 Scale plan and its 1TB allowance.

The part worth sitting with is that none of this requires a team making an unusual choice. Serving video, images, large JSON payloads, or just having a popular app, isn’t exotic behavior; it’s a large share of what web applications actually do. A pricing model that is friendlier to small teams on headcount and meaningfully less friendly to anyone with real sustained traffic is a specific, intentional tradeoff, not a universal improvement, and Render’s own 75%-of-customers framing is consistent with that: it describes the median customer, not the tail of customers whose workloads are exactly the kind that generate real bandwidth.

What a flat price with no egress meter does differently

Railyard’s pricing has no bandwidth line at all, metered or otherwise. The $19-a-month Pro plan and $49-a-month Team plan are flat per team, regardless of how much traffic the apps on those servers actually serve. That’s possible for a structural reason, not a generosity one: the servers themselves live in the customer’s own cloud account, and bandwidth is billed by the cloud provider (DigitalOcean, Hetzner, Vultr) directly to the customer, at that provider’s own rate, which for most providers includes a meaningfully larger bandwidth allowance bundled into the price of the server itself, and historically does not carry anywhere near a $0.15-per-gigabyte marginal rate once a server’s own allowance is used. Railyard never touches that bill, has no markup on it, and has nothing to meter, because the traffic never passes through infrastructure Railyard owns in the first place.

This is the same architectural fork that shows up across every comparison between a managed platform and a BYO-server one: a platform that runs the compute has to price the resources it’s actually paying for, which for a bandwidth-heavy workload eventually means metering bandwidth, because that’s a real, variable cost the platform is absorbing on the customer’s behalf. A platform that doesn’t run the compute has no such cost to recover, so there’s nothing to meter. Neither approach is a trick. Render’s egress cost is real money Render pays somewhere upstream, and recovering some of that from the customers generating the traffic is a defensible, arguably more honest pricing decision than hiding it inside a flat fee that other customers end up subsidizing. The honest framing is that the two models are optimized for different workloads: a platform with metered egress is a fine, fair choice for a team with modest, predictable traffic that benefits from the lower seat-based cost; a flat per-team price with egress billed directly by the cloud provider is the better fit once traffic is large enough that a per-gigabyte meter would dominate the bill.

The actual lesson

Render didn’t do anything deceptive here. It published the change, gave a real transition window, and led with the part of the change that’s an unambiguous win for most customers. The part worth knowing before signing up, or before budgeting a renewal, is the part that didn’t get the headline: a workload with real, sustained bandwidth is now billed per gigabyte with no cap short of the next plan tier, replacing an allowance that for most of Render’s history was generous enough not to think about. Anyone running a bandwidth-heavy app on Render is worth doing the arithmetic for their actual traffic before assuming the new, friendlier-looking base price tells the whole story.

FAQ

When did Render change its pricing? Render moved to a flat workspace-fee model on April 23, 2026, with existing workspaces required to migrate by August 1, 2026.

How much bandwidth does Render include now? The new plans include 5GB on Hobby, 25GB on Pro, and 1TB on Scale, down sharply from the allowances in place before April 2026, with overage billed at $0.15 per gigabyte.

Did Render’s prices go up or down? Both, depending on the workload. Dropping per-seat fees lowers the bill for most teams, especially larger ones. Cutting included bandwidth raises the bill for any workload with real sustained traffic, since egress is now metered past a much smaller included amount.

Does Railyard charge for bandwidth? No. Railyard’s servers run in the customer’s own cloud account, so bandwidth is billed directly by the cloud provider at that provider’s rate, not metered or marked up by Railyard.

Sources

• Render: “Better pricing for fast-growing teams”, Render’s own announcement, checked October 2026, confirming the $0/$25/$499 workspace tiers, included bandwidth of 5GB/25GB/1TB, the $0.15/GB overage rate, and the 75%-of-customers claim
• Reporting on the April 2026 Hobby bandwidth cut, including Render’s April 2026 Egress Cut From 100GB to 5GB on Hobby
• Reporting on the business context behind the change, including Render’s February 2026 funding round, in Render’s $1.5B Valuation Hides a $0.15/GB Question
• Railyard’s own pricing page for current flat per-team plan details

See how the models compare directly: Compare Railyard to Render, or see how Railyard’s flat pricing works on servers you already own.