Shared Hosting vs VPS or a Cloud Server: What Your Site Actually Needs

Shared hosting, a VPS and a cloud server look like three power tiers on a price list, but they differ in three places: what separates you from neighbours on the same machine, where the account runs into its limit, and who updates the software.

On a Wednesday morning around ten the site becomes slow — not dead, just slow: the page opens in five seconds, the admin panel refuses to save an entry, and after half an hour everything is fine again, as if nothing had happened. The host's support replies after lunch that the account has exceeded its plan's limits, and offers a move to the next tier, which costs three times as much and is called a “cloud server” on the price list.

Shared hosting vs VPS and a cloud server sit on the price list stacked one under another as three power tiers of the same service, even though they are three different technical arrangements that differ in three specific places. At this point most buyers do not know what they are actually buying, and that is not a rebuke: you can check each of those three places with your own site's numbers in hand, and none of them can be read off the plan's name.

Shared hosting vs VPS: the three places the plans actually differ

The first is isolation, that is, what exactly separates your site from other clients' sites on the same physical machine. On shared hosting it is an account in the operating system together with a resource container placed at kernel level; with a VPS it is a separate virtual machine with its own operating system; on a cloud server it is the same virtual machine, only ordered and billed differently. The practical difference among these three is how far a neighbour's load can affect your site, and how much of the machine you are even allowed to change when the default configuration turns out not to fit.

The second place is the limit — where the account runs into it and how that shows up — and this is where most of the misunderstanding arises, because people expect overload to mean a slow page, when in some cases it means a page that does not open at all and returns an error code the buyer has never seen even once in their life. The third place is responsibility: who updates the operating system, who the web server, who PHP and who the site itself, and this is where VPS buyers miscalculate most often, because root access is not a gift the host hands over with a more powerful machine — it is the duty list moving from them to you, and it happens quietly, in the same minute the password is sent.

Everything else that takes up rows in a hosting comparison table is either the same on every plan, or is not what fails: NVMe disks are practically everywhere today, but “unlimited traffic” is a claim about the volume of data transferred, not about resources, and it usually sits right next to a table in which those resources are counted down to the last megabyte. 99.9%, for its part, is a figure with a precise legal meaning and an exclusions list underneath it, and most buyers think it covers something quite different from what it actually covers.

Shared hosting: one server, many accounts

Shared hosting is a user account on a machine that is also home to hundreds more like it, and Latvian hosts call this same product three different names: CloudHosting writes it as shared hosting, Hostnet as divided hosting, AlphaHost as virtual hosting. Technically all three mean the same arrangement — you own the account, not the machine, you manage the site through cPanel or a similar panel, and everything beneath that panel belongs to someone else.

What separates you from your neighbours is specific software, not a promise on the price list, and it is worth knowing by name. Most cPanel hosts run CloudLinux, in which each account has its own copy of the filesystem: CloudLinux's documentation on CageFS writes that users cannot see or detect other users and their usernames on the server, cannot read the web server configuration, and see only a truncated process list. The second layer is LVE — a kernel-level resource container which sets CPU, memory, I/O and process limits per account precisely so that, in the documentation's own wording, no single site can bring down the entire web server.

The third layer is the PHP setting open_basedir, and here it is worth knowing what the PHP manual itself says, not the host's marketing: it is an additional security net which is by no means comprehensive and cannot be relied on when security is genuinely needed. In the same place the manual warns that disabling functions with disable_functions can also be bypassed, and that in a shared environment it is not a sufficient security measure. None of this is an argument against shared hosting; it is an argument that isolation here is given by the kernel and the filesystem, not by one line in a configuration file, and that a host who answers a question about isolation with the word “safe” has not answered it.

What you cannot choose on shared hosting matters as much as what you can: the kernel is one for every account, so you will not change the kernel version; the list of PHP versions is set by the host and usually lags the latest by one or two; the web server is whatever is installed, so the answer to a question about a package that is not there will be “no”, not “install it”. A shared server is also the place where, in an incident, the host has to check neighbouring accounts, because an attacker who has got into one account tries the same with the neighbours; what to do when that has already happened we have described in the article on a hacked WordPress site. None of these limits is a defect: it is exactly the arrangement that makes this product cheap, and the buyer who understands that gains from it.

What happens when an account hits its limit

