Hosting is sold on a few headline words: unlimited, guaranteed, secure, cloud. They are real words with real meanings, but in marketing they are stretched to cover things the contract does not promise. After years of reading support tickets from people who believed the headline, we have a short list of claims that cause the most expensive misunderstandings.
There are ten here, each with a verdict and the reasoning behind it. Most are myths, two are only partly wrong, and one is mostly a myth with a narrow exception. None of this is an argument against any type of plan. Shared hosting, VPS, dedicated and cloud all have good uses. The point is to know what you are actually buying, and who is responsible for what once the invoice is paid.
1. "Unlimited" hosting is truly unlimited
Myth
Every hosting server is a physical machine with a finite amount of disk, memory and network. "Unlimited" on a sales page means the provider has not put a number on it, and that is a different thing from there being no limit.
The limits show up elsewhere in the contract. Fair-use clauses, caps on the number of files (inodes), restrictions on what kinds of files you may store, and CPU or memory throttling all apply. A site that grows quickly or serves large downloads will find the real boundary, usually by receiving a polite email asking it to reduce usage. Read the acceptable-use policy, not the headline.
The economics explain why. A shared server is divided among many accounts on the assumption that most use a small fraction of what they could. If every customer truly used unlimited disk, the plan would lose money, so the provider leaves the number unspecified and relies on the average staying low. That is a reasonable business model, and it works for ordinary sites. It stops working for the unusual one.
The usual first collision is inodes, the count of files and directories on the account. A site with a large image library, a mail archive or years of cache files can reach a limit of a few hundred thousand without using much disk at all. Another is CPU: a plugin that runs a heavy query on every page view will get the account throttled long before disk matters. Storage of backups, media archives and files unrelated to the site is often prohibited outright, however much space seems free.
2. A VPS is always faster than shared hosting
Myth
A VPS gives you guaranteed resources, which is not the same as speed. A tidy shared server with fast storage, current PHP and good caching can outperform a poorly configured VPS with a default web server and no tuning.
Where a VPS wins is consistency: you are not competing with a neighbour for CPU at the wrong moment, and you can change the stack. If nobody on your side is going to tune it, you are paying for potential you will not use.
It helps to separate three things people lump together as "fast": how quickly the server starts producing a page (time to first byte), how heavy the page is, and how steady performance is over the day. A VPS mostly affects the third. The first depends on the software stack, and the second has nothing to do with the server at all.
Consider two examples, with numbers that are illustrative. A managed shared server runs PHP 8.x with an opcode cache, object caching and a server-level page cache, all pre-configured by the host. A WordPress site there might answer in 150 to 300 ms. The same site moved to an entry-level VPS, installed with a stock web server, no page cache and the database on default settings, could easily take 600 ms or more on an uncached page, because nobody did the work the shared host had done for you. The VPS has more guaranteed resources but spends them inefficiently.
The real advantages of a VPS are these: guaranteed CPU and memory, so a neighbour's traffic spike does not slow you; root access, so you can install what you need; and isolation, so another customer's hacked site cannot consume your resources. The real costs are the other side of the same coin. You are now the system administrator: updating the operating system, configuring the firewall, tuning the database, monitoring disk space, planning backups. A managed VPS shifts some of that to the host, at a price.
A good test for whether one is needed is symptoms, not ambition. If the site is slow at the same times every day, and the shared plan's resource graph shows throttling at those times, a VPS is a reasonable next step. If it is slow all the time, look at caching, image sizes and plugins first. The page weight tool will tell you whether the problem is the page and not the machine.
3. The backups from my host are enough
Myth
Host backups are valuable and you should use them, but they usually live in the same data centre, often under the same account. If the account is compromised, suspended or deleted, or if the facility has a serious incident, the backups can go with it.
The old rule still holds: keep copies in more than one place, at least one of them somewhere you control. And try restoring one now and then.
Think about what kinds of failure a host backup is designed to cover. It is excellent for the everyday ones: you deleted a file, a plugin update broke the site, a database table was corrupted. Restoring last night's copy takes a few minutes and everyone is happy. It is far less reliable for the rare, severe ones, which are the ones that end businesses.
- Account takeover. An attacker with your control panel login can often delete the site and its backups in one session, because both sit behind the same login.
- Billing or policy suspension. If the account is suspended, the backup system is suspended with it, at the moment you most need it.
- Provider-level incident. Fire, flood or a failed storage system in one data centre can take the servers and the backup copies together, if they share a building.
- Retention. Many hosts keep only a few days of copies. Malware that sat unnoticed for three weeks will have been backed up for three weeks.
The widely used guide is the 3-2-1 rule: three copies of your data, on two different kinds of storage, with one copy off-site. For a small site that translates to: the live site, the host's own backup, and a copy you pull to somewhere else, such as a different provider's storage or your own computer. A scheduled job that exports the database and archives the files, then uploads them off the server, covers it. The cron helper can build the schedule.
The step most people skip is the test. A backup you have never restored is a hope. Once or twice a year, restore the files and database into a scratch location or a staging site, and check that it loads, that the images are there and that the admin login works. It is the only way to find out that the database dump was empty, or that the archive silently excluded the uploads folder.
4. 99.9% uptime means only a few minutes of downtime
Myth
It allows about 8.8 hours of downtime per year, or roughly 43 minutes a month. Reaching 99.99% shrinks that to around 52 minutes a year, which is much harder and much more expensive to deliver.
Look at what the guarantee actually covers. Scheduled maintenance is often excluded, and the remedy for a breach is usually a small service credit. It is a promise to try, with a discount if they fail.
The arithmetic is plain. A year has about 525,600 minutes. Allow 0.1 per cent of those and you get roughly 526 minutes, or just under nine hours. Per month that is about 43 minutes. Each extra nine divides the allowance by ten: 99.99% leaves around 53 minutes a year, and 99.999% about five minutes. The jump in difficulty between each step is large, because eliminating the last few minutes means removing every single point of failure, including the human one.
The percentage is only half the story; the other half is the definition. A typical service level agreement measures availability of the network or the hardware, not of your website. If your site is down because of a plugin, a full disk or an overloaded database, that probably does not count. Scheduled maintenance windows are usually excluded, and so are problems the provider calls "outside our control". The compensation is normally a credit against future fees, often a small percentage of one month's price, and you usually have to claim it within a deadline.
That is not worthless, but it is an incentive and not insurance. If an hour of downtime costs your business more than a year of hosting, the answer is not a better SLA, it is redundancy and monitoring that you control. The uptime calculator converts any percentage to minutes, and a free external monitor will tell you what your site actually did, which is the only number that matters.
5. More RAM always makes a site faster
Myth
Memory helps when a site is running out of it, and the symptom is obvious: crashes, killed processes, swapping to disk. Beyond that point, extra RAM sits idle. A site that is slow because of one expensive database query or a huge page will be just as slow with four times the memory.
Before paying for more, look at the usage graph. If memory never gets near the ceiling, the bottleneck is elsewhere.
Think of RAM as workbench space. A bigger bench lets you lay out more tools at once, which saves time if you were constantly clearing the old ones away. If the bench was already big enough, a bigger one does nothing for the speed at which you saw the wood. Slow sites are usually limited by something other than space: a single-threaded task, a query that scans a whole table, a plugin calling a slow external service, or a page that sends three megabytes of images.
How to tell what is actually going on, on a VPS or dedicated server:
free -h
# "available" is the number to watch, not "free"
top
# press M to sort by memory; look at the load average too
dmesg | grep -i "out of memory"
# evidence that the kernel killed a process for lack of RAM
vmstat 5 5
# non-zero si/so columns mean the machine is swappingIf available memory stays comfortably positive, swap is not in use and nothing has been killed, more RAM will not help. If the load average is high while memory is low in use, the CPU or disk is the constraint. On shared hosting you may not have a shell, but the control panel usually shows resource graphs and an error log; "memory limit exhausted" in the PHP log is the specific sign that a script hit its allowance, which is a PHP setting you can often raise without a bigger plan.
6. Shared hosting is insecure by nature
Partly myth
Shared hosting has a bigger attack surface than a private server, because many customers live on one machine. Good hosts counter this with account isolation, hardened configurations, malware scanning and quick patching. A well-run shared server can be safer than a poorly maintained private one.
The weak point is usually your own account: old plugins, reused passwords, loose permissions. Those are as dangerous on any kind of hosting.
The "partly" is fair. A shared server does carry risks that a private one does not, and pretending otherwise would be unhelpful. Hundreds of accounts share a kernel, and if isolation is poorly done, a compromised neighbour can sometimes read files, or exhaust resources, or send spam from a shared IP. Older, cheaper setups where every site ran as the same user were notorious for this. A single infected site could infect everything on the machine.
Modern, competently run shared hosting has closed most of those gaps. Each account runs as its own user, often inside a container or jailed file system, so one site cannot read another's files. PHP runs under that user, not as a shared web server user. Web application firewalls block known attack patterns before they reach the site, and scanners look for malware signatures. The host patches the operating system and server software for everyone at once, which is something a small business with its own server may not do for months.
Now compare where real compromises start. Most hacked small sites are broken into through the application, not the server: an outdated plugin with a known flaw, a theme downloaded from an unofficial source, an admin account with a password reused from a breached service, a file upload form with no restrictions, or permissions set to 777 because that made an error go away. Those vulnerabilities travel with the site wherever it is hosted.
So the approach that works to shared hosting is to choose a host that visibly cares about isolation, keep your own software updated, use unique passwords with two-factor login on the panel and the CMS admin, remove plugins you do not use, and keep off-server backups. Do that and the "insecure by nature" worry shrinks to a theoretical one.
7. A dedicated server is automatically more secure
Myth
Dedicated hardware removes neighbours but also removes the person who patches the system, unless you pay for management. An unmanaged dedicated server with default settings and an open database port is a very good target.
Security comes from updates, restricted access and monitoring. The type of plan only decides who is responsible for providing them.
Dedicated does remove one class of risk: other customers on the same operating system. That is a real benefit for organisations with strict isolation requirements. But it also removes the safety net, and the net is where most of the protection came from. On shared hosting the provider's staff watch the platform day and night; on an unmanaged dedicated server, the only person watching is you.
Here is what an unmanaged server's first week looks like. Within minutes of getting a public IP, automated scanners find it. Log lines like these appear in /var/log/auth.log almost immediately:
Failed password for root from 198.51.100.77 port 52114 ssh2
Failed password for invalid user admin from 198.51.100.77 port 52118 ssh2That is normal background noise, and a server with key-only SSH and a firewall shrugs it off. A server with password login for root enabled, an old control panel version and a database listening on all interfaces will not shrug it off. Bots try the default combinations, and some of them work.
A minimum for any server you administer: key-based SSH with password login disabled, a firewall that opens only the ports you use, the database bound to localhost, automatic security updates, and a way to be told when something odd happens. If that list sounds like a part-time job, a managed plan is the right answer, and its extra cost is mostly the price of that job being done.
8. Cloud hosting never goes down
Myth
Large providers do have outages, and several well-known ones have taken big parts of the internet offline for hours. Cloud platforms give you tools for resilience, such as multiple zones and automatic failover, but you have to design for them and pay for them.
A site running on a single cloud server in a single zone has about the same weakness as a single physical server.
What cloud offers is building blocks, not a promise. A virtual server in the cloud is still a server: it runs on a physical host that can fail, in a data centre that can lose power or networking, managed by software that can contain bugs. What differs is that you can replace a broken one in minutes, and you can place several in separate failure domains. The word "zone" (or "availability zone") means a separate data centre or part of one, with independent power and cooling, within the same region.
Even the two-zone design has traps. The web servers may be redundant while the database is a single instance, in which case the database is the weak point. The load balancer, the DNS provider and the authentication service can each be a single point of failure. Some outages have hit a whole region, or a shared control plane, so that even correctly designed customers could not launch replacements. Others came from a bad configuration change pushed by the provider itself. The right attitude is that a major cloud has better reliability than most people can build, and still fails sometimes.
For a small site, you can get a good share of the benefit cheaply: a recent snapshot or backup stored in another region, short DNS TTLs so you can repoint quickly, and an external monitor that alerts you. The TTL planner helps with the DNS side. Full multi-zone designs cost real money and engineering time, and for a brochure site they are often worse value than a fast restore plan. Decide how long you can afford to be down, then spend accordingly.
9. Free hosting is fine for a business site
Mostly myth
Free plans suit experiments and learning. For a business, the trade-offs add up: adverts you did not choose, no custom email, tight limits, little or no support, and the risk that the service changes or disappears.
If the site earns you money or reputation, the cost of a basic paid plan is small compared with one lost customer.
The "mostly" is deliberate. Free hosting is perfectly fine for a student project, a practice site for learning WordPress, a personal page or a test of an idea. A static site on a free tier from a reputable platform can be reliable enough for a modest purpose, and some businesses run a simple landing page that way. What fails is the assumption that free is the same as paid with the price removed.
The costs show up in specific places. Email is the first: many free plans do not include mailboxes on your own domain, so you end up using a free webmail address on business cards, which costs trust with customers. Performance is the next: free tiers are heavily oversubscribed and may sleep when idle, so the first visitor after an idle spell waits several seconds. Then comes support. When something breaks at nine on a Monday morning, a free plan generally offers a forum or nothing. And control: the terms can change, the plan can be withdrawn, an account can be closed for reasons you cannot appeal, and exporting your data may be hard.
Put numbers on it. A basic paid shared plan costs very little per month relative to the value of a single customer in most trades. If you can name the revenue a day of downtime would cost, the comparison is easy. The better path is to use free tiers to learn and prototype, then move to a paid plan before real customers arrive, taking care to keep your domain registered separately so the move is painless.
10. My host will protect me from hackers automatically
Myth
Hosts secure the servers, the network and, to some extent, the account boundaries. They generally cannot protect you from vulnerable plugins you installed, stolen passwords or insecure code, because that is your layer.
Many offer extras such as scanners and firewalls. They help, but think of them as a seat belt and not as a driver.
The key idea is the shared responsibility model. The host looks after the layers it controls: physical security, the network, the operating system, the web server software and the account separation. You look after what you put on top: the CMS, its plugins and themes, the code you or a developer wrote, and the credentials that unlock your account. A host cannot update your plugins for you in most cases, because an automatic update can break a site, and breaking customer sites is also a failure.
Security extras do real work, but within limits. A web application firewall blocks common attack patterns, though a determined attacker, or a flaw it has no rule for, can pass it. Malware scanners find known signatures and recently changed files, but a fresh variant or a cleverly hidden backdoor may sit there for weeks. Some hosts will clean an infected site for a fee, which is useful, but cleaning without closing the original hole just invites reinfection.
Checking it yourself
You do not have to take a sales page on trust, and most of these claims can be tested in a few minutes.
- Open the terms of service and the acceptable-use policy. Search for "unlimited", "fair use", "inode", "backup" and "service level". Note the numbers, the exclusions and the credit amounts.
- Check your response time from outside:
curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s total: %{time_total}s\n" https://example.com/. Run it five times at different hours; the spread tells you about consistency. - Look at headers with
curl -I https://example.com/to see the server software and whether caching headers are present. - Find the resource graphs in your control panel and look at the highest points, not the averages.
- Confirm you can actually download a backup, and where it is stored. If you cannot, set up your own.
- Run a free uptime monitor against your site for a month, then compare its numbers with what the provider reports.
If something looks off, the troubleshooting guide is a good first stop, and the hosting quiz can help you decide which kind of plan fits your site.