Docs / Shared hosting
PHP versions, settings, and resource limits
Which PHP versions Candor Host runs, how to switch per site from the portal, and what the published memory, CPU, and I/O guarantees actually mean when you hit them.
Every plan runs PHP 8.3 by default, lets you switch versions per site without a ticket, and comes with resource numbers we publish instead of hiding behind “unlimited.” This page covers all three: the versions, the settings you can change, and what each limit looks like from inside your site when you reach it.
PHP versions
The default on every plan — Solo, Studio, and Org — is PHP 8.3. You can switch any site independently to PHP 7.4, 8.0, 8.1, 8.2, 8.3, or 8.4. The portal steps below switch your service’s primary site; on Studio and Org plans with multiple sites, switch the others from the control panel (Open control panel on the Overview tab).
A word on the older end of that range: PHP 7.4, 8.0, and 8.1 no longer receive security fixes from the PHP project, and 8.2 gets security fixes only. They’re offered so a legacy application keeps running while you fix it, not as a place to stay. If your code runs on 8.3, run 8.3.
Switching PHP versions
- Log in to the customer portal and open your hosting service.
- On the Overview tab, under Apps & developer tools, open PHP version.
- The tab shows the version your site is currently running. Pick a new one from the Switch to dropdown and click Apply.
- Confirm the prompt — your site briefly reloads while the change takes effect.
- Load your site and check it works. If it errors after the switch (usually an old plugin or theme that isn’t compatible with the newer version), come back to the same tab and select the previous version. The switch is fully reversible.
For WordPress sites, it’s worth updating plugins and themes first — see WordPress on Candor Host — since outdated plugins are the most common reason a PHP upgrade breaks a site.
The PHP settings editor
Every plan also includes the control panel’s PHP settings editor, so you can adjust your site’s PHP configuration — the kind of values that traditionally live in php.ini — yourself, per site. Click Open control panel on your service’s Overview tab in the portal, then open the PHP settings for the site; the panel shows the exact directives you can change. If a setting you need isn’t editable there, ask us — some server-wide values are fixed on purpose, and we’ll tell you plainly which and why.
What the resource limits mean
Each account runs in its own isolated container, and the CPU, memory, and I/O numbers below are enforced per account by the Linux kernel (cgroups). That makes them guarantees, not caps-in-disguise: the allocation is yours even when the server is busy, and a noisy neighbor stays their problem. The inode limit is a filesystem quota on the same account; storage is capped by your plan’s allocation. These figures come from the same configuration files that provision accounts — the full plan comparison, including storage, mailboxes, and databases, is on the platform page.
| Solo | Studio | Org | |
|---|---|---|---|
| Guaranteed memory | 1 GB | 2 GB | 2 GB |
| Guaranteed CPU | 1 vCPU | 2 vCPU | 2 vCPU |
| Disk IOPS | 1,024 | 2,048 | 2,048 |
| I/O bandwidth | 20 MB/s | 30 MB/s | 30 MB/s |
| Processes | 20 | 40 | 40 |
| Inodes (files) | 250,000 | 500,000 | 500,000 |
Transfer isn’t in the table because we don’t meter it — no counter, no overage charges. “Not metered” still isn’t “unlimited”; the Acceptable Use Policy covers genuine abuse, which is what every host’s “unlimited bandwidth” quietly means anyway.
Memory
Your account’s processes — PHP, and anything you run over SSH or cron — share the guaranteed memory. There is no swap on any plan, deliberately: when memory runs out, you don’t get a site that slowly drowns in disk-swapping; the kernel ends the largest process instead. In practice that looks like an occasional failed request or a killed script, and the site recovers immediately. Note that a single PHP request usually hits PHP’s own per-request memory limit (the familiar “Allowed memory size exhausted” error) long before the account-wide limit — that per-request limit is PHP configuration, separate from the account guarantee.
CPU
The vCPU figure is a floor: that much compute is yours at all times. When your site uses everything it has — a traffic spike, a heavy import — requests queue and pages respond more slowly. Nothing errors, nothing is killed; things are just slower until the load passes.
Disk IOPS and I/O bandwidth
IOPS is how many disk operations per second your account can perform; I/O bandwidth is how much data per second it can move to and from disk. Hitting either one throttles rather than fails: file-heavy work — a large media import, a backup restore, a cache rebuild — simply takes longer. Normal page loads rarely get near these numbers.
Processes
This is the number of simultaneous processes your account can run. Exceeding it means new processes can’t start — typically a “resource temporarily unavailable” error — until existing ones finish. The usual culprits are a cron job that overlaps itself because each run takes longer than its schedule, or a script that spawns children without cleaning them up.
Inodes
Every file and directory consumes one inode, so this is effectively a file-count limit. Hitting it means new files can’t be created — uploads, cache writes, and session files start failing with “disk quota exceeded” — even when you have gigabytes of storage free. The usual cause is hundreds of thousands of tiny files: unpruned cache directories, old sessions, log fragments. Clearing those brings you back under, and your disk usage is always visible in the portal’s Usage & resources tab.
If you keep hitting a limit
Hitting a limit once during a spike is normal. Hitting one constantly means the plan no longer fits: you can upgrade (or downgrade) from the client area at any time, and your renewal price stays the listed rate you signed up at. If you’re not sure whether the fix is a bigger plan or a smaller cache directory, ask — per Candid Support we don’t upsell in support conversations, so you’ll get a straight answer either way.
For how the isolation itself works, see How shared hosting works.
Something here wrong, unclear, or missing? Tell us — docs get fixed like bugs.