A shared plan has several different limits; they are reached independently of one another and show up entirely differently, so the symptom is a useful diagnostic tool. CloudLinux's default limits per account are 100% of one CPU core, 1 GB of physical memory, 1024 KB/s of I/O, a hundred processes and twenty entry processes, and it is the last of those figures that surprises buyers, because twenty sounds like a ridiculously small number for a site that receives ten thousand visitors a month.

The explanation is that an entry process is not a visitor: it is a process that enters the account from outside — a new HTTP request to a PHP script, an SSH session or a cron job — while processes that arise already inside count against an entirely different limit. When the entry-process count is reached, the Apache module no longer admits the next request and returns the error 508 Resource Limit Reached, and CloudLinux describes this in its knowledge base without softening: a site that consumes too many resources stops working, but the other clients on the same server continue to operate normally. That is exactly the point of the mechanism — cut off one account so that the machine does not stop.

The other limits show up differently, and from the symptom you can read which one has been reached before anyone starts guessing: CPU and I/O are not cut off but throttled, so the page becomes slow and eventually opens, while memory and process limits usually produce a 500 or a 503, that is, a page that does not open at all. On LiteSpeed servers entry processes are counted differently than on Apache, so there the same figure must not be translated as a number of concurrent visitors, and that is one of the commoner ways a correct number ends up in the wrong sentence.

There is a fourth limit as well, which has nothing to do with load and therefore creeps up unexpectedly: an inode is a filesystem record for one file or directory, so the inode count on an account is simply the number of files and folders, including a mailbox nobody has cleaned for years. Latvia's Hostnet publishes inodes openly on its price list — 400,000 on the MINI plan, 600,000 on PLUS, 800,000 on PRO — and in the same table MINI and PLUS stand next to 100% of one core and 2048 MB of memory, while PRO has 200% and 3072 MB, and all three have 10 MB/s of I/O and 150 concurrent connections, while monthly traffic is “unlimited”. This combination is the real lesson about the word “unlimited” on a hosting price list: it applies to the volume of data transferred, and every other limit sits right there beside it, counted out to the last figure.

VPS: your own operating system on shared hardware

A VPS (virtual private server) is a virtual machine in which you own the operating system, root access and the ability to install what you need, and hosts write it both expanded and as the English abbreviation: Tet expands it on its page as Virtual Private Server, but calls the service itself virtual server rental. What the name does not say is two technical questions that decide how much of “your own server” is really yours.

The first question is whether the virtualisation is at hardware or operating-system level. KVM is a Linux kernel module that uses the processor's virtualisation extensions and gives each guest its own virtualised hardware — a network card, a disk, a video adapter — and, most importantly, its own kernel, so unmodified Windows can run on it too. LXC and related containers are a different mechanism: they use Linux namespaces, cgroups and capability restrictions to create an environment as close as possible to a separate Linux installation, but without a separate kernel. The consequences are simple and practical — in a container the kernel version, kernel modules and kernel vulnerabilities remain shared with the host machine, so part of what you thought you were buying actually stayed with the neighbours.

The second question is about the processor, because the words “your own server” do not mean your own processor. Hetzner cloud servers have two separate product lines: on shared-resource plans, compute resources are divided among all instances on the same physical server, with a baseline performance and the ability to exceed it for a time, while on dedicated-resource plans one vCPU is one thread of a physical core and yours alone. DigitalOcean puts it even more clearly: on a shared plan the thread may be shared with others, and if neighbours are under heavy load the instance receives slices of the thread rather than full access, so in practice full access is possible but not guaranteed.

How many neighbours sit on one machine is published by none of the large providers, and the ratio you will find in blogs is nobody's published measurement, so it is not worth citing or believing. The only documented figure you can refer to is whether the plan promises shared or dedicated resources, and that difference is usually written quite openly — under two different product names, two different specifications, and a several-fold price difference.

A cloud server is the same VPS, bought differently

A cloud server is technically a virtual machine on a hypervisor, that is, exactly the same thing as a VPS, and in Latvia it is explained the same way: CloudHosting in its FAQ writes that a Cloud server, or cloud server, is a virtual server, and Hetzner's documentation opens with the same sentence — cloud servers are virtual machines that run on physical servers. If you expect two different pieces of hardware from two offers, there is no basis for the expectation.

The difference is not in the hardware but in the way you buy, and the most precise description is still the definition from NIST, the US National Institute of Standards and Technology, which the industry continues to cite: a cloud has five characteristics — on-demand self-service, broad network access, resource pooling with multiple tenants, rapid elasticity and measured service. In practice that means an API with which a machine can be created and destroyed programmatically, hourly billing with a monthly cap, and extras that can be attached separately: snapshots, separate block storage, a movable IP address and a load balancer.

