This article explains how scaling works on LumaDock so you know what happens as your needs change.
Scaling on LumaDock is explicit
On LumaDock, nothing scales automatically without you asking for it.
Your VPS starts with the CPU, memory and storage you chose at deployment. It stays that way until you decide to change it. There is no background autoscaling and no silent resizing.
This makes behavior predictable. Performance changes only when you make a change.
What “scaling” usually means
For most users, scaling means one of two things.
Either you:
Increase resources on an existing VPS
Add another VPS and split responsibilities
Both approaches are supported, and neither changes how the platform behaves.
You don’t unlock a different system or move to a different product tier. You’re still using the same control panel and the same workflows.
Vertical scaling feels like resizing a machine
When you resize a VPS, you are giving that same server more room to breathe:
More CPU helps with concurrent work.
More memory helps with caching and busy applications.
More storage helps when data grows.
From your perspective, it’s still the same server with the same IP and configuration. It just has more capacity available.
Horizontal scaling means adding another server
Sometimes one server is no longer the right shape for the job. In those cases, scaling means deploying an additional VPS and letting each one handle a specific role. For example, one server for the app and another for the database.
Because all locations behave consistently, adding a second server doesn’t introduce new platform concepts. You already know how to deploy it and manage it.
Why this approach is intentional
Some platforms try to hide scaling behind automation. LumaDock takes the opposite approach. It keeps scaling decisions visible so you understand what changed and why. That makes troubleshooting easier and costs easier to predict.
You stay in control of when resources increase and when they don’t.