Heroku Pricing 2026: Plans, Costs and Alternatives

Most teams should start on Standard dynos with a Postgres tier sized for their data, and wire up any background automation, say with Activepieces, only after the core app is stable.

Move up to Heroku Teams or Enterprise only when access control or compliance forces it.

Although the dyno is the unit Heroku meters, the database and the team controls decide the bill. This pick reflects Heroku's plan structure as of 3 November 2026. I've left out dollar figures I couldn't confirm, so check the live pricing page before you commit.

Which Heroku plan fits you

Although the dyno is the unit Heroku meters, the database and the team controls decide the bill.

Situation	Recommended plan	What sets the monthly cost	The catch that forces the next tier
Solo developer	Eco dynos with the smallest Postgres tier	One shared dyno allowance plus one database	Eco dynos sleep when idle, so the first visitor after a quiet spell waits
Team of 5	Standard dynos on Heroku Teams	Dynos, a per-member Teams fee, and a production database tier	The database tier you need for backups and headroom costs more than the dynos
Team of 25 needing SSO	Enterprise	Contract pricing, quoted rather than listed	SSO and finer admin controls sit above Teams
Heavy or regulated workload	Performance dynos in Private Spaces, or Shield	Quoted, and driven by isolation rather than dyno count	Compliance rules require network isolation that standard dynos do not provide

Heroku plan for a solo developer

For a solo developer, Eco dynos and the smallest database tier are enough for a prototype or personal tool.

An idle Eco dyno sleeps until the next request, so anything customer-facing feels unreliable. That's your cue for Standard, not a bigger dyno.

Team of 5

Once a team of 5 is running production, Standard dynos keep the app awake, and Heroku Teams adds shared access, so you pay a per-member fee on top of the dynos.

Team of 25 needing SSO

For a team of 25 needing SSO and admin controls, who can touch production matters more than raw compute.

SSO and tighter administration sit on Enterprise, which Heroku quotes by contract.

Heroku plan for heavy or regulated workloads

Performance dynos handle sustained load, but regulated data changes the question.

If you must have network isolation, Private Spaces is the tier that provides it, and Shield adds the controls auditors ask for.

Heroku plan pricing and limits

Heroku bills by dyno hours, the data service attached to them, and each add-on, with team controls layered above.

Tier	Price	Memory	Scaling	Sleeping	Limits
Eco dyno	$5/month for a shared pool of 1,000 hours	512 MB	Draws on the same pool	Sleeps after 30 minutes without traffic	Pool runs out across all Eco dynos
Basic dyno	Up to $7/month, prorated	512 MB	One dyno per process type	Never sleeps	No horizontal scaling
Standard-1X	$25/month	512 MB	Scales out to several dynos	Never sleeps	Memory is the ceiling per dyno
Standard-2X	$50/month	1 GB	Scales out to several dynos	Never sleeps	Double the memory, double the price
Postgres tiers	Essential starts at $5/month	Set by tier	Move up a tier to grow	Not applicable	Storage and connection caps
Key-Value	Mini starts at $3/month	25 MB on Mini	Move up a tier to grow	Not applicable	Memory cap per tier
Teams	Dynos and add-ons billed as usual	Follows dyno type	Org-level access and shared apps	Follows dyno type	Adds roles and collaborators
Enterprise	Contract, quoted by sales	Follows dyno type	Org-wide governance	Follows dyno type	Sold on contract only
Private Spaces	Contract pricing	Follows dyno type	Isolated runtime for your apps	Follows dyno type	Network isolation inside the space

Keep an Eco dyno always on and it needs 744 hours per month, which fits inside the 1,000-hour pool with 256 hours spare.

Two Eco dynos need 1,488 hours, and three need 2,232. Both exceed the pool, so the apps stop partway through the month. Past one always-on app, Basic or Standard is the honest comparison.

Pick the cheap dyno and the database is where the stack quietly turns expensive, because each Postgres or Key-Value tier caps storage, connections or memory. Key-Value's Mini tier holds only 25 MB, which suits a small cache and nothing larger.

