The term “cloud hosting” gets used loosely in the WordPress world. Some hosts call any server in a data center “cloud”. Others use it to mean autoscaling infrastructure spread across multiple regions. The result is that “cloud WordPress hosting” can describe anything from a rebranded shared server to a full Kubernetes cluster, depending on who is selling it.
This post breaks down what cloud hosting actually means in technical terms, how it compares to traditional shared hosting and VPS setups, and what to look for when evaluating a cloud WordPress host.
What cloud hosting actually means
At its core, cloud hosting means your site runs on infrastructure that is virtualized and managed by a cloud provider rather than tied to a single physical machine. The cloud provider – DigitalOcean, Linode, AWS, Hetzner, or similar – owns and operates the physical servers. The hosting company (or you, if self-hosting) runs virtual machines or containers on top of that hardware.
This creates a meaningful distinction from traditional hosting models:
Traditional dedicated server: You rent an entire physical machine. If the hardware fails, your site goes down until the hardware is replaced. You get full control but also full responsibility.
Traditional shared hosting: Your site shares a single physical server with hundreds of other accounts. If the server fails, every site on it goes down. Resources are shared and one account’s traffic spike can affect everyone else.
Cloud hosting: Your site runs on virtualized infrastructure where the underlying hardware is abstracted. If a physical server fails, the cloud provider can migrate your workload to another machine. Resources can be allocated more precisely because they are managed at the software level rather than being limited by a single machine’s hardware.
The cloud part is not magic. It is the difference between running software on a specific machine versus running it on infrastructure where the machine can be swapped without your site knowing the difference.
Shared hosting, VPS, and managed cloud: the real differences
These three models are fundamentally different in how they isolate accounts, allocate resources, and distribute responsibility. The names are often misused in marketing, so what matters is the technical implementation, not the label.
Traditional shared hosting
A shared hosting server runs hundreds or thousands of accounts on one machine. The most common stack is cPanel + CloudLinux + Apache or LiteSpeed. Each account gets a home directory, a cPanel login, and resource limits enforced by CloudLinux’s LVE (Lightweight Virtual Environment).
How isolation works: CloudLinux’s CageFS creates a virtualized filesystem for each user. When your PHP code runs, it sees a restricted view of the server – it cannot access other users’ files or sensitive system paths. Resource limits (CPU, memory, I/O) are enforced via kernel cgroups through LVE.
Where it falls short: CageFS provides filesystem isolation, but not process or network isolation. All accounts share the same kernel, the same process table, and the same network stack. A compromised account cannot read another account’s files (CageFS prevents that), but it can see that other processes exist. The isolation is a layer on top of a shared environment, not a true separation.
This model works well for low-traffic sites where cost is the primary concern. It is the most affordable option because the fixed cost of one server is spread across many accounts.
VPS (Virtual Private Server)
A VPS gives you your own virtual machine with dedicated resources. You get root access, your own operating system, and full control over the software stack. The hypervisor (the software that creates virtual machines) guarantees that your allocated CPU, RAM, and storage are yours – not shared with other tenants at the application level.
How isolation works: Each VPS runs in its own virtual machine with its own kernel, process table, and network stack. This is stronger isolation than shared hosting. One VPS being compromised does not give the attacker access to another VPS on the same physical host.
Where it falls short: You manage everything yourself. Operating system updates, security patches, MySQL tuning, Nginx configuration, PHP upgrades, SSL certificates, backups, firewall rules, WordPress updates – all of it is your responsibility. This is significant ongoing work that most WordPress site owners underestimate.
An unmanaged VPS from a cloud provider costs $5-50/month. A managed VPS where the provider handles server administration costs $50-200/month or more, depending on the level of support.
Managed cloud WordPress hosting
Managed cloud hosting sits between shared hosting and VPS. The infrastructure runs on cloud servers (virtualized, scalable, hardware-abstracted), but the hosting company manages the entire stack – you do not need to administer the server.
The key difference from traditional shared hosting is the isolation model. Instead of CageFS filesystem virtualization, managed cloud hosts typically use containers or lightweight virtual machines that provide stronger isolation between accounts.
The key difference from VPS is that you do not manage the server. The hosting company handles updates, security, backups, and optimization. You manage your WordPress site, not the infrastructure underneath it.
This model works well for WordPress sites that need reliable performance and security but whose owners want to focus on their business rather than server administration.
What container isolation means for WordPress
Container isolation is the technical foundation that separates modern managed WordPress hosting from traditional shared hosting. Understanding what containers do (and do not do) helps you evaluate hosting claims.
A container is an isolated environment that runs on a shared kernel but has its own filesystem, process table, and network namespace. When your WordPress site runs in a container, its PHP processes cannot see other accounts’ processes, cannot access other accounts’ files, and cannot interfere with other accounts’ network connections.
This is a meaningful step up from CageFS-style isolation. To understand why, consider what happens when a WordPress plugin has a security vulnerability:
On traditional shared hosting (CageFS): The attacker gains code execution under your user. CageFS prevents them from reading other users’ files, but they can see other processes running on the server (process table is shared). They share the network stack with every other account. The blast radius is contained but the isolation boundaries are thinner.
With container isolation: The attacker gains code execution inside your container. They cannot see other processes because the process namespace is separate. They cannot access the network interfaces used by other accounts. They cannot escalate privileges because the container drops dangerous Linux capabilities. The blast radius is limited to your container. For a deeper technical comparison of these two approaches, see how Hostney isolates websites with containers.
Resource isolation follows a similar pattern. On traditional shared hosting, resource limits are enforced but flexible – a noisy neighbor can still cause momentary slowdowns before the limits kick in. With containers, resource limits are enforced at the kernel level with harder boundaries. Your allocated CPU, memory, and I/O bandwidth are yours, and another account exceeding their limits does not degrade your performance.
What to look for when evaluating cloud WordPress hosting
Marketing pages all say the same things: fast servers, great support, 99.9% uptime. The differences that matter are technical and often require reading beyond the headline features.
Isolation model
Ask what isolates your account from other accounts on the same server. “CloudLinux” or “CageFS” means filesystem-level isolation. “Containers” or “Podman/Docker” means namespace-level isolation. “Virtual machines” means hypervisor-level isolation (strongest but heaviest). Each is a valid approach with different tradeoffs, but they are not equivalent.
Resource allocation: dedicated vs shared
“Dedicated resources” means specific CPU cores, RAM, and I/O bandwidth are allocated to your account and enforced by the system. “Shared resources” means you compete with other accounts on the same server, with soft limits that prevent extreme abuse but do not guarantee performance under load.
Look for specific numbers. A host that says “1 CPU core, 4GB RAM, 50MB/s I/O” is being transparent about what you get. A host that says “unlimited everything” is not, because server resources are finite and something has to give when a server is oversold.
Storage type
The storage your hosting runs on affects WordPress performance more than most people realize. WordPress relies heavily on random I/O – database queries, PHP file includes, session reads, and cache lookups all generate random read patterns that expose the difference between storage types.
NVMe storage connects via PCIe and delivers dramatically higher random read IOPS and lower latency than SATA SSDs. The difference is most visible when your site’s caches are cold, during traffic spikes, or on WooCommerce sites where pages cannot be fully cached. For a detailed breakdown of how storage type affects WordPress specifically, see NVMe WordPress hosting: why storage type affects your site speed.
If the host does not specify their storage type, ask. If they say “SSD” without specifying NVMe, it is likely SATA SSD, which is fine but not as fast.
Caching stack
WordPress performance depends heavily on caching. A well-configured caching stack eliminates most database queries and PHP execution for repeat visitors. Look for:
- Server-level page caching: Nginx FastCGI cache or a similar reverse proxy cache that serves cached pages without invoking PHP at all. This is the biggest performance win for WordPress.
- Object caching: Memcached or Redis for storing database query results in memory. WordPress core and WooCommerce benefit significantly from object caching because they run many small repeated queries.
- OPcache: PHP’s built-in bytecode cache. If OPcache is disabled or undersized, every PHP request recompiles every included file. This is a basic configuration that every host should have enabled, but the allocated memory varies.
A host that provides all three caching layers with adequate memory allocation will deliver better performance than a host with faster raw hardware but no caching.
Security layers
WordPress is the most popular CMS on the internet, which makes it the most targeted. The hosting stack should include security beyond what WordPress provides itself:
- Firewall: Both network-level (blocks unauthorized traffic before it reaches the application) and application-level (detects and blocks attack patterns in HTTP requests).
- Bot detection: Automated tools that identify and challenge suspicious traffic. Brute force login attempts, vulnerability scanners, and content scrapers generate significant load on WordPress sites even when they do not succeed.
- Malware detection: Monitoring for compromised files and automated response when something is detected.
- Automatic updates: WordPress core, and ideally plugin and theme updates, applied promptly when security patches are released.
These are not nice-to-have features. They are essential for any WordPress site that is publicly accessible.
Backup frequency and retention
Backups are not a feature to check off a list – the details matter. Daily backups with 14-day retention is a reasonable baseline. Ask whether backups include both files and database, whether they are stored on separate infrastructure from the hosting server, and how restoration works.
Management scope
“Managed” hosting varies enormously in what is actually managed. Some hosts manage the server but leave WordPress to you. Others manage WordPress updates, plugin compatibility, and security scanning. Know what you are getting before you need support.
The "unlimited" problem
Many hosting providers advertise unlimited storage, unlimited bandwidth, unlimited websites, or all three. This is marketing, not engineering. Servers have finite resources, and a host that claims unlimited everything is relying on the statistical reality that most accounts use very little.
The problem emerges when your site actually needs resources. A WooCommerce store processing hundreds of orders per day, a membership site with thousands of concurrent logged-in users, or a content site receiving a traffic spike from social media will hit real limits regardless of what the marketing page says. At that point, you either get throttled (silently), asked to upgrade to a more expensive plan, or told your usage violates the terms of service.
Hosts that specify exact allocations – a specific number of CPU cores, a specific amount of RAM, a specific I/O bandwidth limit – are being honest about what the server can deliver. You can plan around known limits. You cannot plan around “unlimited” until you discover where the real limit is.
Where Hostney sits
Hostney is managed cloud WordPress hosting running on cloud infrastructure. Each account runs in its own Podman container with dedicated resources enforced at the kernel level through systemd cgroups.
Isolation: Each account gets its own process namespace, mount namespace, and network namespace. Your PHP processes, your filesystem, and your network connections are separated from every other account. On top of containers, SELinux runs in enforcing mode as an additional mandatory access control layer. Dangerous Linux capabilities are dropped from each container, and the no-new-privileges flag prevents privilege escalation.
Resource allocation: Plans specify exact resources – CPU cores, RAM, I/O bandwidth, and IOPS. These are not soft limits that flex under pressure. They are enforced by systemd cgroups at the kernel level. Swap is disabled per-container to prevent I/O thrashing when memory is under pressure. Your allocated resources are yours regardless of what other accounts on the same server are doing.
Storage: All servers run NVMe drives. I/O bandwidth and IOPS limits are allocated per-plan and enforced per-device, so one account running heavy database imports cannot saturate the disk for other accounts.
Caching: Nginx page caching at the server level, Memcached for object caching (on eligible plans), and per-container OPcache with plan-specific memory allocation. PHP JIT compilation is available on higher-tier plans for PHP 8.0+.
Security: Bot detection runs at the edge with multiple detection layers including rate limiting, honeypot traps, scanner detection, and a machine learning model that scores IP behavior. Malware detection monitors files in real time. All servers run firewalld with strict default rules.
Management: WordPress deployment, PHP version management (5.6 through 8.5), SSL certificates, DNS, backups, cron jobs, and server-level configuration are handled through the control panel. An AI assistant named Ellie can walk you through 80+ server management tasks through natural language. You manage your WordPress content and plugins; the platform manages everything underneath.
What Hostney does not include: Email hosting (we recommend a dedicated email provider – bundling email with hosting creates unnecessarily coupled infrastructure), domain registration (coming soon), and cPanel (the control panel is built specifically for this stack).
Summary
Cloud WordPress hosting means your site runs on virtualized infrastructure with hardware abstraction, but the term covers a wide range of implementations. The differences that matter are isolation model (filesystem virtualization vs containers vs virtual machines), resource allocation (dedicated vs shared, with real numbers vs “unlimited”), storage type (NVMe vs SATA SSD vs HDD), caching stack configuration, and security layers.
Traditional shared hosting is the most affordable option but provides the weakest isolation and shares resources most aggressively. VPS gives you full control and strong isolation but requires you to manage the entire server stack. Managed cloud hosting sits between the two – container-grade isolation and dedicated resources without the server administration burden.
When evaluating hosts, look past the marketing terms. Ask about isolation model, resource allocation specifics, storage type, caching layers, and what “managed” actually covers. The answers tell you more about what your site will experience than any benchmark or uptime guarantee.