Each of these extras has limits worth knowing before the purchase, not a month after it. A Hetzner plan change cannot reduce disk size even if only part of it is in use; after a disk increase you have to grow the partition yourself in rescue mode, and the plan change itself is listed as an exclusion from the availability guarantee. A snapshot, in turn, is not a backup, even though the market uses the two words as synonyms: Hetzner snapshots do not include attached volumes, and consistency is not guaranteed if the server is running, so it is a good thing before an update and a bad thing as the only copy of the data. A movable IPv4 address is charged separately, as is the primary IPv4 address on the instance itself.

A five-page company site usually uses none of these extras, and that is the most honest sentence in this section: if the site never changes capacity, never fails over to a second machine and is never attached to an API, then a cloud server and a VPS of the same size are the same machine with two different bills. That is not an argument against the cloud, because where elasticity is used, it costs less than a reserve held permanently. It is an argument that the choice is between capabilities you will actually use, not between words that sound modern.

Who updates what

The largest practical difference among the three plans is not speed but the split of duties, and the cloud providers themselves have formulated it most clearly. AWS's shared responsibility model divides everything in two: security of the cloud is AWS's responsibility — the hardware, software, networking and facilities in which the services run — but security in the cloud is the customer's. On the patching question it is even written separately and word for word: AWS is responsible for infrastructure patches and defects, but the customer is responsible for patches to their guest operating system and their applications.

On shared hosting this layer belongs to the host, and that is this product's greatest value, which few people think about: they update the kernel, the web server and PHP, and you know nothing about it until something breaks. On an unmanaged VPS or cloud server all of that passed to you together with the root password, and Hetzner says so from the other side in its terms: software, configuration and system settings introduced by the client are not treated as an availability incident, so the provider is not responsible for them and they are not covered by any compensation.

The site itself remains your responsibility in all three cases, and that is the point at which offers have to be read carefully, because the word “managed” in the industry usually means the operating system and server software, not the WordPress core, plugins and theme. Our own infrastructure rental's maintenance also includes operating-system and server-software updates, security configuration, backups with a tested restore, monitoring and response under an SLA — and it does not say that we update your plugins, because that is a different line on the price list and a different contract, and we say so plainly so that nobody discovers this boundary on the day of an incident.

The practical test before an order is one question, asked directly and in three parts: who updates the operating system, who the web server and PHP, and who the site's code. If the answer to any of the three is “you yourself”, then that is work that needs either a person with time or a contract with someone else, and neither of the two is free. Unanswered, this question does not disappear — it comes back after eighteen months as a system into which nobody has put a single patch, and by then it is no longer a question of plan choice.

What 99.9% means, and what it does not cover

An availability percentage on a price list looks like a promise, but it is in fact a formula with a list of exclusions. Hetzner's cloud-server service level agreement promises 99.9% per month for a single instance, and Hetzner itself, in its explanation, calculates what the figure means in practice: in a thirty-day month, 43 minutes of downtime are still within the agreement, that is, they are not a breach and no compensation is provided for them.

The compensation itself is just as specific and much smaller than people expect: it is calculated from the minutes above the threshold, converted into hours and multiplied by the instance's hourly rate, and paid as a credit against future usage, not as money. In Hetzner's own example, 185 minutes of downtime give 142 minutes above the threshold, or 2.37 hours, and a credit of €0.87, which is less than an hour's work spent calculating it. Lost turnover, lost orders and dropped search rankings are nowhere inside it, and no hosting agreement we have read covers them.

The exclusions list is as important as the figure, because it is what determines how often the figure is applied at all: scheduled maintenance announced in advance, the client's own software and configuration, a plan change requested by the client, live migrations for host-machine stability, and the network beyond the provider's core network all remain outside the agreement. All of this is written honestly and openly, and a simple conclusion follows: the percentage applies to the machine, not to your site, so a site that went down after a failed update is entirely outside this contract.

99.9% is not an industry constant either, though it is often used as if it were. Amazon EC2's agreement for a single instance promises 99.5%, and 99.99% only if instances are placed in at least two availability zones — that is, two different contracts with two different figures, and the sentence “the industry has 99.9%” flattens both into one. On shared hosting there is usually no such document at all — only a figure on the website with no definition, no measurement method and no consequences, and that is a claim, not a commitment.

How to measure your site before you choose

