The Ultimate PaaS Pricing Calculator

About this calculator

It’s no secret that we’re big fans of PaaS at Judoscale—we believe small teams should be spending their time building features, not servers.

But we also believe there’s no one-size-fits-all PaaS solution. There’s hot competition in the PaaS space today, and we’re here for it! We built this calculator as a tool to compare cloud hosting options.

To be clear, it’s not THE tool‚ it’s just A tool. We don’t recommend choosing a provider based on compute cost alone. But still, we find it super helpful to compare them side-by-side like this, and we hope you do too!

CPU cores

CPU cores are all about processing power, and each PaaS lets you dial in how much power you need. Shared CPU cores are cost-efficient but are susceptible to “noisy neighbors”, meaning performance is not always consistent.

Your app stack and configuration are important here—a Ruby background worker running the free version of Sidekiq, for example, can’t utilize more than a single CPU, so it’s wasteful to pay for more. When in doubt, start with a single CPU core and scale horizontally with instances/replicas.

Memory

If you know how much memory your service requires to run, dial it in here with adequate headroom. If you don’t know, 1 GB is usually a safe starting point for most apps, and you can always increase it later.

Instances

Each cloud provider has a different name for these: Dyno, Instances, Replicas, Nodes, Tasks… They’re all the same—copies of your service running in parallel, allowing you to process more web traffic or background jobs.

This is “horizontal scaling” in action, and it’s the secret to being cost-efficient with your PaaS. We recommend aiming low on your compute (CPU & memory) and leveraging horizontal scaling as much as possible. You can automate this later through autoscaling to maximize your efficiency.

Monthly egress

Some (but not all) providers charge for egress (outbound network bandwidth), and it can be an unexpected expense because it’s hard to estimate.

To get a very rough ballpark of your egress, estimate your average throughput in requests per second (RPS), multiply by your typical page size in KB, then multiply by 2.5. For example:

1 RPS * 100 KB * 2.5 = 250 GB

If you don’t know your page size, 100 KB is a reasonable estimate for HTML responses that assumes you’re using a CDN for assets like JavaScript and images. If your application is delivering your assets (no CDN), this number will be MUCH higher—likely several megabytes. If your application is mostly responding with JSON, your estimated page size is likely to be smaller.

Heroku

Heroku pricing notes:

• We’ve referenced Heroku’s team pricing, dyno costs, and dyno tech specs.
• There is no charge for team members.
• Teams above 25 members require a custom enterprise contract, so we can’t calculate a price.
• There is no charge for egress.
• Heroku does not publish CPU core counts for shared dynos, so shared CPU values are our estimates of effective compute.
• Heroku only has two compute tiers with shared CPU, so even with shared CPU selected, your CPU/memory requirements might push you into a dedicated CPU tier.

Render

Render pricing notes:

• We’ve referenced Render’s service compute pricing table.
• Render charges per team member.
• Teams with more than 10 users require an “Organization” plan.
• Render charges for egress with an initial free allotment. The free allotment and per-GB rate differ between the Team and Organization plans.
• Render does not specify if any compute tiers have dedicated CPU.

Railway

Railway pricing notes:

• We’ve referenced Railway’s pricing page.
• Railway is 100% metered billing, without the compute tiers that are common with other providers.
• You do not pay for idle/unused CPU or memory.
• There is no charge for team members.
• Railway does not specify if CPU is shared or dedicated.

Fly

Fly pricing notes:

• We’ve referenced Fly’s resource pricing for “started” machines.
• Fly supports more regions than any other PaaS listed here, with different prices per region.
• We use pricing for the ORD region (Chicago, US) since it’s not the cheapest nor most expensive region.
• We’ve factored in Fly’s CPU time-slicing on shared machines.
• Fly charges for egress, rate determined by region. We’re using the North America & Europe rate.
• Fly does not charge for team members.

Amazon ECS Fargate

Amazon ECS Fargate pricing notes:

• We’ve referenced Fargate’s compute pricing and AWS data transfer pricing.
• Fargate is 100% metered billing—you pay per vCPU-second and per GB-second with no fixed compute tiers.
• We use Linux/x86 on-demand pricing for the US East (N. Virginia) region.
• AWS provides 100 GB/month of free egress (shared across all AWS services), then charges $0.09/GB.
• There is no charge for team members (AWS IAM users are free).
• Fargate does not distinguish between shared and dedicated CPU.