Skip to content

Scaling

vCPU and RAM scaling

When your resource needs grow we don't rebuild the server. vCPU and memory are raised in a planned maintenance window while your application, data and configuration stay exactly as they are.

When scaling up
No reinstall
Downtime applied under control
Planned window
Capacity threshold tracking
Zabbix
Scale up and down
Two-way

When vertical scaling is enough — and when it isn't

Vertical scaling means giving the same server more vCPU and memory. It requires no change to application architecture, which makes it the fastest option: same code, same configuration, just a higher resource ceiling. For most enterprise applications it is sufficient for a long time.

Two limits eventually appear. The first is the physical capacity of a single server. The second, and more critical, is that a single server is also a single point of failure: when it goes down, so does the service. For systems that cannot tolerate downtime the answer is not a bigger server but horizontal distribution and a high-availability architecture.

We base capacity decisions on measurement, not guesswork. CPU utilisation, memory pressure, disk queue and response-time data collected in Zabbix show whether the bottleneck genuinely sits in the processor, in memory or in disk access. Growing the wrong item usually fixes nothing.

  • Scaling decisions rest on measurement data
  • Application and data are preserved as-is
  • Changes are applied in a planned maintenance window
  • Resources can be reduced when demand falls
  • When the single-server limit is reached, an HA design is planned

Process

The scaling process

  1. 01

    Threshold alert

    Zabbix alerts our operations team when CPU or memory use crosses the defined threshold — usually before any user complaint arrives.

  2. 02

    Bottleneck analysis

    Metric history is reviewed to determine whether the constraint lies in CPU, memory or disk access.

  3. 03

    Window planning

    The change window is agreed with you, typically at the hours of lowest traffic.

  4. 04

    Apply and verify

    New resources are applied, the server is brought back up, and metrics are verified against the new values.

Features

What can be scaled

  • vCPU count

    The first item to review for compute-heavy applications, reporting queries and multi-user systems.

  • Memory (RAM)

    Decisive for database caches and application server pools. Memory pressure drives disk access up and slows everything down.

  • NVMe capacity

    Data growth is predictable, so it is usually planned ahead; capacity is still extended when the utilisation threshold trips.

  • Network capacity

    The private network is 10 Gbps as standard; where a higher internet uplink is needed it is planned separately.

  • Server count

    At the single-server limit the workload is distributed across multiple servers with load balancing in front.

  • Backup capacity

    As data grows, backup storage and retention are reviewed together.

FAQ

Frequently asked questions

Is there downtime during scaling?

In most scenarios a brief restart is required, typically measured in minutes, and it is applied in a maintenance window agreed with you. For systems that cannot tolerate any downtime, a high-availability architecture removes even this step.

Can I scale back down?

Yes. Resources raised for a seasonal peak can be reduced afterwards. E-commerce customers with campaign periods use this two-way scaling regularly.

When should I add a second server instead of scaling?

In two cases: when you approach the capacity limit of a single server, and when you cannot accept the outage risk. The second is the more common reason, because however large you make it a single server remains a single point of failure. At that point we plan a high-availability design with you.

How do I know whether my capacity is sufficient?

We review the CPU, memory, disk and network metrics collected in Zabbix together with you. Beyond utilisation levels we look at peak-hour behaviour and response times, and base the capacity decision on that data.

Let's plan your infrastructure together

Tell us what you need and we prepare a configuration and pricing specific to you. We don't sell fixed packages; we build the deployment, licensing and backup plan with you.