Stop a Basic dyno mid-month and it costs less than $7, because Heroku prorates dynos for the time they run. The Eco pool is a flat $5 regardless of use, so an idle pool saves nothing.

What Heroku costs at realistic usage

Once an app has a database and more than one person on it, the dyno stops being the biggest line on the bill.

The table below adds up the same three apps, and its pattern is the point: the marked line moves from the dyno to the database to the people.

Line	Hobby app	Small production app	Team app
Dynos	Eco pool (largest line)	Two Standard	Standard, repeated per environment
Worker	None	One	One per environment
Postgres	Smallest tier	Production tier (largest line)	Production tier plus a smaller staging tier
Add-ons	None	A few	Several
Staging	None	None	One full copy
Review apps	None	None	Billed while running
Seats	One	One or two	Per member, with team controls (largest line)

Price each cell from the current list, since every dollar amount in this table is monthly.

Heroku cost for a hobby app

With one process, one person and a small database, the dyno is the only line worth looking at in a hobby app.

Heroku cost for a small production app

Start with two Standard dynos for redundancy, a worker for background jobs, and a production Postgres tier. The dynos are billed per dyno per month, so adding the worker is a straight addition.

The database is different. Its tier sets storage, connection limits and backup retention in one price, which makes it the line that most often decides the total.

Team app with staging and review apps

Here the metered units multiply. Staging duplicates the dynos, the worker and a database. Review apps add temporary dynos for as long as each pull request stays open, so the cost depends on how many branches your team leaves running.

Hidden Heroku costs and limits teams hit

It is rarely the dynos you can't cut. It is add-ons, the database tier, and a handful of limits that force a bigger dyno or a different design once real traffic arrives. Five of them, checked against Heroku Dev Center, cause most of the surprises:

• Add-ons are billed per plan on top of every dyno, so logging, cache and email can outweigh the web process itself. Price each one separately and leave out of staging the ones only production needs.
• Postgres plans move up in tiers, and each tier sets its own connection limit. A busy app can hit that limit with the CPU nearly idle, which forces a tier upgrade. Add connection pooling first.
• An R14 error means a dyno passed its memory quota and began slowing down. Find the leak or cut worker concurrency before paying for a larger dyno.
• Requests that run past 30 seconds are cut off by the router, so a slow export fails for the user. Move that work to a background worker, which is one more dyno on the bill.
• The filesystem is ephemeral, so uploaded files vanish when a dyno restarts. Store them in external object storage, which has its own bill.

Every staging app and review app runs its own dynos and usually its own add-ons, so one production stack quietly becomes several. Set review apps to expire and keep staging data small.

Send Heroku alerts and billing notices into Slack through a workflow tool, as many teams do, and you catch a usage spike before the invoice does.

Heroku against Render, Railway and Fly.io on price

When you compare hosts, the same metering trap shows up: Heroku bills a flat unit per dyno, while Railway and Fly.io bill what you consume.

To see which line item will move first as your app grows, read the table below. It shows the shape of each vendor's price, meaning the unit being metered, not a dollar figure.

	Heroku	Render	Railway	Fly.io
Entry service price	Flat rate per dyno size	Flat rate per instance size	Metered by CPU, memory and network used	Metered by machine size and run time
Managed Postgres price	Separate tier, priced by plan	Separate instance, priced by size	Runs as a service, billed by resources used	Priced separately from app machines
Free tier	None for new apps	Limited free services, with caps	Trial allowance, then paid	Trial allowance for new accounts, then paid
Billing model	Per dyno, prorated	Per instance plus workspace plan	Subscription plus usage	Usage, by the second
Team pricing	Per-member charges at higher tiers	Workspace plans with per-member charges	Plan-based seats	Organization-level, with support sold separately
Compliance	Separate Shield offering for regulated data	Offered on higher plans	Confirm on vendor page	Confirm on vendor page

Billing model and team pricing

Before launch, flat per-instance pricing lets you forecast a bill, while usage billing lets an idle app cost almost nothing and a busy one cost far more than expected.

