The “hosting” line on a website quote is often vague, and customers rarely know what to ask about it. Here are the four common options with their real costs and real problems.
Shared hosting
Dozens to hundreds of sites on one server, sharing its resources. Usually ten to forty dollars a month, with a control panel that installs WordPress in a few clicks.
Suits: tight budgets, low traffic, and tolerance for occasional slowness. Personal blogs, small businesses still testing an idea.
The real problems: your neighbours affect you. Another site on the same machine gets attacked or runs terrible code, yours slows down, and there is nothing you can do. These providers also restrict a lot — certain extensions unavailable, no server configuration, backups sold separately.
The most overlooked part: renewal is usually two to three times the first-year price. Thirty-nine in year one, a hundred and nineteen in year two is normal in this industry rather than exceptional. Ask about renewal before signing.
A VPS
One physical server divided into portions; you get one, with dedicated resources and full control. Ten to a few hundred a month depending on specification.
Suits: running WordPress or other dynamic software, managing several sites, needing particular software installed.
We use one ourselves, with around fifty sites on a single machine. It is economical, provided somebody looks after it.
The real problems: it does nothing for you. System updates are yours. SSL renewal is yours — including configuring the automatic renewal, and if you configure it wrong the whole site shows a security warning on expiry day. Backups are yours to set up. A compromise is yours to notice.
“Somebody looks after it” is the actual line between a VPS and shared hosting. Not technical difficulty — whether a person genuinely deals with it on the day something breaks. Without that, a VPS is more dangerous than shared hosting, where the provider at least patches the system.
Static hosting
If your content does not change between updates — company sites, portfolios, product pages, which is most of them — it does not need a server running continuously.
Generate the pages in advance as files and put them on a CDN. Visitors receive finished files, with no software executing and no database queried.
Price: the free allowances on the major platforms cover a business website comfortably. Not cheap — free.
Speed: its main advantage. After moving our own site, every page measures between 40 and 60 milliseconds consistently. Before, it was 45 on a cache hit and 520 on a miss.
Security: no software running means no software vulnerabilities to exploit. Most attack methods aimed at websites simply do not apply.
The real problems: dynamic features need arranging separately. Form submissions, logins and payments cannot be done with static files, so they need a third-party service or a small separate endpoint. Updating content also means regenerating and republishing rather than clicking save in an admin panel — unless someone has reduced that to a single command.
Serverless and edge computing
Between static and dynamic. Code does not live on a particular server; it is distributed across the CDN and executes near whoever made the request.
Suits: mostly static content that needs a little dynamic capability — a form endpoint, access control, language routing.
This is our current arrangement: pages deploy as static files alongside the code, while admin and API requests are passed back to a server. Visitors never touch that server; it exists only as the place content is managed.
The real problems: its own constraints — execution time limits, a restricted set of libraries, and debugging that is more awkward than on your own machine. Good for small pieces of logic, poor for relocating a whole application.
Choosing between them
Do not start from price. Start from three questions:
Does the site have genuinely dynamic features? Having a form does not count — forms can be handed to a service. Genuinely dynamic means logins, orders, an admin interface. Without those, static hosting should be the default: it wins on speed, security and cost simultaneously, with nothing to trade off.
Who deals with it when something breaks? If the answer is nobody, do not choose a VPS. This is not about money. An unattended server eventually has an incident, usually while you are busy with something else.
How often does the content change? A news site updated daily and a company site edited twice a year want different arrangements. The first needs a smooth publishing flow; the second can live with running a publish command after edits.
What to establish before signing
Whichever you choose, settle these in advance, because all of them are painful to change later:
The renewal price, not the first-year price. How often backups run, how long they are kept, how a restore works and how long it takes. Whether SSL renews automatically and who is responsible on expiry. How quickly someone starts work when the site is attacked or goes down. And the important one: if you move to another provider, can you take the code and data with you intact?
That last question determines whether you are locked in. Some platforms cannot export a site at all, so moving means rebuilding. One question at signing settles it; discovering it when you want to leave is too late.
On our projects the code and data belong to the client, and hosting is chosen per project rather than pushing everyone onto the same thing.