Hosting and cloud

A website is a set of files and often a program that builds pages and talks to a database. Hosting is where they live: a server in a data centre with a fast connection and a public IP address. Your domain's DNS records point at that server, so typing the name brings visitors to it.

The options form a ladder. Shared hosting puts many small sites on one server; a VPS gives you your own virtual machine; app platforms and serverless functions run your code without you managing a machine; static hosts and CDNs serve prebuilt files from many locations. Each step trades money or effort for control, speed or scale.

There are still servers; you just never see them. You write small functions (handle this form, return these products) and the platform starts copies on demand, runs as many at once as traffic needs, and shuts them down when things go quiet, which is called scaling to zero. Billing is per request and per unit of compute time rather than per month.

AWS Lambda popularised the model, and Vercel Functions, Netlify Functions, Google Cloud Run functions, Azure Functions and Cloudflare Workers follow it. The catches: a function that has been idle can take a moment to start (a cold start), each run has a time limit, nothing stays in memory between requests, and many functions opening their own database connections can overwhelm a database unless a connection pooler sits in between.

A CDN already keeps copies of files in hundreds of cities, known as the edge of the network. Edge functions put code there too: a request from Mumbai is handled in or near Mumbai, one from London in London. Most run in V8 isolates, lightweight sandboxes built on the JavaScript engine from Chrome, which start in milliseconds, so there is little of the cold-start delay that regular serverless functions have.

The trade-off is a slimmed-down runtime: web-standard APIs such as fetch rather than all of Node.js, tight CPU limits and small bundles. Speed also depends on where the data lives; an edge function that queries a database on another continent can end up slower than a regular function sitting next to that database. Cloudflare Workers, Deno Deploy, Netlify Edge Functions and Supabase Edge Functions are examples.

That lesson has shaped the platforms. Recent versions of Next.js no longer support the edge runtime for pages and routes and run them on Node.js in a chosen region instead, while edge code remains popular for redirects, sign-in checks and caching in front of an app.

Without a CDN, every visitor fetches every file from your one server, which may be thousands of kilometres away. A CDN caches copies in many cities and answers from the closest one, which cuts load times and takes most of the traffic off your server. It also absorbs traffic spikes and many attacks, and usually handles HTTPS for you.

What gets cached, and for how long, is controlled by HTTP headers such as Cache-Control, and a purge clears old copies after a change. Cloudflare, Fastly, Akamai, Amazon CloudFront and Bunny are standalone CDNs; Vercel, Netlify and Cloudflare Pages include one automatically.

Vercel builds your project on each push, serves static files from its global CDN and turns server code (API routes, server-rendered pages, server components) into functions automatically. Every branch and pull request gets its own preview URL, which makes review with clients and teammates simple. Most frameworks are supported, but Next.js features such as ISR and image optimisation work there with no setup, because the same company builds both.

Around the hosting sit extras: Web Analytics, Speed Insights, a firewall, Blob storage, cron jobs, the AI SDK and AI Gateway, and a marketplace that connects databases such as Neon, Supabase and Upstash. Pricing combines a seat fee with metered usage (bandwidth, function time, image transformations), and spend management can alert you or pause projects at an amount you set.

Netlify helped popularise the Jamstack approach of prebuilt pages served from a CDN; its co-founder coined the name. Connect a repository and each push is built and deployed, with a deploy preview for every pull request and instant rollback to any earlier version. It is framework-agnostic and works well with Astro, Nuxt, SvelteKit, Next.js and plain static sites.

Serverless functions, edge functions (which run on Deno), built-in form handling, Netlify Blobs storage and a managed Postgres database cover light backend needs. Billing is based on credits: each plan includes a monthly allowance, and deploys, bandwidth, requests and compute all draw from it, so a busy site on the free plan pauses when its credits run out rather than running up a bill.

Push HTML, CSS and JavaScript (or the output of a static site generator) to a repository and GitHub serves it at username.github.io or on your own domain, with free HTTPS. It builds Jekyll sites by itself, and a GitHub Actions workflow can build anything else, from Astro to a Vite app.

There is no server code and no database, only files. Published sites can be up to 1 GB with a soft bandwidth limit of 100 GB a month, and GitHub's rules do not allow using it mainly to run an online shop or a commercial software service.

When a domain uses Cloudflare, visitors connect to Cloudflare's servers in a nearby city first. Cloudflare answers from its cache when it can, filters out attacks and abusive bots, and passes the rest on to your real server (the origin). Even the free plan includes DNS, the CDN, a free SSL certificate and unmetered DDoS protection, which is why so many small sites sit behind it.

On top of that network sits a developer platform: Workers for code, Pages for sites, R2 for files, KV and D1 for data, Durable Objects for shared state, Queues and Workers AI. Cloudflare also sells domains at cost through Cloudflare Registrar, offers Turnstile as a CAPTCHA alternative, and runs Zero Trust tools that secure company networks.

Pages builds a repository on each push (or accepts a prebuilt folder), publishes it to Cloudflare's network and gives every branch a preview URL on pages.dev. Static requests and bandwidth are free and unlimited on every plan, which makes it a popular home for sites that may get sudden traffic. Pages Functions add server code that runs on Workers, with access to KV, R2 and D1.

