Hosting & Cloud

Every project reaches a moment when somebody has to answer a plain question: which machine serves this, and who is responsible for it the minute it stops. The answers form a ladder, and that ladder is almost always presented as a price list. Price is the wrong axis. What each rung sells is control, and control is not paid for in money. It is paid for in attention: the hours that go into patching, monitoring, tuning and recovering instead of into the thing visitors came for. Shared hosting sits at the bottom because you control almost nothing and are therefore asked for almost nothing. A VPS hands you root and, in the same movement, the job title of systems administrator. A dedicated server removes the neighbours and keeps every one of those duties. Cloud hosting turns the machine into an API call and the invoice into a meter, while PaaS and serverless hide the machine entirely and charge a premium for never making you think about it. Managed hosting is the sideways move available at nearly every rung: you buy someone else's attention back. A managed plan looks expensive beside a bare server right up to the moment you price your own weekends honestly, and then it is often the cheapest line on the budget. The table below is the same ladder every comparison draws, with the columns that decide real projects rather than the ones that win price wars.

Which rung your project belongs on

Start with the position most people resist. A brochure site, a portfolio, a local business with a contact form, a small shop on a standard platform: these belong on shared or managed hosting, and moving them to a VPS is a hobby wearing the costume of an architecture decision. The rung is not a status symbol, and nobody visiting the site can tell which one you chose. A VPS earns its place when the application needs something a plan cannot hand over: a background worker, a queue, a long-running job, a specific runtime version, a service listening on its own port, or genuine isolation for compliance reasons. The signals that it is time to climb are behavioural rather than emotional. You are on a plan and still colliding with a fixed limit. The same tuning request goes back to support every month. A deploy needs downtime you cannot schedule. Two engineers are now waiting on one person with panel access. Traffic by itself is rarely the signal, because traffic is usually cheaper to absorb with caching and a CDN than with a bigger box: buy the cache before you buy the rung. The cloud's own rung is earned by variability and by the need to create and destroy infrastructure on demand, not by ambition. If your load is flat and predictable, a fixed-price machine is usually both cheaper and calmer. Containers are what keep the climb reversible, which is the main argument for adopting them early: they make the rung a deployment detail instead of a decade-long commitment. One more thing belongs in this decision. What a vendor calls an uptime SLA is a refund schedule rather than an undertaking. It defines how the provider counts a bad hour and what share of your fee comes back, and it does not undertake to keep anything running. The credit is almost never in the same order of magnitude as what the outage cost you in sales, support time and trust. If a figure is quoted, do the arithmetic yourself: a tenth of a percent of a thirty-day month is roughly forty-three minutes, so 99.9% describes an ordinary month rather than an exceptional one. Availability gets designed, with redundancy, load balancing and a recovery somebody has actually rehearsed, or it is not there at all.

The slow server and the expensive cloud

The two rungs fail in opposite directions, and confusing them is how budgets get wrecked. Undersize a flat-rate machine and it degrades quietly. Pages take longer, the queue backs up, somebody complains, and the invoice does not move. The damage is real but bounded, visible in the place you are already looking, and fixable by buying the next size. A misconfigured cloud account fails the other way round. Nothing gets slower. The bill grows. Instances spun up for a test three months ago still running, snapshot sets nobody prunes, object storage that is cheap to fill and priced again on the way out, autoscaling rules that answer a crawler with the same enthusiasm they answer customers: this is the cloud's version of downtime, with the same sinking feeling, a larger number and no incident page to point at. Egress is the line most newcomers never see coming, because every other model they have used treated bandwidth as included. Treat cost as an operational metric from the first day: tag every resource with the project it belongs to, put a billing alert on the account before the first deploy, and set a standing calendar reminder to read the bill line by line, because nothing in a cloud console ever suggests that you turn something off. Then there is the sentence that decides how bad the worst day gets. A backup that has never been restored is an assumption, not a backup. Restoring is a separate skill from copying, and it fails for dull reasons: an incomplete database dump, a missing configuration file, a key nobody kept, a restore procedure written by the one person now on holiday. Pull a backup into a scratch machine, bring the site up on it, and write down how long that took. The answer you want from a colleague is never 'we have backups', it is how long the last real restore took and when it happened. Our hosting guide takes the provider question from here; the career route through these systems is mapped in IT, cloud and security.