Methodology
How we build app profiles and sizing results, and what you can and can't conclude from them.
Principles
Official sources first: vendor documentation, official repositories and official Compose files. Community sources are labelled as such.
Every number has a source. A profile line without one cannot be published.
Results are reproducible: the same profiles and the same choices always give the same result.
What a profile contains
The components of a typical deployment (for example the app, its database and its cache), load presets with vCPU, RAM and disk per component, the options that change those numbers, and the sources with the date each one was read.
A profile records when its numbers were last checked against its sources.
Versions
Each profile has its own version, raised whenever its numbers or its structure change. The catalog as a whole has a release identifier (for example 2026.10.0).
A Deployment Spec records both, so any result can be traced back to the exact data it came from.
How sizing works
The Stack Sizer adds up what each selected profile states for the chosen load preset, plus the stated effect of each option you choose. Each line of the breakdown keeps its source.
Nothing else is applied. There is no hidden headroom and no silent rounding up to a machine size; if such rules are introduced, they will be stated here and shown in the result.
Verified Compose files
A profile can come with a Docker Compose file. It is marked Verified only after it was actually run and checked, and the record says when, how and against which profile version. Everything else is shown as unverified.
Limits
Profiles describe requirements, not guarantees. Real usage depends on your data, traffic and configuration.
The tools don't recommend providers, regions or prices.