Hosting

How Web Hosting Works¶

When you type a domain into a browser, a chain of systems turns that name into a page on your screen in a few hundred milliseconds. This page walks through that chain end-to-end, explains what a hosting provider actually rents you, compares the common types of hosting, and breaks down the components of a hosting stack so the hands-on pages later make sense.

Tested on

This page is conceptual and applies to any platform. The hands-on companion pages target AlmaLinux 9 / RHEL 9 (with Debian/Ubuntu notes inline) on the Linux web-server track.

What happens when a visitor opens your site¶

Imagine someone types https://example.com and presses Enter. Roughly this happens:

DNS lookup — the browser needs an IP address, not a name. It asks a recursive resolver (usually your ISP's or something like 1.1.1.1), which walks the DNS hierarchy to find the A record (IPv4) or AAAA record (IPv6) for example.com. The answer is cached for the record's TTL. See Domains and DNS for Hosting for the full resolution path.
TCP connection — the browser opens a TCP connection to that IP on port 443 (HTTPS) or 80 (plain HTTP). This is the network plumbing covered in Networking Basics.
TLS handshake — for HTTPS, the browser and server negotiate encryption and the server presents its TLS certificate. The browser checks the certificate is valid, unexpired, and issued for example.com. Now the connection is encrypted. See HTTPS with Let's Encrypt.
HTTP request — over the encrypted channel the browser sends a request like GET / HTTP/2 plus a Host: example.com header (so one IP can serve many sites — name-based virtual hosting).
Server does the work — the web server (nginx or Apache) receives the request. For a static file it reads it from disk and returns it. For a dynamic app it hands the request to an application runtime (PHP, Node, Python), which often queries a database for content, renders HTML, and passes it back.
HTTP response — the server returns a status code (200 OK, 404 Not Found, 301 redirect, etc.), response headers, and the page body.
Browser renders — the browser parses the HTML and fires off more requests for CSS, JavaScript, images, and fonts, repeating steps 1-6 (often to a CDN) until the page is complete.

Visitor's browser
   │  1. DNS: example.com -> 203.0.113.10
   ▼
Recursive resolver ──> root ──> .com TLD ──> authoritative NS
   │  2. TCP connect 203.0.113.10:443
   ▼
Web server (nginx/Apache)
   │  3. TLS handshake (presents certificate)
   │  4. HTTP GET / (Host: example.com)
   │  5. app runtime ──> database query
   ▼
   6. HTTP 200 + HTML  ──>  7. browser renders + fetches assets

It is fast because of caching

DNS answers, TLS sessions, and static assets are all cached at multiple layers. A returning visitor often skips the DNS lookup and reuses a connection, so the page loads far faster than the first hit.

What a hosting provider actually provides¶

A web hosting provider rents you the infrastructure and services to keep your site reachable. Depending on the plan, that bundle includes some or all of:

Compute — a slice of a server, a virtual machine, or a whole physical box where your files and processes run.
Storage — disk for your site's files, databases, and logs (often SSD/NVMe).
Network and IP — bandwidth, a public IP address, and connectivity to the internet backbone.
A web server — pre-installed, or yours to install.
A database — MySQL/MariaDB or PostgreSQL, on the same box or a managed service.
Email — mailboxes and SMTP/IMAP for your domain (or you point email elsewhere).
DNS hosting — authoritative nameservers and a panel to edit your zone.
TLS/SSL — often free Let's Encrypt certificates with auto-renewal.
A control panel — a web UI (cPanel, Plesk, or open-source like CyberPanel) to manage all of the above.
Backups, monitoring, and support — how much you get here is the big difference between plans.

The core insight: hosting is not one product. It is a stack of services, and the plans below differ mainly in how much of that stack the provider runs for you versus how much you run yourself.

Types of hosting¶

The four common models trade cost, isolation, control, and effort against each other.

Type	What you get	Isolation	Control	Scaling	Typical cost	Best for
Shared	An account on a server shared with many other customers	Low (neighbors share CPU/RAM)	Low (panel only)	Limited	Lowest	Small sites, blogs, first projects
VPS	A guaranteed slice of a server as your own virtual machine with root	Medium (kernel-level VM isolation)	High (full root)	Resize plan / add nodes	Low-medium	Growing sites, developers, small apps
Dedicated	A whole physical server, just yours	Highest	Highest	Add/replace hardware	High	High-traffic, compliance, heavy workloads
Cloud	VMs/containers from a pooled platform, billed by usage	Medium-high	High	Elastic, on-demand	Pay-as-you-go	Variable traffic, scale-out apps

Shared hosting¶

Hundreds of sites live on one server behind a control panel. The provider handles the OS, web server, PHP, and security patching; you just upload files and manage your site through the panel.

Pros: cheapest, zero server admin, beginner-friendly.
Cons: a noisy neighbor can slow you down, limited resources, little control over software versions, no root.
Suits: a personal blog, a brochure site, a first WordPress install.

VPS (Virtual Private Server)¶

A hypervisor carves a physical server into isolated virtual machines. You get guaranteed CPU/RAM and root access to your own OS.

Pros: real isolation, full control, install anything, predictable resources, good price/performance.
Cons: you (or your managed plan) are responsible for the OS, updates, and security.
Suits: a developer who wants control, a growing site that outgrew shared, small production apps.

Dedicated server¶

An entire physical machine is yours. Maximum performance and isolation, no hypervisor overhead.

Pros: all resources, full hardware control, strong isolation for compliance.
Cons: most expensive, you manage everything, scaling means buying more hardware.
Suits: high-traffic sites, databases with heavy I/O, workloads with strict data or compliance needs.

Cloud hosting¶

Compute, storage, and networking come from a large pooled platform (OpenStack, AWS, etc.). You spin resources up and down on demand and pay for what you use.

Pros: elastic scaling, pay-as-you-go, high availability across nodes, fast provisioning.
Cons: costs can be unpredictable, more concepts to learn, can be overkill for a static site.
Suits: apps with spiky or growing traffic, teams that need to scale horizontally, anything that must survive a single-node failure.

Managed vs unmanaged¶

Independent of the type above, a plan is either managed or unmanaged - this describes who runs the operating system and stack.

	Managed	Unmanaged
OS install & patching	Provider	You
Web server / stack setup	Provider	You
Security hardening & updates	Provider	You
Backups & monitoring	Usually included	You set up
Root access	Sometimes limited	Full
Cost	Higher (you pay for labor)	Lower
You focus on	Your website/app	The whole server

Managed suits people who want to focus on their site or business and treat the server as a service - and teams without a sysadmin. You pay more, but the provider keeps it patched, monitored, and backed up.
Unmanaged suits engineers comfortable with Linux who want full control and lower cost. You own everything from kernel updates to firewall rules.

These combine

You can have a managed VPS or an unmanaged VPS, a managed dedicated server, and so on. Shared hosting is almost always managed by definition; raw cloud instances are usually unmanaged unless you buy a managed layer on top.

Components of a hosting stack¶

A working site is several cooperating services. Here is how they relate.

        DNS (points the name at the IP)
                 │
                 ▼
   ┌─────────────────────────────────┐
   │            Server                │
   │                                  │
   │   Web server (nginx/Apache)      │  <- terminates TLS, serves files,
   │        │            ▲            │     proxies to the app
   │        ▼            │            │
   │   App runtime ──> Database       │  <- PHP/Node/Python + MySQL/Postgres
   │                                  │
   │   Mail server (SMTP/IMAP)        │  <- send/receive email for the domain
   │                                  │
   │   Control panel  ───────────────┼──> manages all of the above via a UI
   └─────────────────────────────────┘

DNS maps your domain to the server's IP and routes email via MX records. Covered in Domains and DNS for Hosting.
Web server - nginx or Apache - listens on 80/443, terminates TLS, serves static files, and reverse-proxies dynamic requests to the app. Hands-on: nginx.
SSL/TLS certificate lets the web server speak HTTPS and proves your identity. Hands-on: HTTPS with Let's Encrypt.
Database stores dynamic content (posts, users, orders). See Databases for Hosting.
Email is a separate service (SMTP to send, IMAP/POP to read), wired up through DNS records. See Email Hosting.
Control panel ties it together with a web UI for sites, domains, mailboxes, databases, and SSL. See Control Panels.
Backups and migration keep you safe and let you move between providers. See Backups and Migration.

These pieces can all live on one box (typical shared/VPS) or be split across managed services (typical cloud), but the relationships stay the same.

Verify your work¶

This page is conceptual, but you can already confirm the chain on any live site:

# 1. DNS lookup - which IP does the name resolve to?
dig +short example.com

# 2. Reach the web server and read the response headers (note Server: and the status)
curl -I https://example.com

# 3. Inspect the TLS certificate the server presents
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

If dig returns an IP, curl -I returns a 2xx/3xx and a Server: header, and openssl shows a valid certificate, you have just watched steps 1-6 happen by hand.

Summary¶

Opening a site is a chain: DNS lookup -> TCP connect -> TLS handshake -> HTTP request -> server (often + database) -> HTTP response -> render.
A hosting provider rents you compute, storage, network, and a stack of services (web server, database, DNS, email, TLS, control panel, backups), not a single product.
The four types - shared, VPS, dedicated, cloud - trade cost, isolation, control, and scaling differently.
Managed vs unmanaged is orthogonal to type: it decides who runs the OS and stack. Managed costs more but offloads ops; unmanaged is cheaper but all yours.
The stack components cooperate: DNS finds the server, the web server terminates TLS and serves/proxies, the app talks to the database, mail runs alongside, and the control panel manages it all.