Vertical scaling on Stack Harbor PaaS changes the amount of RAM and CPU available to a container without rebuilding it. The platform dynamically reallocates resources in response to load — no manual intervention, no application restart. You set a ceiling, and the platform stays inside it.
This page covers the mechanics: the unit of allocation (cloudlets), the two cloudlet types, and how to change the limits from the topology wizard.
What scales vertically
Vertical scaling applies to any container in an environment — application server, database, load balancer, custom Docker container, Elastic VPS, cache instance, build node. It works in place: as load grows, the platform allocates more resources to the container; when load drops, it pulls them back.
Cloudlets — the unit of allocation
Resources are measured in cloudlets. One cloudlet is 128 MiB of RAM and 200 MHz of CPU. Cloudlets are split into two classes:
- Reserved cloudlets — capacity you commit to. The container always has access to them, and you are billed for them regardless of actual usage. The unit cost is lower than dynamic.
- Dynamic cloudlets — capacity the container can grow into. You are billed only when they are actually consumed.
Automatic vertical scaling operates inside the dynamic-cloudlets pool. The dynamic limit you set on a layer is the ceiling on what the platform will allocate — and the ceiling on what you can be billed for if the load justifies it. Mixing reserved and dynamic gives you a knob between predictable monthly cost and elastic capacity.
Default cloudlet values per stack
Each stack added to an environment gets sensible defaults. A few examples:
| Stack | Reserved | Dynamic limit |
|---|---|---|
| Tomcat, Jetty | 1 | 6 |
| TomEE | 1 | 8 |
| GlassFish | 6 | 16 |
| Apache, NGINX, NGINX balancer | 1 | 4 |
| NGINX-Ruby | 1 | 6 |
| Apache-Ruby, Apache-Python | 1 | 8 |
| Node.js | 4 | 8 |
| MySQL, MariaDB, PostgreSQL | 1 | 6 |
| Memcached | 1 | 4 |
| VPS | 1 | 16 |
| Maven | 1 | 16 |
These are starting points. Use the statistics the platform collects automatically (visible in the dashboard) to see what your application actually consumes over the previous month, then size accordingly.
Adjust the limits
Open the topology wizard for the environment and use the cloudlet sliders in the Vertical Scaling section of the central pane. Apply the changes.
Changing the dynamic limit (the upper cap) on an existing application server, database, or cache node restarts the layer. The wizard shows a warning before you confirm. The reserved value can usually be changed without a restart, but read the warning shown in the wizard before applying.
If a single container’s capacity is no longer enough — even at the maximum cloudlet limit — that’s the signal that vertical scaling has done its job and you need to move along the other axis: add nodes manually with horizontal scaling, or wire up automatic horizontal scaling triggers.
Related pages
- Horizontal scaling — adding nodes when one container is no longer enough.
- Automatic horizontal scaling — load-driven node addition and removal.
- Isolated containers — how vertical scaling interacts with container isolation guarantees.