Short answer. Web hosting is renting space and computing power on an always-on server that sits in a data centre and is wired to the internet. Your site files live there, and a web server program answers browsers. A domain is the name; hosting is the building — separate services, bought separately.
What is web hosting in plain words
A website is a pile of files: HTML pages, images, stylesheets, scripts, and usually a database plus code in PHP, Python or JavaScript. For anyone other than you to see those files, three things have to be true at the same time.
- A computer that never switches off. A laptop sleeps, loses Wi-Fi and goes on holiday with its owner. A site hosted on it is available exactly that often.
- A permanent address on the network. Home connections usually hand out a dynamic IP, and often an address behind the provider's shared gateway that nobody can reach from outside.
- A running web server program. nginx, Apache or Caddy accept the HTTP request and build the response. Files on their own answer nobody — something has to serve them.
Hosting is renting that computer, or a slice of it, together with the operations around it. You pay a provider; the provider keeps the metal powered, cooled and connected to upstream networks, swaps dead drives, and makes sure all of it still works at night, on holidays and during a substation failure.
The analogy that mostly holds: a domain is the address on the sign, hosting is the actual room with shelves, lights and a door to the street. You can move the sign to a different room in an evening. The stock has to be physically carried across.
What you are actually renting
"Hosting" is not one service but a bundle of five. The gap between a cheap plan and an expensive one is not "how many megabytes" — it is how many of these are guaranteed versus supplied on a best-effort basis.
| Component | What it is | What limits it in practice |
|---|---|---|
| Disk space | Room for site files, the database, mail and backups | Gigabytes, the number of file records (inodes), drive type — SATA SSD or NVMe |
| CPU and memory | Resources to execute code: PHP, Node.js, database queries | Share of a core, memory ceiling, maximum concurrent processes |
| Bandwidth and IP address | The uplink and the point at which the server is found | Port speed, traffic volume, shared versus dedicated address |
| Software stack | Web server, interpreters, database engine, mail server, control panel | Available PHP and MySQL versions, root access, right to install your own software |
| Operations | Power, cooling, hardware replacement, backups, attack mitigation, support | Stated availability, backup retention depth, support response time |
Web hosting vs domain: the difference
This is the beginner's central confusion, so let us settle it early. A domain and hosting are two independent services. One company often sells both on one invoice, but underneath they are renting a name and renting resources, and you can buy them in different places.
| Aspect | Domain | Hosting |
|---|---|---|
| What it is | A name such as example.com | Disk, CPU, memory, bandwidth |
| Who you buy from | A registrar accredited for the zone | A hosting provider or cloud platform |
| Billing period | Usually a year or more | Usually a month or a year |
| Where the record lives | In the registry of the domain zone | On a specific server with a specific IP address |
| If you stop paying | The name is released, the site stops opening by address | Files are deleted after a grace period, the name stays yours |
| Switching supplier | Transfer between registrars | Move the files, repoint the DNS record |
DNS is what ties them together. A domain has NS records telling the world which name servers answer for the zone. Those name servers hold an A record — or AAAA for IPv6 — carrying the IP address of your hosting. The browser asks for the address by name first, then knocks on the address. For how names and zones are built, see what a domain is; for the wiring itself, see how to connect a domain to hosting.
A domain and hosting do not depend on each other. Delete the site from hosting and the domain is still yours. Let the domain lapse and the files stay on the server, but nobody can open the site by name. They carry separate invoices and separate renewal dates — which is why sites usually "disappear" not because of the server but because of a forgotten domain.
Where hosting physically is
The answer to "where is my hosting" is literal: in a building with a street address, security at the door and two independent power feeds.
The data centre
This is not a cloud in the figurative sense but an engineering structure. Power arrives from separate substations; between the feeds sit battery-backed uninterruptible supplies and diesel generators that start while the batteries still hold. Cooling systems pull heat out of the racks — the more kilowatts per rack, the more elaborate the scheme. Access to the halls is by pass, and racks lock. Facility resilience is commonly described in Tier levels under the Uptime Institute classification: the higher the tier, the more the engineering infrastructure is duplicated and the more expensive a rack unit becomes.
Rack, server, drive
The hall holds racks roughly two metres tall. Servers slide into them horizontally; the common sizes are 1U and 2U, that is 4.4 or 8.9 centimetres in height. Inside are CPUs with dozens of cores, tens or hundreds of gigabytes of RAM, and storage. Drives are grouped into arrays so that one failure does not destroy the data; on modern floors that usually means NVMe SSDs rather than spinning disks. Each server has at least one, normally two, network links to the top-of-rack switches.
How one server becomes hundreds of sites
Your site almost never occupies a whole machine. On shared hosting, hundreds of accounts live on a single operating system, separated by file permissions and resource limits. On a VPS, a hypervisor slices the physical server into virtual machines, each with its own kernel and its own root user. In the cloud, one more layer of abstraction appears: disk, address and compute become separate objects you can resize without taking the service down.
Geography: why the city matters
Light travels through optical fibre roughly a third slower than through vacuum, and every intermediate router adds a fraction of a millisecond. The result is that latency grows with distance and cannot be optimised away in code. The gap between a server in your own country and one on another continent is measured in tens — sometimes well over a hundred — milliseconds per request-response round trip. A page that makes ten sequential calls to the server multiplies that gap by ten.
So you place the server near the audience and push static files through a content delivery network when needed. Region is normally chosen at order time — for an audience inside Russia, for instance, a local operator such as Selectel runs its own data centres there and lets you pick the site when the server is created.
Jurisdiction and data residency
Beyond kilometres there is law. Where a server physically stands decides which legal regime applies to the data on it. Under the GDPR, moving personal data of people in the European Economic Area to a country outside it is only lawful on specific grounds — an adequacy decision or appropriate safeguards such as standard contractual clauses. Several countries go further and require certain categories of data to be stored domestically. The obligation attaches to the server, not to the domain: the name can live in any zone, the database has to sit where the rules say. Check where your provider actually keeps data and backups, not only where its head office is registered.
Types of web hosting: shared, VPS, dedicated, cloud
The difference between the types is where the boundary runs between your responsibility and the provider's. The cheaper the plan, the more the provider does and the less you are allowed to change.
| Type | What you get | Who administers the system | Who it suits |
|---|---|---|---|
| Shared | An account on a common server, a control panel, a ready stack | The provider | Brochure sites, blogs, small shops |
| VPS / VDS | A virtual machine with root, guaranteed cores and memory | You | Custom stacks, several projects, staging environments |
| Dedicated server | A whole physical machine with no neighbours | You | Heavy load, large databases, specific hardware needs |
| Cloud | Resources on demand, pay for consumption, scaling | You, with some layers handled by the platform | Spiky traffic, fault-tolerant designs |
Narrower formats sit alongside these: static hosting, where files are served without running any code; managed hosting for one specific CMS, where the provider updates the engine; and serverless platforms, where you pay per function invocation rather than for machine uptime.
The full comparison — when a shared account stops being enough and which symptoms mean it is time to move — is in shared hosting vs VPS vs dedicated server. How to pick a provider and what to read in the contract is covered in the guide to choosing hosting. We deliberately do not repeat them here: this article exists to explain what hosting is at all.
How much does web hosting cost and what drives the price
Exact figures go stale faster than an article, so the structure is more useful than the numbers: what is the provider actually charging for?
- Hardware depreciation. A server runs for a few years, then it is replaced. Its cost is spread across the months of every customer living on it.
- Power and cooling. The bill covers not only the watts the server eats but the ones spent conditioning the hall around it. Every watt of useful load carries a noticeable share of engineering overhead.
- Rack space and transit. Renting rack units, paying for uplinks and peering, filtering junk traffic at the network edge.
- Licences. Control panel, commercial operating system, mail antivirus, backup tooling.
- Labour. On-call engineers and support working nights and weekends — the most expensive part of a cheap plan, and the reason genuinely free serious hosting does not exist.
- Backups. Storage for copies and the traffic to create them cost real money, which is why retention depth is almost always a paid option.
The ratios between the types stay stable even when the numbers move: shared hosting is the cheapest option, a VPS of comparable power costs several times more, and a dedicated server another order of magnitude on top. Cloud changes the character of the bill more than its size: instead of a flat fee you get a consumption-based invoice, which can land below the flat one or noticeably above it during a traffic spike.
What to look at besides the headline number
- Renewal price. The first term is often discounted and renewed at full rate. Compare the second invoice, not the first.
- "Free domain" bundles. The gift covers one term. In year two the domain is billed separately, often above what a dedicated registrar charges.
- What costs extra. A dedicated IP address, certificates beyond the free one, daily backups with long retention, additional mailboxes, migration done by the support team.
- Compensation for downtime. If availability is advertised but a breach carries no remedy, that is a marketing number, not an obligation.
- Refund terms. Paying a year upfront beats monthly billing only if the money comes back when you leave early.
Why "unlimited" hosting is not unlimited
No server has an infinite disk. "Unlimited" means the counter was removed from the price list, not from the system. The limits are all still there — they simply live in the acceptable use policy rather than on the plan page.
- File records (inodes). A filesystem stores not only bytes but an entry per file. That count is finite, and a cache of hundreds of thousands of tiny files hits the ceiling long before the gigabytes do.
- CPU time. Shared plans allocate an account a share of a core, a memory ceiling, a process cap and an I/O limit. Going over is not punished with an email but with slowdowns and a "resource limit reached" error.
- What the space is for. The policy nearly always says the disk is meant for a working website, not a file archive, not backups of unrelated projects, and not video distribution.
- Fair use of traffic. "Unlimited bandwidth" is bounded by port speed: even without a counter, you cannot push out more than physically fits down the link.
Read the acceptable use policy and the contract, not the plan page. "Unlimited" on the storefront almost always means "no separate meter in the price list". The real thresholds — inodes, CPU share, process count, maximum single file size — live in the document behind the small link at the bottom of the page.
How close you are to a threshold is visible on the server itself if you have SSH access.
# Inodes used and remaining on this filesystem
df -i .
# Ten heaviest directories in the current folder
du -sh ./* | sort -h | tail -10
# Total number of files in the project
find . -type f | wc -lMore often than not it turns out the space and the inodes went to the CMS cache or to logs, not to content. On shared hosting without SSH, the same figures usually appear in the control panel's resource usage section.
How to find out what hosting a website uses
The question comes up in two situations: you inherited a project and do not know where it lives, or you are looking at somebody else's site. The method is the same — go from the name to the address, and from the address to the owner of the network.
Step 1. Find the IP address
DNS turns the domain into an address. While you are there, look at which name servers answer for the zone: on shared hosting they almost always belong to the same provider.
# A record: which address the domain's name servers return
dig +short example.com A
# Which name servers are authoritative for the zone
dig +short example.com NS
# Reverse zone: what the host at that address is called
dig +short -x 93.184.216.34On Windows without dig installed, nslookup -type=A example.com and nslookup -type=NS example.com return the same data.
Step 2. Find who owns the address
Blocks of IP addresses are allocated to organisations and recorded in the regional registry databases. That is where the provider or data centre name comes from.
# The organisation the address block is delegated to
whois 93.184.216.34 | grep -Ei 'netname|descr|orgname|country'
# Response headers: sometimes reveal the web server, panel or an intermediary
curl -sI https://example.com | grep -Ei '^(server|x-powered-by|via|cf-ray)'Step 3. Do not be fooled
- Behind a CDN you only see the CDN. If the site sits behind a delivery network or an attack-mitigation service, the A record points at the intermediary and the real server address is hidden. That is the design, not a flaw in the method.
- NS records do not always point at the host. Zones are frequently kept apart from files: names at one service, the website at another.
- Domain whois shows the registrar, not the host. Two different questions, two different answers.
- MX records lead to the mail provider. Mail often lives away from the site, and its address says nothing about where the pages are.
A whois lookup on an IP answers "who was this address block delegated to", not "who is the site owner paying for the server". There is often a chain in between: a data centre leases a rack to a host, the host sells a VPS to a reseller, the reseller sells to the end customer. The database shows you the top of that chain.
Step 4. Check it with tools
All four steps work without a terminal:
- Whois — who the domain is delegated to and who owns the address block;
- IP lookup — where the address physically sits, which network and autonomous system it belongs to;
- DNS records — A, AAAA, NS, MX and the rest for one domain;
- Response headers — what the web server says about itself;
- Speed test — how fast the server actually answers.
The step-by-step walkthrough with all the edge cases is in how to find a website's hosting and IP address.
Measuring your own server's response
A single curl call shows where the time goes: name resolution, connection setup, the TLS handshake, or the server's own work.
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.comRead it like this: a wide gap between tls and ttfb means the code or the database on the server is slow. Large connect and tls with a fast ttfb means distance and network, not the host. A large dns points at the name servers, not the site.
How to make your own hosting
At home: possible, but not for a production site
Standing up a web server on a home machine is technically easy. The problems start outside the configuration.
- No permanent public address. Residential plans often place you behind the provider's shared gateway, so nothing from outside can connect at all and no amount of router tweaking helps.
- Blocked ports. Inbound connections on 80 and 443 are frequently prohibited by the terms of consumer plans.
- Asymmetric link. Home internet downloads fast and uploads slowly, and a website is pure upload.
- No redundancy. A power cut or a cable dug up in the street takes the site down, and nobody is coming to fix it under an SLA.
- Security is entirely yours. A server exposed to the internet is scanned around the clock from the first minutes. Patching, firewalling and brute-force protection become a standing chore.
For a lab, a home media server or a demo to a colleague, that is fine. For a site real people depend on, it is not.
Your own server instead of a ready-made plan
The realistic way to "build hosting" is to rent a VPS or a dedicated server and assemble the stack yourself. You get root, install the web server, the database and the interpreter, and from then on you own updates, backups and monitoring. A minimal nginx site block looks like this:
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}Validate and apply with nginx -t && systemctl reload nginx. After that you will need a certificate with automatic renewal, a firewall, scheduled backups and external uptime monitoring — because a server that has fallen over will not report itself.
Hosting as a business
Selling hosting to other people is a different story, and the entry bar is higher than it looks: address space and network agreements, round-the-clock support, billing, a control panel, plus the legal side. Providers carry obligations for what their customers publish, must run an abuse-handling process, and in a growing number of jurisdictions face registration or reporting duties. The usual first step is simpler — reselling, where you repackage somebody else's capacity under your own brand and never touch the hardware.
What happens when you migrate to another host
The key point: the content moves, the name does not. The domain stays with the registrar; only the records that point at an address change. That is exactly why a migration cannot cost you the name.
- Lower the TTL in advance. A day or two before the move, cut the A record's time to live to, say, five minutes. This has to happen before the switch, not with it.
- Move files and the database. A site archive plus a database dump. Check the dump's character set and the database engine version on the new side.
- Bring the site up on the new server and test it before switching. Open it by IP address, or override the name-to-address mapping in your local hosts file.
- Issue the certificate. HTTP-based validation requires the domain to already point at the new server; if it does not yet, use DNS-based validation instead.
- Repoint the A record. And the MX records too, if mail is moving along with the site.
- Wait for caches to expire. Some visitors will keep landing on the old server for a while.
- Keep the old host running for a few days. Do not cancel it on migration day: orders and mail can still settle there.
- Raise the TTL back. Once things are stable, restore it so you are not hammering the name servers.
Lower the TTL ahead of time. If you do it at the same moment you repoint the address, the old value keeps living in resolver caches for exactly as long as the previous TTL said — and for a full day part of your audience will keep hitting a switched-off server no matter what you edit in the panel.
What breaks most often
- Mail leaves with the MX records. Everyone remembers the website; the mailboxes get forgotten. Messages start arriving at a new server where no mailboxes exist yet.
- The database write window. Orders placed between taking the dump and flipping the record land on the old server and vanish. A temporary read-only mode during the copy avoids this.
- Filename case. Linux distinguishes Logo.png from logo.png; some other systems do not. After a move, part of the imagery can simply disappear.
- A different PHP version. The new server is usually newer, and code that ran for years suddenly complains about deprecated constructs.
- Hardcoded paths and URLs. Absolute paths in configuration and the old domain baked into the database are the classic cause of "the site opens but the styles do not load".
Verifying a migration is easiest from outside: DNS records show what the zone is actually publishing, the propagation check shows how far resolvers still disagree, the certificate check confirms TLS came up on the new side, and a speed measurement tells you whether the thing you did all this for actually got faster.
Frequently asked questions
Can I buy the domain and the hosting from different companies?
Yes, and it is standard practice. Either point the registrar's name server fields at the host, or keep the zone with the registrar and add an A record with the server's address. Splitting them is arguably better: changing hosts never touches the domain, and a dispute with one supplier does not freeze the other service.
Is there such a thing as free hosting?
There is, and it is paid for in another currency: adverts on your pages, hard resource limits, no support and no backups, and sometimes a third-level domain that is not yours. Fine for a learning project. Not fine for a site your orders depend on — there is nothing to restore from and nobody to hold accountable.
How much disk space does a website really need?
A brochure site or a small blog occupies a few gigabytes including the database and mail. Space is usually eaten not by pages but by unoptimised images, accumulated logs and CMS cache. If a plan fills up on an apparently empty site, look in those three places before upgrading.
What happens if I stop paying for hosting?
First the site is suspended but the data is kept — most providers offer a grace period. After it expires, files and database are deleted with no recovery. The domain meanwhile carries on until its own renewal date, because it is a separate bill.
Can visitors see which host a site uses?
Not directly, but almost always indirectly: through the IP address and network owner, response headers, name server names and the reverse DNS entry. Hiding the provider completely requires sitting behind a delivery network or proxy, and even then not from every method.
Does mail need a separate server?
Not strictly, but separating them is wise. Mail on the same box as the site suffers whenever the site is under load, and the sending reputation of a shared IP address depends on your neighbours. To see where the mail records currently point, use the MX lookup.
Checklist: what to know about your own hosting
- Who the provider is, under which contract, and until what date the plan is paid.
- What the site's IP address is and which country it sits in.
- Where the DNS zone is kept: with the host, the registrar or a third-party service.
- Which limits the acceptable use policy sets: disk, inodes, CPU time, process count.
- Whether backups run, how far back they go, and — crucially — whether one has ever been restored.
- Whether SSH and FTP access exist, and who else holds the passwords.
- Who issues the TLS certificate and whether renewal is automatic.
- Where the MX records point and where the mail actually lives.
- Whether external uptime monitoring exists and whose phone the alert reaches.
- Exactly what would have to move if you had to change provider tomorrow.