Docker Memory Budget Calculator

Table of Contents

• What this tool does—and does not do
• Formula
• Default worked example
• How to measure memory
• Reservation versus hard limit
• Host reserve
• Workload headroom
• Swap and OOM caveats
• Databases and page cache
• Validate under load
• Next steps
• Frequently asked questions

What this tool does—and does not do

This calculator turns per-container memory budgets into a Docker Compose host-size worksheet. Enter each workload group’s container count and per-container budget. It adds budgets, applies workload headroom, protects part of host RAM for the operating system, and rounds up to a common size.

It is arithmetic, not app-specific RAM advice. Use measured or official inputs; it cannot predict demand, infer a budget from an image name, or anticipate changes in traffic, data, plugins, dashboards, or jobs.

Do not size a host from image download size: it is not running-container memory. Do not copy an unverified forum number. Start with an observable workload, record conditions, and revisit the budget when the workload changes.

Formula

The calculator follows four steps:

1. Add every workload row: container count × memory budget.
2. Apply workload headroom: container subtotal × (1 + headroom percentage).
3. Convert the protected host reserve into total required RAM: headroom-adjusted workload ÷ (1 − host reserve percentage).
4. Round up to the next common host size in 1, 2, 4, 8, 16, 32, 64, 128 GiB.

In one expression:

rounded host size = round up(subtotal × (1 + workload headroom) ÷ (1 − host reserve))

Use the calculator’s units. In the default example, budgets are entered in MB and the result is shown in MB and GiB. Keep units consistent; convert MB and GiB before combining them.

Default worked example

The default rows represent a small Compose host with two application containers, one database, one cache, one reverse proxy, and one monitoring container:

Workload	Count	Budget each	Subtotal
App containers	2	512 MB	1,024 MB
Database	1	1,024 MB	1,024 MB
Cache	1	256 MB	256 MB
Reverse proxy	1	128 MB	128 MB
Monitoring container	1	512 MB	512 MB

The container subtotal is 1,024 + 1,024 + 256 + 128 + 512 = 2,944 MB.

Apply 20% workload headroom:

2,944 × 1.20 = 3,532.8 MB

Because the host reserve is 25% of total RAM, calculated host RAM is:

3,532.8 ÷ (1 − 0.25) = 4,710.4 MB

That is approximately 4.60 GiB. The calculator rounds up to the next common host size in its list: 8 GiB.

For these budgets and percentages, the result is an 8 GiB host. It does not mean every host needs exactly 8 GiB or prove the budgets are correct; it means 8 GiB is the next listed size above the calculated requirement under the worksheet’s assumptions.

How to measure memory

Use budgets grounded in the intended workload. For each service, choose a representative period and record memory during normal work, including active users or jobs, scheduled tasks, imports, backups, dashboards, and data size.

Do not rely on one quiet-time snapshot: startup readings may be low, and a short spike may matter despite a comfortable average. Keep the observation window and workload description with each budget for later comparison.

For related deployment context, review OpenAlt’s Portainer Docker Compose guide, Grafana Docker Compose guide, easiest self-hosted apps, and PaaS deployment category.

Reservation versus hard limit

A Compose memory reservation expresses what a service needs for placement or scheduling. A limit is a ceiling on use. They answer different questions and are not interchangeable.

Docker’s Compose resource reference documents limits and reservations, including memory values expressed as byte quantities. Docker also documents that containers are unlimited by default unless constraints are configured and that memory pressure can cause out-of-memory behavior. Read the Docker resource constraints guidance before treating a configured value as protection.

Enter the service’s expected memory need. If you configure a hard limit, ensure it permits normal operation: too low can cause failure with RAM available, while too high can let one service consume capacity needed elsewhere. The calculator sizes the host; it does not choose safe Compose limits.

Host reserve

The host reserve protects memory for the operating system and host-level work. Docker is not the only RAM consumer, so the margin keeps the machine from operating at total capacity.

Enter the reserve as a percentage of total host RAM. With a 25% reserve, only 75% of total RAM is available to the calculated workload after headroom. That is why the formula divides by 0.75 instead of simply adding 25% to the workload subtotal.

Workload headroom

Workload headroom covers the gap between entered budgets and their measured conditions. In the default example, 20% changes 2,944 MB to 3,532.8 MB before the host reserve is applied.

Headroom is not a substitute for measurement. Apply it consistently for auditability. If one service has a known burst pattern, improve its budget from evidence rather than hiding the issue in a larger percentage.

Swap and OOM caveats

Swap does not turn insufficient physical RAM into a reliable host-size recommendation. It changes what happens when demand exceeds RAM but does not remove the requirement. A swapped system may behave differently, and an out-of-memory event can still occur when demand cannot be satisfied.

Docker’s guidance describes the risk of out-of-memory conditions and the importance of testing resource constraints. Treat swap policy as an operational choice to validate on your host, not as extra RAM to add to the calculator’s physical-memory result.

Databases and page cache

Databases deserve separate attention because observed memory can reflect the database process and useful filesystem activity. Quiet readings, warm datasets, and active queries may differ. Record conditions when measuring the budget, and tie it to the dataset and operations that produced it.

The same applies to page cache and memory that supports host I/O. Do not assume every visible byte belongs to one container or can be reclaimed without changing behavior. Compare representative measurements and keep the host reserve in place.

Validate under load

After choosing a host size, test the Compose stack under the heaviest representative workload you can safely generate. Exercise important operations and observe container memory, host memory, service health, and resource pressure. Repeat when configuration, data volume, or workload shape changes.

Validation should answer two questions: do the budgets describe reality, and does the host retain its intended reserve while active? If either answer is no, update the inputs and calculate again. An idle start is not enough evidence.

Next steps

List every container sharing the host, including operational services. Group identical containers when useful, then enter a measured or officially documented budget for each group.

Confirm the workload headroom and host reserve percentages. Review MB and GiB, select the next common host size, and validate under representative load before production. Retain the observations supporting each budget.

Frequently asked questions

Why does the result round to 8 GiB?

The default calculation produces 4,710.4 MB, or about 4.60 GiB. The calculator rounds up to the next size in its common-size list—1, 2, 4, 8, 16, 32, 64, and 128 GiB—so the displayed host size is 8 GiB.

Does image size equal RAM usage?

No. Image download or storage size is not the running container’s memory budget. Use measured memory or official application guidance for the workload, then enter that budget in the calculator.

Does swap count as host RAM?

No. Swap is not counted as physical RAM in this worksheet and should not be used to reduce the calculated host size. Validate any swap policy separately under the workload you intend to run.

Does the calculator replace load testing?

No. It performs the capacity arithmetic after you provide budgets. Load testing is still needed to check whether those budgets describe real behavior and whether the host keeps its reserve under representative activity.