The figure that decides it is not monthly visitor counts, even though that is the one the buyer knows by heart and the one the salesperson asks first. What decides it is the number of concurrent PHP requests at the moment load is heaviest, and that is an entirely different quantity, which correlates poorly with monthly traffic.

Two sites with the same traffic can sit on opposite sides of the same limit, and the difference is how long each page holds a process. A static, cached company site is served mostly by the web server without PHP, so it consumes almost no entry processes and ten thousand visitors a month mean nothing to it. An online store in which every cart, every sign-in and every return from a payment gateway holds a PHP process for two seconds can hit that same limit already at twenty concurrent buyers, and that is why, in a campaign's first hour, it is precisely the shops that have paid for the campaign that go down.

Alongside that figure it is worth reading three more, and all three are available without a developer's help. The first is the database size and the slowest query in it, because that is usually the real cause of slowness, not the machine's power. The second is the file count on the account, because sites with large media libraries and an old mailbox hit the inode limit unexpectedly and without warning. The third is what the site does outside the browser — cron jobs, mail sending, integrations with an accounting system — because those processes also enter the account from outside and count against the same limit you have just measured for buyers.

All four figures can be read in one afternoon from the hosting panel's statistics and the server logs, and that is the only place where your site's real load is, not a guess about it. The plan's name does not know these figures; a salesperson who has not seen them does not either; and a conversation that starts with them usually ends with a cheaper answer than a conversation that starts with a list of plans.

When a move helps, and when it solves nothing

Moving to a larger plan is the right answer considerably less often than it is offered, and the first case in which it does not help is also the commonest. If the site is slow because one query reads the entire product table on every page open, a more powerful machine will execute it faster, the problem will remain, and you will have bought time, not a solution. The same applies to forty plugins, to unprocessed images at full size, and to a theme that rebuilds the menu from scratch on every request.

An upgrade is the right answer when the limit has been reached with correct code: if the site is cached, the queries are in order and the account still runs into the entry-process count, then that is a plan limit, not a defect in the code, and there is nothing left to optimise. Likewise, an upgrade is the only answer when you need something a shared account cannot install — a different PHP version, a queue worker, Redis, your own cron at a one-minute interval — or when an industry, procurement or client requirement specifies the country in which the data physically sits.

There is a third case as well, which salespeople discuss rarely because it reduces the bill: sometimes the right move is down. A site that was moved to a VPS three years ago because of one advertising campaign and has since received two hundred visitors a day is paying for a machine it does not use, and paying twice — with money on the invoice and with a person's time, because a VPS operating system has to be updated by someone even when nobody is coming in.

Before any move it is worth settling one more question that has nothing to do with capacity at all: in whose name the domain is registered and in whose name the hosting account stands. We have written about that separately in the article on mistakes when commissioning a website, and this is one of those questions that can no longer be repaired quickly on migration day, because the answer depends on a person you may no longer be speaking to.

What you are buying when the plan is called managed

The price difference between an unmanaged and a managed machine is large, and it is not a markup on the same goods, so it is fair to put both figures side by side. On the Hetzner price list that took effect on 15 June 2026, a CX23 cloud server with two vCPU, four gigabytes of memory and a 40 GB disk costs €5.49 a month excluding VAT, and the primary IPv4 address comes on top at €0.50 a month. Our infrastructure rental starts from €45 a month, and the difference between those two figures is exactly what this section is about.

The difference is work, and it can be listed item by item: operating-system and server-software updates, security configuration, monitoring with Zabbix around the clock and response under an SLA, backups every day with 30-day retention and a regularly tested restore, and for especially critical infrastructure — up to 365 days and in two different European Union countries. Preparing the environment and moving it takes 3–10 days, we run the migration in parallel and switch DNS in a planned window, and afterwards you have one named contact, not a support ticket in another time zone.

The other side has to be said honestly as well, because without it this section would be a price list with an article around it. If your site is static, traffic is small and nobody ever asks for a PHP version the host does not have, then shared hosting at a few euros a month is the right answer, and a managed environment would be a fee for peace of mind you already have. We say this also to people who call with that question, because selling an environment that is not used is a short-term transaction — a year later it comes back as a question about what was actually being paid for, and there is no good answer to that.

If you are not sure which side of this line your site is on, those four figures can be read together: write to us, and we will tell you what your current account's statistics show and which limit is nearest — even if the answer turns out to be that there is no need to move, and the money is better invested in the site's speed.