Buying Hosting: The Line Items Nobody Puts on the Pricing Page

The right way to buy hosting is to work out what your site actually needs, which is usually a small amount of CPU, a small amount of memory, some bandwidth and maybe a database, and then find the plan that covers it, rather than choosing between tiers named Starter, Business and Pro.

Those names are marketing, and they differ between providers in ways the names do not reveal. Underneath, every host is selling the same handful of things. Here is what they are, how to size them for a real site, and the questions that separate a plan that works from one that becomes a problem in six months.

Table of contents

• What you are actually paying for
• The types, and who each is for
• Sizing it without guessing
• The questions worth asking before you pay
• Mistakes that cost real money
• A decision path that works
• How this fits the rest of the stack
• FAQ

What you are actually paying for

Strip away the plan names and every hosting bill is some combination of these.

• Compute. CPU and memory for something to run on. A static site needs almost none. An application needs enough to hold the runtime and handle concurrent requests.
• Storage. Disk for your files and your database. Usually generous and rarely the constraint, unless you serve video or accept large uploads.
• Bandwidth. Data leaving the server. The line item most likely to surprise you, because it scales with success rather than with what you built.
• A database. Either included, or a separate instance with its own price.
• The managed part. Patching, backups, certificates, monitoring. This is most of what you pay for on a managed plan and it is genuinely worth paying for.

Once you see a plan as those five numbers, comparing across providers becomes arithmetic rather than a judgement about which brand sounds more serious.

It also makes the sizing question tractable, because you can estimate each one rather than guessing at a tier.

The types, and who each is for

The categories are genuinely different products, not tiers of one product.

Shared hosting puts many sites on one server. Cheap, simple, and your performance depends on your neighbours. Fine for a brochure site, frustrating for anything with traffic.

Managed WordPress is shared or cloud hosting tuned for one application, usually with caching, updates and backups handled. If you are running WordPress, this beats generic hosting at the same price, because the tuning is the product.

A VPS gives you a slice of a machine and root access. Maximum control, and you now own patching, firewall rules, certificates, backups and the pager. Choose this when you need the control, not because it sounds more professional.

Application platforms deploy from a repository and run your code as a service, with build logs, environment variables, runtime logs and rollback. This is the shape most web applications want, because the server administration is not the thing you were trying to do.

Static hosting serves files from a CDN. Nearly free and extremely fast, for anything that does not need a process running between requests.

The most common expensive mistake in this list is buying a VPS for a site that needed managed hosting. The monthly price is competitive and the real cost is the hours, which are not on the invoice and are not small.

Sizing it without guessing

Rough figures that hold up in practice.

1. A static site, any size, with normal traffic: no compute at all, and bandwidth is the only variable. A text and image site serving a few thousand visitors a month uses single-digit gigabytes.
2. A small WordPress site: half a vCPU and a gigabyte of memory handles a typical small business site comfortably. Traffic spikes are handled by caching rather than by a bigger plan.
3. A small web application with a database: one vCPU and one to two gigabytes for the service, plus a small database instance. This covers a great deal more traffic than people expect, because most requests are cheap.
4. Anything doing real work per request, such as image processing, report generation or model inference: measure it. Rules of thumb are useless here, and this is the case where autoscaling earns its keep.

The general rule: start smaller than you think and make sure you can move up without a migration. Over-provisioning on day one is money spent on capacity you have no evidence you need, and the evidence arrives within a week of launching.

For reference on the general ladder: Dev is 0.3 vCPU and 624MB at four dollars, Basic is 0.5 vCPU at six, BasicMini is a full vCPU and 1GB at thirteen, and BasicPlus is a vCPU and 2GB at twenty. Autoscaling between a floor and a ceiling plan handles the spikes so the baseline does not have to.

The questions worth asking before you pay

Six questions that predict most of the trouble.

• What does this renew at? Introductory pricing is the norm, and the second-term price is the real one.
• What happens when I exceed the bandwidth allowance? Overage rates, throttling and hard cutoffs are three very different answers, and only one of them is survivable during a traffic spike.
• Are backups included, how far back do they go, and can I restore one myself? A backup you cannot restore without a support ticket is a backup with a response time attached.
• Can I move up a plan without downtime or a migration? If scaling means rebuilding on a new server, the cheap plan has a cost attached that is not on the page.
• Do I get logs? Build logs and runtime logs are the difference between fixing a problem and guessing at one.
• How do I leave? Database dumps, file access and DNS control should all be things you can do yourself.

