Hosting is the item that causes the most quiet regret in a website project. Nobody thinks about it while deciding, everyone picks the cheapest option, and the subject only comes back to the table when the site goes down on a Monday morning or when the developer says they cannot install what they need.
The choice is not hard. What gets in the way is the marketing vocabulary of the industry, which sells "unlimited cloud" and "turbo SSD" without explaining the only thing that matters: how much machine you are renting and how much control you have over it.
What you are actually buying
You are renting four things at once, and different plans trade one for another:
- Compute resources. CPU, memory, disk and bandwidth. This determines how many simultaneous visitors the site handles before slowing down.
- Control. Which language versions you choose, which services you can install, whether you have administrator access to the system.
- Responsibility. Who patches the operating system, configures the firewall, renews the certificate, and wakes up at 3am when it falls over.
- Isolation. How much other customers' behaviour affects your site.
The entire difference between shared, VPS and cloud lies in how those four are distributed. More control always arrives with more responsibility. No plan gives you full power and full care at the same price.
One thing almost nobody checks before signing: whose name the account is in. If hosting, domain and repository all sit in a third party's account, you have an ownership problem, not an infrastructure one, worth reading in who actually owns your website.
Shared hosting: when it is enough and when it starts to hurt
On shared hosting, dozens or hundreds of sites share the same physical server. You get a control panel, a folder, a database and a limit. The provider handles everything below that.
It is excellent in three situations: a brochure site with predictable, moderate traffic; a static or near-static site; and a tight budget. For a good share of small business websites, shared hosting runs the whole year with no drama at all.
It starts to hurt when you hit any of these signs:
- Slowness with no visible cause. Your site has not changed but crawls at specific hours. Usually a noisy neighbour: another customer on the same server eating resources.
- Limits you do not control. Maximum processes, simultaneous database connections, executions per minute. You hit the ceiling and the provider answers with a plan upgrade.
- Locked language versions. You need a PHP or Node version the panel does not offer.
- No access. No terminal, no installing services, no configuring cron the way you need, no tuning the web server.
- Manual deploys. If FTP is the only path, you have no pipeline, no easy rollback, and you depend on someone dragging files.
No single sign forces a move. Two or three together do.
VPS: the turning point
A VPS is a virtual slice of a physical server, with resources reserved for you and a whole operating system under your command. It is the first time you get real administrator access.
What changes in practice:
- You pick versions, install what you want, configure the web server your way.
- The resources are yours. The noisy neighbour stops being a problem.
- Automated deploys from a repository become trivial.
- You can run cache, queues, workers, your own database, things shared hosting will not allow.
And what becomes your problem: system security updates, firewall, SSH configuration, certificate renewal, monitoring and backups. A neglected VPS is less secure than a well-run shared host, because on shared hosting somebody is doing that for you.
There is a middle ground: managed VPS. You pay more and the provider keeps the system patched and monitored. For anyone without a technical person on hand, it usually has the best risk-to-cost ratio.
Whatever the model, the hygiene minimum is the same: properly configured HTTPS with security headers, detailed in HTTPS, HSTS and security headers.
Cloud and serverless: when it makes sense
"Cloud" has become a marketing word, and plenty of shared hosting sells itself as cloud. What defines real cloud is elasticity: the ability to scale resources up and down in minutes, paying for what you use, with managed services ready for databases, storage, queues and content delivery.
Cloud makes sense when at least one of these is true:
- Your traffic has large, unpredictable peaks, campaigns, seasonality, launches.
- You need genuine high availability, redundant across more than one zone.
- Your architecture has several parts that grow at different rates.
- You have someone who knows how to operate it.
That last item eliminates the most candidates. Cloud hands you power and hands back complexity: networking, permissions, usage-based billing. A misconfigured cloud account is the only kind that risks an unpleasant surprise at the end of the month.
There is one case, though, where cloud is the simple and cheap choice: a static site. If your site is generated at build time, finished HTML, no server rendering on every request, hosting it on a static platform with a global CDN is fast, resilient and often costs close to nothing. That is why modern React sites ship with static generation, as explained in why a React site does not show up on Google.
Comparing the three models
| Criterion | Shared | VPS | Cloud |
|---|---|---|---|
| Control over the environment | Low, panel only | High, system administrator | High to total, per service |
| Relative cost | Lowest, fixed | Middle, fixed | Variable, usage-based |
| Technical knowledge required | Little | Medium to high, unless managed | High |
| Resource isolation | Weak | Good | Very good |
| Elasticity under peaks | None | Manual, with brief downtime | Automatic |
| Who handles system security | The provider | You, unless managed | Split by layer |
| When to choose it | Brochure site, moderate traffic, lean budget | You need specific versions, automated deploys or more performance | Unpredictable peaks, high availability, or a static site on a CDN |
Server location and latency for a Brazilian audience
Physical distance between server and visitor costs time. Every request has to travel out and back, and the secure connection needs additional round trips before the first useful byte arrives.
For a mostly Brazilian audience, a server in Brazil noticeably reduces time to first byte compared with one in the United States or Europe. It is not the dominant speed factor, heavy images and too much JavaScript weigh more, but it is a fixed cost that shows up on every request and affects the loading metrics discussed in Core Web Vitals explained.
Two useful caveats. First, if your site is static and served from a CDN, the origin matters little: content is delivered from the node nearest the visitor. Second, if your audience is international, choosing Brazil only makes the experience worse for everyone. Decide by the real audience, not by where the company is registered.
Uptime, support and the fine print
Every provider advertises high availability. What differs is what is written under the number.
- What the guarantee covers. Usually only server unavailability, not slowness, not application errors, not scheduled maintenance windows.
- What the compensation is. Almost always proportional credit, not a refund. It does not cover the loss from the day your site was down.
- Support hours. Does 24/7 include Sunday at 4am? On which channel? In which language?
- Backups. Included? How often? Retained for how many days? Is restoring billed separately? A provider backup does not replace your own, as we argue in backup and continuity when the site goes down.
- Real limits. "Unlimited" always has fine print somewhere: inodes, processes, fair use.
- Exit. Can you export everything, files, database, DNS zone, without depending on goodwill? If the answer is no, the low price is a trap.
How to migrate without downtime
Migration feels frightening because almost everyone does it in the wrong order. The right order is this:
- Lower the DNS TTL. A few days ahead, drop the records' TTL to something short, like five minutes. That makes the switch propagate fast when the moment comes.
- Build the new environment completely. Files, database, variables, certificate, cron jobs. All ready and tested before pointing anything.
- Test via IP or a temporary subdomain. Browse the entire site on the new server while the old one keeps serving the public.
- Freeze changes. Agree a window in which nobody publishes content and no form submissions are expected, so you do not lose data written to the old server after the final copy.
- Sync the data one last time and only then change DNS.
- Keep the old server running for a week. While DNS caches around the world still point there, it will keep receiving visits. Shutting down early is the most common cause of "everything disappeared" during a migration.
- Verify after the switch: valid certificate, redirects working, the form sending email, domain email still delivering, and Search Console showing no new errors.
- Restore the TTL once everything has settled.
Done in that order, the migration happens without a single visitor noticing. Done in reverse, point DNS first, configure afterwards, you get a few hours of broken site and no easy way back.
If you are not sure which model your site needs, or want to migrate without the drama, talk to ALB Seven.