If your traffic is spiky, usage billing can save money; if it's steady, the flat rate is easier to budget.

With team pricing, the cost lands when you need SSO, audit trails or role controls, and each vendor puts those behind a plan step. Price that step, not the first seat.

When staying on Heroku is the cheaper choice

When migration labor outweighs the gap in hosting cost, staying on Heroku wins. That's most likely when you already use its add-ons, need its compliance offering for regulated data, or run steady traffic where flat dyno pricing matches usage billing anyway.

What Activepieces does about this

The problem this article keeps returning to is a bill that grows in places you didn't size: the add-ons, the database tier, the seats. Activepieces can't shrink your Postgres tier, and I won't pretend it can.

What it can do is keep the glue around Heroku, such as billing alerts, usage notices and deploy notifications, from becoming one more metered line.

Activepieces charges 1 credit per flow run, whatever the number of steps, as its pricing page states. A ten-step flow that reads a Heroku usage report, checks it against a threshold and posts to Slack costs the same as a two-step one.

On Zapier or Make, where the unit is a task or a module, the same flow gets more expensive every time you add a check.

The core is MIT-licensed and self-hostable. If you run it yourself, the flows run on infrastructure you already pay for, and the per-run charge goes away. Be careful where you put it, though.

A self-hosted instance on a Heroku dyno adds a dyno and a database to the bill this article is trying to keep down, so a small VM elsewhere is usually the better home.

I haven't priced either option here, so check current figures before you decide.

The practical use is the spend watch the FAQ above recommends, since Heroku offers no hard cap I can confirm.

Build one flow that pulls usage on a schedule and flags a forgotten review app or an idle database that is still accruing its full tier price. Have it post to the channel your team already reads.

It's a small flow, and it catches the sort of waste that this article says sets the real monthly bill.

Frequently asked questions

Does Heroku still have a free plan?

No. Heroku retired its free dynos and free data tiers in late 2022. As of November 2026 the cheapest way to run an app is the entry-level Eco dyno on a paid basis.

That means even a hobby project carries a recurring charge before you add a database. Budget for the dyno and the data store together, because the second line is the one people forget.

How do I stop paying for an idle Heroku app?

Scale the dynos to zero, then remove or downgrade the add-ons, because add-ons keep billing whether or not any code runs. A stopped web process saves the dyno charge only. A Postgres database attached to that app still accrues its full tier price every month.

If you want the app back later, do these in order:

1. Take a backup.
2. Delete the database.
3. Restore it when you return.

If you only pause the dynos, you're paying for a database nobody is querying.

Is Heroku Postgres billed separately from dynos?

Yes. Heroku Postgres is an add-on with its own tier and its own monthly price, and it appears as a separate line on the invoice. Changing dyno size does nothing to it.

For most production apps the database tier is the larger of the two lines, so compare plans on the dyno plus the database, not the dyno alone.

The same applies to every other add-on, such as caching, logging, or scheduling: each is metered on its own plan.

Can I cap my Heroku bill?

Not with a hard stop that I can confirm as of this writing. What you can do is control the ceiling by controlling what you provision.

Dynos and add-ons are billed at fixed rates for the time they exist, so your worst case is the sum of the dyno count, dyno types, and add-on tiers you have switched on.

Avoid autoscaling rules you haven't tested, keep the maximum dyno count low, and review the usage page in the dashboard before the invoice closes. Check Heroku's current billing documentation for any spending alerts on your account type.

Do I pay for Review apps?

Yes, for whatever they spin up. A Review app is a temporary copy of your app built for a pull request, and it uses dynos and any add-ons defined in its configuration.

Because billing is prorated for the time it runs, a short-lived review app is cheap and a forgotten one is not.

The practical fix is to keep review apps on the smallest dyno type, avoid giving each one a paid database tier, and let them be deleted automatically when the pull request closes.

Related reading

• GitLab Pricing in 2026: What Teams Pay
• Snowflake Pricing Explained for 2026 Data Teams
• HeyGen Pricing for Creators, Marketers and Teams

References

• Heroku Dev Center