The bandwidth question is the one most likely to matter unexpectedly, because the day it becomes relevant is the day something you made did well, which is the worst possible time to find out the answer is a hard cutoff.

Mistakes that cost real money

The patterns that show up again and again.

Paying for three years up front to get the advertised rate, then needing something different in month four. The discount is real and so is the commitment, and hosting is one of the few purchases where your requirements are genuinely likely to change within the term.

Buying a VPS to save money and spending twenty hours on server administration. At any realistic value of your time, the managed plan was cheaper before the first weekend.

Running a database on the same tiny instance as the application. It works until traffic arrives, at which point they compete for memory and both get slow, and the symptom looks like an application problem.

Not having a rollback. Every deploy is a chance to break the site, and the difference between a bad deploy and an outage is entirely whether you can go back to the previous version in one click.

Ignoring where the database lives relative to the application. If they are in different regions or different providers, every query crosses a network boundary and often a billable one. Keeping them on the same private network is free and makes everything faster.

A decision path that works

1. Does the site need anything running between requests? If no, static hosting. Stop here, it is nearly free.
2. Is it WordPress? Managed WordPress, which starts at three dollars a month and includes the tuning that generic hosting does not.
3. Is it an application you deploy from a repository? An application platform, sized from the table above, with a managed database beside it.
4. Do you specifically need root, custom system packages, or software that assumes a whole machine? A VPS, with a realistic estimate of the administration time.
5. In every case: confirm the renewal price, the bandwidth policy, the backup restore process, and how you would leave.

Most people asking where to buy hosting are at step one or two and being sold step four, which is the single largest source of overspending in this category.

On RunxBuild all of these sit on one platform: static sites with 120GB of bandwidth included and ten cents a gigabyte after, managed WordPress from three dollars, services deployed from GitHub with build logs and rollback, and managed MySQL or Postgres on the same ladder with private networking between them.

How this fits the rest of the stack

The reason hosting is confusing to buy is that it is sold as plan names and consumed as line items, so two plans at the same price can be completely different purchases. The RunxBuild hosting calculator works the other way round: you pick the compute, the database, the storage and the bandwidth you actually need and see each one priced separately, which is a much better basis for a decision than a tier called Business.

Useful related references:

• What Is a Static Website? Benefits, Examples, Hosting
• WordPress Self-Hosting: LAMP, Docker, or Managed RunxBuild
• Webspace Hosting: An Old Word for a Constraint That Moved
• Services on RunxBuild

FAQ

What should I look for when buying web hosting?

The renewal price rather than the introductory one, what happens when you exceed the bandwidth allowance, whether backups exist and whether you can restore one yourself, whether you can change plan without a migration, whether you get build and runtime logs, and how you would export everything if you left.

How much hosting do I actually need for a small website?

Less than most plans assume. A static site needs no compute at all and only bandwidth. A small WordPress site runs comfortably on half a vCPU and a gigabyte of memory. A small application with a database typically needs one vCPU and one to two gigabytes. Start small and make sure you can move up without rebuilding.

Is a VPS cheaper than managed hosting?

On the invoice, often. In total, usually not. A VPS means you own patching, firewall configuration, certificate renewal, backups and anything that breaks at an inconvenient hour. Choose one when you specifically need root access or custom system packages, not to save a few dollars a month.

What is the difference between shared hosting and an application platform?

Shared hosting puts your site alongside many others on one server and is aimed at traditional websites. An application platform deploys your code from a repository, runs it as a service, and gives you environment variables, build logs, runtime logs and rollback. The second is what most web applications actually want.

Why does my hosting bill go up when my site gets popular?

Bandwidth, usually, and sometimes compute. Data leaving the server is metered on most plans, so traffic converts directly into cost, and an application under load may need a larger plan or autoscaling. Check the overage policy before you need it, since throttling and hard cutoffs behave very differently during a spike.