Build a plan for the workload you expect
Choose catalog apps using their displayed sources and assumptions, or add a custom workload with your own minimum and maximum estimates. Quantity multiplies both ends of each range. Use GiB for RAM and decimal GB for storage.
Enter the resources available to this stack, allowing for other workloads on the host. Headroom reserves the selected percentage of each budget once; it is not a separate multiplier on every app. The default is a starting assumption, not a universal operating rule.
Leave an estimate unknown when you do not have evidence for it. Fill in both ends of a custom range when you do: a partial or reversed range needs correction. Revisit the plan when user activity, retained data, indexing, or media processing changes.
An estimate needs a workload behind it
The planner totals RAM and app storage, not CPU requirements or a complete hardware specification. A reviewed catalog estimate has a stated basis, confidence, and source date. Reviewed does not mean official, measured on your host, or suitable for every installation. A custom estimate carries the assumptions you supply.
Read that evidence before treating a range as your workload. A small personal database and a heavily indexed shared service can have very different needs even when they run the same app.
Read fit as a planning range
| Status | Comparison with the available budget | What it means for the plan |
|---|---|---|
| Within | The maximum estimate fits | The whole estimated range fits, including equality |
| Tight | The minimum fits but the maximum does not | Workload variation can exceed the budget |
| Over | Even the minimum exceeds the budget | The entered budget cannot cover the estimated range |
| Unknown | One or more required estimates are missing | The known subtotal cannot settle the full requirement |
The binding resource is the complete dimension with the largest maximum-demand-to-budget ratio. It is a way to compare the entered ranges, not a measured bottleneck. CPU notes remain qualitative and are not added into a CPU total.
Resource limits do not predict demand
A Docker memory limit constrains a container; it does not establish how much memory the application needs. Reservations and limits also serve different purposes. Setting a low limit to make a plan fit can leave the application short of memory rather than reduce its workload. See Docker's resource-constraint documentation before translating estimates into container settings.
Run a representative workload and compare observed use with your assumptions. Docker's stats command can help with container usage, but the planner itself collects no host telemetry and cannot guarantee that a stack will run well.
The site loads the catalog evidence; calculations using your selected workloads and budgets then run locally in the browser. That does not mean catalog loading or the rest of the site makes no network requests.