The free plan allows 500 builds a month, one at a time, with up to 20,000 files per site and 25 MiB per file. Cloudflare Workers can now serve static sites too (Workers static assets), with extra features such as cron triggers and Durable Objects, and Cloudflare publishes a guide for moving Pages projects across, so new projects often start on Workers instead.

A Worker is a function that receives a web request and returns a response. Instead of containers, Workers run in V8 isolates, lightweight sandboxes inside one process, so they start in milliseconds and cost very little to keep ready. The same Worker can serve a site's static files for free, run an API, change pages on the way through, or run on a schedule with cron triggers.

Workers reach other Cloudflare services through bindings: KV and D1 for data, R2 for files, Durable Objects for per-room or per-user state (useful for chat and multiplayer), Queues, and Workers AI for models. The runtime speaks web standards (fetch, Request, Response) and supports many Node.js APIs through a compatibility flag, though not every npm package works. The runtime itself, workerd, is open source.

KV stores values (text, JSON or binary, up to 25 MiB each) under keys inside namespaces, and caches popular keys in Cloudflare's data centres so reads are fast worldwide. A Worker reads it through a binding with a call such as env.CONFIG.get('theme'), and writes go through the same API, the dashboard or Wrangler.

It is eventually consistent: a change can take 60 seconds or more to show up in other locations. That suits feature flags, redirects, configuration and cached API responses, but not counters, stock levels or anything two users might change at once, where D1 or Durable Objects fit better.

R2 keeps files as objects in buckets, like Amazon S3, and speaks the same API, so most S3 tools and SDKs work once you change the endpoint and keys. The difference is pricing: storage and operations cost money, but serving files to the internet (egress) is free, which matters for media-heavy apps where downloads usually dominate the bill.

Buckets can stay private, reached through signed URLs or a Worker, or be public through a custom domain behind Cloudflare's cache; the r2.dev address is rate-limited and meant for testing. Workers read and write R2 directly through a binding. There is also an Infrequent Access class for archives, event notifications, and tools (Super Slurper and Sippy) that copy data across from S3.

wrangler dev runs a Worker on your machine with workerd, the same runtime Cloudflare uses in production, plus local copies of KV, R2 and D1. wrangler deploy uploads it, wrangler tail streams live logs, and commands such as wrangler secret put and wrangler d1 migrations apply handle secrets and database changes.

Settings live in a wrangler.jsonc or wrangler.toml file beside the code: the Worker's name, compatibility date, routes, bindings and variables. Keeping that file in Git makes deployments repeatable and easy to run from CI.

AWS rents computing by the hour, the second or the request. The core pieces are EC2 virtual servers, Lambda serverless functions, S3 file storage, RDS and Aurora managed SQL databases, DynamoDB, the CloudFront CDN, SES for email and IAM for permissions. Simpler bundles such as Lightsail (fixed-price servers) and Amplify (frontend hosting) exist for smaller projects.

It runs regions on every inhabited continent, including Mumbai and Hyderabad in India. Its breadth is the draw and also the difficulty: permissions, networking and billing take real skill, and costs such as data transfer and forgotten resources surprise many teams. Budgets and billing alerts are worth setting up on the first day.

S3 stores objects in buckets, each addressed by a key, and is designed for eleven nines (99.999999999%) of durability by keeping copies across several facilities. Apps upload through presigned URLs, serve files through CloudFront, and use lifecycle rules to move older data to cheaper classes such as Standard-IA and Glacier.

Launched in 2006, it set the standard: Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Supabase Storage and MinIO all offer S3-compatible APIs. Its price has several parts (storage per GB, requests per thousand, and data transfer out to the internet), and for popular public files the transfer part usually dominates.

Google Cloud offers Compute Engine virtual machines, Cloud Run for containers that scale to zero, Cloud Run functions, Google Kubernetes Engine (Kubernetes began at Google), Cloud Storage, Cloud SQL, Firestore, BigQuery for analytics and Vertex AI for Gemini and other models. Firebase projects are Google Cloud projects underneath, so the two share billing and permissions.

Cloud Run is a common way in for app developers: hand it a container image and it serves HTTPS, scales with traffic and bills for the time spent handling requests. Google has regions in Mumbai and Delhi. Like the other big clouds it rewards expertise, and IAM roles, networking and quotas take time to learn.

Azure covers the same ground as AWS and Google Cloud: virtual machines, App Service for web apps, Azure Functions, Azure SQL and Cosmos DB, Blob Storage, Kubernetes (AKS) and Static Web Apps for frontends. Its identity service, Microsoft Entra ID (formerly Azure Active Directory), links cloud resources to the accounts a company already uses for Outlook and Teams.

That fit with Microsoft's world is its main draw: enterprise agreements, Windows Server and SQL Server licences, and GitHub, which Microsoft also owns. It also hosts OpenAI's models for companies that want them under Microsoft's contracts and data rules. Azure has several regions in India, including Pune, Chennai and Mumbai.

