ScalaHosting Build #1 SPanel Limits: cgroups vs CageFS, CPU Caps & 2026 Cost

What CPU 100 actually buys an account

In SPanel's Advanced Limits controls, **CPU 100 is one full core**, CPU 50 is half and CPU 200 is two cores. The dial measures a share of a single core, not 100 percent of the whole Build #1 machine. When an account sustains excess CPU demand, the kernel throttles execution rather than terminating a process. A page can become slow without the process disappearing.

Build #1 offers two CPU cores and 4GB RAM at the server level. A plan hosting four customer accounts is not four independent two-core machines. For planning, an agency could begin by considering smaller account caps for lower-traffic sites, leaving capacity for the OS, MySQL, PHP and backups, then revising them from real usage—not taking a universal fixed 25% allocation as the product's default. SPanel's separate example package values are illustrative settings chosen by an administrator, not guaranteed allocations per Build #1 account.

Five ceilings produce different failure signatures

**CPU cap:** Requests stall under sustained calculation and recover when load eases. **Memory cap:** The kernel may reclaim or kill the offending account's own processes in a worst-case shortage. **Storage throughput:** Disk reads and writes queue and slow; this is disk MB/s, not website network bandwidth. **IOPS:** Many small file/database operations queue even when raw MB/s looks acceptable. **Total process limit:** A new fork can fail outright when the cap is reached. SPanel describes a service that moves account processes into their control group roughly once per second, so sub-second transient spikes are not perfectly contained.

PHP workers add another layer: requests may queue behind busy PHP processes despite spare CPU. Therefore “the site is slow” cannot automatically be diagnosed as a CPU issue. Check PHP worker saturation, RAM reclaim or process exits, disk latency/IOPS and account-level CPU pressure separately before buying more server cores. Package settings also govern inodes, mail quotas, databases and other non-CPU resources.

cgroups is not CageFS

cgroups are about how much CPU, memory, disk I/O or process capacity a group may consume. CageFS, a separate CloudLinux filesystem isolation mechanism, concerns what a tenant can see in the filesystem. Resource limiting does not by itself prove that one account cannot read another account's files. CloudLinux's LVE resource controls and its CageFS mechanism should not be collapsed into a single feature comparison. ScalaHosting's own documentation states that its SPanel resource limiting is **not CageFS-style filesystem virtualization**.

An agency dealing with mutually untrusted customers should ask about OS user separation, file permissions, PHP process identity, backups, malware response and the threat model before deciding whether one multi-account VPS is sufficient. For strict client or contractual isolation, separate virtual servers or an explicitly verified filesystem boundary may be more appropriate. We have not penetration-tested ScalaHosting and make no claim that any particular client can or cannot access another client's files.

Beware of “burst” as a capacity promise

SPanel documents opportunistic burst behavior while the server has unused physical capacity. That is not the same as buying extra dedicated cores, and the speed may disappear as neighboring accounts on **your own server** become busy. If a store has predictable promotion peaks, size the machine and worker budgets for measured concurrency and test error handling. Neither a marketing burst claim nor a quota number is a real-world application benchmark.

How to check before paying

1. Ask ScalaHosting whether the current Build #1 checkout exposes SPanel Advanced Limits and how your account quotas are configured by default; record the answer rather than copying sample reseller package settings. 2. List the expected clients, peak PHP/database load, memory-hungry plugins, upload jobs and scheduled backups. Budget headroom for the control plane and system software; do not promise every customer the entire VPS allocation. 3. Request a sample of account-level CPU throttle, memory/failed-fork and disk-I/O observations, and clarify which troubleshooting data and SPanel alerts your chosen managed plan exposes. 4. If clients must be mutually isolated, separately document filesystem permissions, user boundaries and backup access. A CPU cap is not an access-control test. 5. Verify the actual term, add-ons, support scope, eligibility, total due now and displayed renewal before paying. No actual checkout or workload benchmark was performed for this guide.

October–December 2026 sale: compare cash rather than slogans

ScalaHosting's October 21 Black Friday post lists Build #1 at **$22.46/month for a 12-month promotional term**, prepaid **$269.52**. Its **36-month promotional term is $29.95/month**, prepaid **$1,078.20**, and the displayed standard renewal reference is **$54.95/month**. The offer runs October 19 to December 1, 2026, applies to eligible new plans and upgrades, not ordinary existing-plan renewals.

The 12-month rate is lower on the first-year headline, but if you kept the server 36 months and renewed the next 24 months at the *currently advertised* $54.95 rate, you would spend $269.52 + $1,318.80 = **$1,588.32**. That exceeds the current 36-month promotional prepayment by **$510.12**. This is arithmetic based on listed terms, not a guarantee about future renewal prices, tax, currency, upgrades, refunds or cart eligibility. A buyer uncertain about the project duration may rationally prefer the lower initial commitment.

Other reviews cover ScalaHosting's broad pricing, SPanel interface, migrations or provider performance, but they do not replace an account-level isolation budget and actual checkout verification. In particular, shared-hosting competitor headline prices and third-party speed scores cannot be applied as Build #1 resource promises.

The buying decision

Choose Build #1 if its two-core/four-gigabyte server is enough for your measured workload, account-level throttles make shared-client operations manageable and you understand the security boundary. Do not buy it expecting a separate guaranteed 2-core server or a CageFS filesystem for every customer. Verify the official cart and remember that one large prepaid discount is less useful if you outgrow the plan or need stronger per-client isolation. The approved ScalaHosting personal affiliate link may earn Toolnavia a commission on qualifying purchases without additional cost to the reader.