Dyno Sizes

Every process in your formation (web, worker, etc.) runs on a dyno—an isolated, containerized instance of your application. Dynos come in several sizes, each with a different amount of memory, CPU, and price. Choosing the right size for each process type is part of both cost control and performance tuning (see Scaling & Performance).

Common Runtime sizes

These sizes run in the shared Common Runtime, alongside dynos from other apps (isolated via containers, but not on dedicated hardware unless noted).

Size	Memory	CPU share	Dedicated	Compute	Dyno units
eco	512 MB	1x	No	1x	1
basic	512 MB	1x	No	2x	0.28
standard-1x	512 MB	1x	No	4x	1
standard-2x	1 GB	2x	No	8x	2
performance-m	2.5 GB	100%	Yes	12x	8
performance-l	14 GB	100%	Yes	50x	16
performance-l-ram	30 GB	100%	Yes	24x	16
performance-xl	62 GB	100%	Yes	50x	30
performance-2xl	126 GB	100%	Yes	100x	60

Dyno units express what each size costs relative to the others. A dyno accrues its unit count for every hour it runs—730 hours in an average month if it stays always-on—and a process type scaled to zero accrues nothing.

Size names are case-insensitive but conventionally written lowercase-hyphenated (e.g. standard-1x) as shown above.

Dyno unit pricing

Each dyno unit hour costs $0.025. Multiply a size’s dyno units by the hours it runs to get its cost: a standard-1x dyno (1 unit) costs $0.025 per hour, or $18.25 over a full 730-hour month; a performance-m dyno (8 units) costs $0.20 per hour, or $146 per month.

Setting dyno size

Set (or change) the size for a process type at the same time you scale it, using ps:scale:

$ bld ps:scale web=2:standard-2x worker=1:standard-1x -a my-app

The TYPE=QUANTITY:SIZE syntax lets you set the count and size for multiple process types in a single command. If you omit the size, the process type keeps its current size.

To change only the size without changing the dyno count, pass the current quantity along with the new size:

$ bld ps:scale web=2:performance-m -a my-app

Inspecting current sizes

List running processes along with their size:

$ bld ps -a my-app -j | jq '.[] | {type, state, size}'

Or check the full formation (including scaled-to-zero process types) from the app details:

$ bld apps:info -a my-app -j | jq '.formation'

Choosing a size

• Start with standard-1x for new apps—it offers a full dedicated CPU share at a moderate price point.
• Use eco or basic for review apps, low-traffic staging environments, or quick experiments where cost matters more than performance.
• Move to standard-2x or a performance-* size if you see dynos being restarted for exceeding memory limits, or if response times are high under load despite adequate dyno count (see Vertical scaling).
• Reach for performance-l-ram over performance-l when your workload is memory-hungry but not CPU-bound—more RAM, less compute.