Run fly launch in a project and Fly.io builds a container image, then starts it as Fly Machines (fast-booting micro virtual machines built on Firecracker) in the regions you choose. Apps get a global anycast address, private networking between machines, persistent volumes and managed Postgres. Machines can stop when idle and start again on the next request.

It suits apps that need a real long-running server, such as WebSocket services, background workers or SQLite on a volume, spread across regions. You handle more yourself than on Render or Heroku: sizing machines, placing volumes and planning failover. New accounts get a short trial rather than a free allowance, and pricing is purely usage-based.

Connect a repository, pick a service type and Render builds and deploys on every push, with HTTPS, zero-downtime deploys and private networking between services. Managed Postgres and Key Value (Redis-compatible) sit beside the apps, and a render.yaml Blueprint file describes the whole setup as code so it can be recreated in one step.

It is often chosen as a modern replacement for Heroku. Free web services exist but spin down after 15 minutes without traffic and take about a minute to wake, and free Postgres databases expire after 30 days, so they suit demos rather than production. Paid services run on fixed-size instances.

A Railway project is a canvas of services: an app from GitHub, a Postgres, MySQL, Redis or MongoDB database added in a click, workers and cron jobs, all joined by a private network and shared variables. Railway works out how to build most projects by itself, gives each service a URL and can spin up preview environments for pull requests.

Billing follows usage: memory, CPU and storage are metered by the second, and each paid plan's monthly minimum includes the same amount of usage. That keeps small or idle apps cheap, but a busy service's bill moves with its load, so usage limits are worth setting.

Heroku popularised the model other app platforms follow: push code, and buildpacks detect the language, build it and run it on dynos (containers) behind a router. Add-ons attach Postgres, key-value stores, logging and email in a few clicks, and the twelve-factor app guidelines written at Heroku still shape how cloud apps are built.

Free dynos ended in November 2022, so the cheapest options are now paid. In 2026 Heroku moved to what it calls a sustaining engineering model: the platform stays supported, with the focus on stability and security rather than new features, and enterprise contracts are no longer offered to new customers.

You rent an account on a server the host runs, with a control panel such as cPanel or Hostinger's hPanel, one-click WordPress, email accounts, a MySQL database and file access over FTP. The host handles the operating system, security patches and the web server, so there is nothing to administer beyond your own site.

Because everyone shares the machine's CPU and memory, a busy neighbour can slow your site, and plans cap resources quietly. Traditional plans suit PHP and static files; long-running Node.js or Python servers, background workers and custom software usually need a VPS or an app platform, though some hosts now offer limited Node.js. Intro prices assume paying for several years up front, and renewals cost several times more.

A provider splits a powerful server into virtual machines, each with a set amount of memory and disk and a share of the CPU. You get root access over SSH to a fresh Linux install (usually Ubuntu or Debian) and can run anything: Node.js or Python apps, databases, Docker containers, Nginx, cron jobs and WebSocket servers.

The flip side is that you are the system administrator: security updates, firewalls, backups, monitoring and recovery when something breaks. Tools such as Coolify, Dokku and CapRover add a Heroku-like deploy layer on top of a VPS. DigitalOcean, Hetzner, Vultr, Linode (now Akamai), AWS Lightsail and Hostinger are common providers.

DigitalOcean started with Droplets, virtual servers that launch in under a minute with a monthly price cap, and grew into a compact cloud: App Platform for Git-based deploys, managed PostgreSQL, MySQL, Valkey and MongoDB, Spaces object storage (S3-compatible, with a built-in CDN), managed Kubernetes, load balancers and serverless Functions. It has a data centre in Bengaluru.

It sits between a bare VPS host and the big clouds: fewer services than AWS, but a cleaner dashboard, predictable bills and a data transfer allowance included with each Droplet. Its free community tutorials on Linux, Nginx and deployment are widely used, even by people who host elsewhere.

Hetzner runs its own data centres in Germany and Finland and has cloud locations in the US (Virginia and Oregon) and Singapore. Hetzner Cloud sells virtual servers billed by the hour with a monthly cap, plus load balancers, firewalls, volumes and S3-compatible object storage. Separately it rents whole dedicated servers, including older hardware through a server auction.

It has long been known for low prices on plenty of CPU and memory, with 20 TB of traffic included on EU cloud servers. In 2026 it raised prices, sharply for dedicated-CPU plans, and stock of its cheapest cloud tier is limited. Support and extras are leaner than at AWS or DigitalOcean, and new customers may be asked to verify their identity.

On a typical VPS, Nginx listens on ports 80 and 443, serves static files itself and forwards other requests to an app on a local port, such as Node.js on 3000 or Gunicorn for Python. It terminates HTTPS (often with free Let's Encrypt certificates from Certbot), compresses responses, caches, rate-limits and balances load across several app servers.

Its event-driven design handles many thousands of connections with little memory, which is why it runs a large share of the world's websites. Configuration lives in text files made of server and location blocks. F5 owns the company behind it and sells NGINX Plus with extra features and support; Caddy and Traefik are simpler alternatives with automatic HTTPS.