What Is Web Hosting? How It Works, Types, Costs and Setup

Web hosting is the service that provides the storage, computing resources and network connectivity needed to publish a website on the internet. It serves your pages and files, runs any required server-side software, and connects to a database when the application needs one.

Your domain name is the address visitors use. Your website is the content and software they interact with. Hosting supplies the environment that makes that website reachable.

You might buy hosting separately, get it bundled with a website builder, or operate the server yourself. You do not necessarily need a separate hosting subscription or a separately purchased domain: some publishing platforms provide both hosting and a usable platform address.

This guide explains the choices in plain English, with practical examples, a cost calculation and questions to ask before paying. Technical references were checked on 22 October 2026. The numerical examples below are illustrations, not benchmarks or provider quotations.

Website, domain, DNS and hosting: what each one does

Imagine a small bakery opening a shop:

• Website: the shop's design, menu and ordering system—your pages, images, code and features.
• Domain: the address on the sign, such as example.com.
• DNS hosting: the directory that publishes the records connecting the name to the right services.
• Web hosting: the premises and operating resources—the server, storage and software environment.
• Email hosting: a separate service for mailboxes such as orders@example.com.
• Website builder or CMS: the tools used to create and update the site.

One company can supply several of these services, but they remain separate functions. Registering a domain does not automatically create your website. Buying a hosting plan does not necessarily include a domain, email accounts or website design.

You can keep a domain registered at one company, DNS at another, your website at a third and email elsewhere. This is useful flexibility, provided the records and renewal accounts stay organized.

How web hosting works when someone visits a page

The request-and-response process described in MDN's web fundamentals can be understood in six steps:

1. A visitor opens a URL. Their browser may already have some information or files cached.
2. DNS helps locate the service. The name resolves to an address or a chain of names. The destination may be a CDN, reverse proxy or load balancer rather than the origin server itself.
3. The browser establishes a connection. With HTTPS, TLS protects the connection and the browser checks the certificate.
4. The receiving system handles the request. A web server such as Apache, Nginx or LiteSpeed may return a file, use a cache, or forward the request to an application.
5. The application does any necessary work. It might query a database or call another service, then generate a response.
6. The browser receives and renders the result. HTML, CSS, JavaScript, images and fonts can involve multiple requests. Browser-side JavaScript may make further API calls.

The browser normally receives the application's output, not its private database, server-side source files or credentials. Those need to remain protected on the server.

There is no universal promise that the whole page arrives in a few milliseconds. Connection quality, distance, caching, application work and page size all affect the experience.

Static and dynamic websites need different things

A static website serves files prepared in advance. It can still look interactive and use browser-side JavaScript. A portfolio, documentation site or brochure website may fit this model; GitHub Pages is one example of a static publishing service.

A dynamic website performs server-side work for requests. WordPress, customer dashboards, search services and checkout flows may need application runtimes, databases and background jobs. Caching can avoid rebuilding some public pages, but personalized or transactional responses need appropriate handling.

A static frontend can also call a separate backend. That backend still needs hosting somewhere, even if the frontend's hosting is free.

The main hosting options and their trade-offs

These labels describe different aspects of a service. “Managed cloud WordPress hosting” can combine infrastructure, management and application choices. They are not mandatory steps on a ladder from shared hosting to a dedicated server.

Shared hosting

Multiple customer accounts share a server's capacity. A control panel usually provides file, database and email management. The host operates the server platform; you still maintain your site's content, accounts and application software unless the plan includes that work.

Useful for: straightforward blogs, portfolios and small business sites using supported software.

Check: CPU and memory limits, account isolation, available runtimes, backups and support scope. Neighboring workloads and how the provider controls them can affect performance; the label alone does not tell you the result.

VPS and virtual dedicated plans

A virtual private server gives you a virtual machine or similar isolated environment with allocated resources. Root or administrator access is common, but depends on the product.

Useful for: custom applications, additional software, more configuration control or workloads needing their own environment.

Check: whether CPU is shared, dedicated or burstable; what memory is allocated; storage and network limits; licensing; and who maintains the operating system. A listed vCPU is not automatically a dedicated physical core. DigitalOcean's CPU-plan documentation illustrates why these distinctions matter.

Names such as VDS or “virtual dedicated” vary between providers. Compare the written allocation and isolation terms.

Dedicated servers

You rent a physical server assigned to your organization. This provides substantial configuration control and avoids sharing that machine with other customers.

Useful for: particular hardware requirements, sustained workloads or an architecture designed around dedicated machines.

Check: management, replacement procedures, storage resilience, monitoring and recovery. Renting a whole server does not automatically make an application faster, secure or compliant. It also does not make a single machine highly available.

Cloud hosting

Cloud services provide infrastructure through a provider's resource pool. The product might be a single virtual machine, a managed application service or an architecture spread across multiple systems.

Useful for: workloads that benefit from flexible provisioning or specific managed cloud services.

Check: the actual architecture. Autoscaling, database failover and multi-zone redundancy must be supported and configured; “cloud” alone does not mean that another server instantly takes over. AWS's Auto Scaling documentation describes capabilities that an application architecture can use, not a guarantee attached to every cloud instance.

Scaling up adds capacity to an instance; scaling out adds instances. The application, database and shared storage must support the chosen approach.

Managed hosting and managed WordPress

Managed hosting is a service arrangement layered onto shared, virtual, cloud or dedicated infrastructure. A provider performs specified operational tasks.

Useful for: teams that want help maintaining a supported stack.

Check: exactly which updates, backups, restores, incident investigations and application fixes are included. Managed WordPress may add caching, staging and update tools, while restricting certain plugins or server changes. “Managed” does not universally include every task.

Reseller hosting

A reseller package lets an agency or business create and sell hosting accounts under its own commercial arrangement.

Useful for: designers and agencies managing multiple client sites.

Check: whether clients get separate accounts, individual and aggregate resource limits, licenses, billing tools, migration support and responsibility for customer support. Reseller hosting describes how services are packaged and sold; it does not necessarily provide a separate server.

Website builders, static platforms and serverless services

A hosted builder combines creation tools with hosting. Compare supported features, customization and what can be exported before assuming the site can move intact.

Static platforms publish built files, often through a CDN. Application platforms, containers and serverless functions can run supported backend code while the provider manages more of the underlying infrastructure. Servers still exist; your access, execution limits, scaling behavior and billing model differ.

Check runtime versions, request and execution limits, persistent storage, background jobs and database connections. A free frontend deployment does not imply free databases, email, file storage or unlimited backend execution.

Colocation is another arrangement: you own the physical equipment and rent data-center space, power and connectivity. It involves a different level of operational responsibility from buying a normal hosting account.

What a hosting plan's specifications actually mean

Start with the application you need to run, then compare the limits that affect it. CloudLinux's resource-limit documentation explains several terms commonly shown on shared-hosting plans.

Storage, SSD, NVMe and inodes

Storage capacity covers files and databases, and may also include email, logs, caches and locally stored backups. Ask what counts toward the allowance and what happens when it fills.

NVMe is a storage protocol commonly used with SSDs; it is not a promise of a particular website speed. Faster storage can help a disk-bound workload, while a cached page or a slow external API may see little benefit. Account I/O limits, CPU, database queries and contention also matter. Avoid interpreting a drive benchmark as “this website loads six times faster.”

Inodes broadly track filesystem objects such as files and directories. Many thumbnails, cache files or mail files can exhaust an account's inode allowance before its storage capacity. Exact accounting depends on the platform.

CPU, RAM and concurrent work

CPU performs computation. RAM holds the working data of applications and processes. More of either helps when it addresses the actual bottleneck; adding CPU does not fix every slow database query or network call.

On shared hosting, ask whether “memory” means an account-wide limit, a PHP process setting or something else. On a VPS, the OS, database, control panel and application share its memory.

Entry processes (EP) on CloudLinux limit entries into the account's resource environment, commonly involving concurrent dynamic requests and other supported entry points. They are not the number of people allowed to read your site. NPROC, application-worker and database-connection limits measure different things. Ask which limit is being hit before choosing an upgrade.

I/O, IOPS, bandwidth and transfer

• I/O throughput: how much data can be read or written per second.
• IOPS: how many storage input/output operations are allowed per second.
• Network bandwidth: a data-transfer rate, usually expressed in Mbps or Gbps.
• Monthly transfer allowance: a volume, usually expressed in GB or TB. Hosting pages often call this “bandwidth,” so check the units.

“Unmetered” or “unlimited” still requires reading the acceptable-use, resource and fair-use terms. Check egress, overage and suspension policies.

Illustrative transfer calculation: 10,000 visits × 3 page views per visit × 2 MB transferred per page view is about 60 GB using decimal units. This excludes other traffic and assumes that transfer size for each view. Caching, bots, downloads, APIs and email can change the result. It estimates transfer, not the CPU or RAM required.

Software, operating systems and control panels

Verify supported runtimes and versions, database engines, extensions, scheduled tasks, SSH/SFTP access, deployment tools and restore options.

Linux is common for PHP, WordPress and many application stacks. Windows may be needed for particular legacy software or Windows-specific dependencies. It is inaccurate to say all ASP.NET or SQL Server workloads require Windows: Microsoft documents ASP.NET Core on Linux and SQL Server on Linux. Check the application's actual dependencies and supported features.

cPanel, Plesk, DirectAdmin and provider dashboards are management interfaces, not hosting architectures. A familiar panel does not prove a particular runtime is supported. Your laptop's operating system does not determine which server OS your website needs.

How much hosting capacity does your website need?

Monthly visitor counts alone cannot determine an exact RAM or CPU requirement. Ten thousand visits spread over a month differ from a burst of orders arriving together. Public cached pages differ from logged-in dashboards, imports and checkout requests.

Use these starting questions:

• Brochure or portfolio: can it be published as static files, or does it need a CMS and forms service?
• WordPress blog or business site: which plugins, scheduled jobs, cache and backup tools will run?
• Online shop: how demanding are uncached product searches, cart/checkout, payments and background tasks?
• Custom application: does it need persistent Node.js, Python, Java or another runtime, WebSockets, workers or queues?

A WordPress-oriented plan may not support a long-running Java or Node service. A Next.js site exported to static files has different requirements from one using server-dependent features; Next.js documents those export limitations.

There is no universal rule that every shop needs 2 GB or 4 GB of RAM. Start with the software's requirements, test representative requests and measure CPU, memory, worker saturation, database time and errors during expected peaks.

For WordPress, the current official recommendations include PHP 8.3 or newer, MariaDB 10.11 or newer or MySQL 8.0 or newer, and HTTPS. Those are platform recommendations, not a complete performance sizing formula.

Worked example: a bakery choosing its first hosting

This is a hypothetical decision, not a Hostlelo customer story or a performance test. Imagine the bakery above needs a menu, opening hours and a contact page. It may later add online ordering. The hosting choice changes with what the website must actually do.

A menu and contact page

If the pages can be prepared in advance and ordering happens through a separate service, a static publishing platform or hosted website builder may be enough. The bakery need not buy a server plan just to display a menu. It should still check custom-domain support, form handling, export options, usage limits and who is responsible for the separate ordering service.

A site staff can edit in WordPress

If staff need to change pages and publish posts in WordPress, a shared or managed plan that supports WordPress's current PHP, database and HTTPS requirements is a plausible starting point. Ask who updates WordPress and plugins, what backups include, how a restore works and whether email is separate. A VPS is not automatically required for a small WordPress site.

Orders handled by the bakery's own application

If the website itself manages customer accounts, stock and checkout, its application code and database need a compatible environment. Login, cart and payment steps may not benefit from the same public-page cache as the menu. The developer should test those important actions at expected peak activity and protect payment and customer data appropriately. A managed application service or VPS might fit, depending on the software and who will maintain it; neither label guarantees performance or compliance.

The decision is therefore not “At what monthly visitor count do I need a VPS?” It is “Which software must run, which requests cannot be cached, what limits might be reached, who fixes incidents, and how will we restore orders?” Compare written answers and the full initial and renewal cost. Revisit capacity only when representative tests or resource data show a real constraint.

Uptime, server location and CDN: what the promises mean

Put an uptime percentage into context

Availability is the proportion of the measurement period that the defined service is available. For a 30-day month, simple arithmetic gives:

• 99%: 7 hours 12 minutes unavailable.
• 99.9%: 43 minutes 12 seconds unavailable.
• 99.99%: approximately 4 minutes 19 seconds unavailable.

Over a 365-day year, 99.9% corresponds to about 8.76 hours and 99.99% to about 52.56 minutes. These are mathematical equivalents, not predicted outages or permission for a provider to schedule that downtime.

An SLA defines what is measured, exclusions, the reporting period and any remedy. Many infrastructure SLAs use monthly service credits and eligibility conditions; Google Compute Engine's SLA is an example. A server-network commitment is not automatically an end-to-end guarantee covering your application, DNS, database and third-party services.

Choose location using your visitors and architecture

A well-connected origin closer to visitors can reduce network latency, particularly for uncached dynamic work. Routing, peering, application processing and the database location also affect results.

For an audience in the UAE or Gulf, compare measurements from those locations. A provider being registered in Dubai does not establish that its servers are in Dubai. Ask where the application, database and backups are stored, and whether that arrangement meets your project's requirements.

A CDN can serve eligible cached content from locations nearer to visitors. It does not automatically cache every response or remove the need for a healthy origin. Cloudflare, for example, does not cache HTML or JSON by default.

Keep private account pages and personalized checkout data out of shared public caches. Test important user journeys, not just a cached homepage.

Security, backups and who is responsible

Hosting security is shared work. AWS's shared-responsibility model illustrates how responsibilities change with the service used; a managed website package and a self-managed VM leave different tasks with the customer.

Get clear answers about:

• Platform maintenance: who patches the OS, web server, runtime and database?
• Site maintenance: who updates the CMS, plugins and themes, and fixes compatibility problems?
• Access: can you use multifactor authentication, separate accounts and appropriate permissions?
• Protection: what do WAF, malware and DDoS services cover, and what happens during an incident?
• Recovery: who restores the site, how quickly, and at what cost?

TLS, commonly sold as “SSL,” protects data in transit. A valid certificate does not prove a website is free of malware or that its payment handling meets every requirement. Automatic certificate issuance and renewal can be provided through systems such as Let's Encrypt; confirm renewal is actually configured.

WAF and DDoS services can reduce exposure to particular attacks. They do not replace application updates, secure configuration or incident response, and they do not make attacks impossible.

Ask how a backup becomes a working website again

Check backup frequency, retention, files and database coverage, independent storage, access controls, restore fees and whether email is included. A snapshot or copy on the same account is not automatically protected from every account compromise or server failure.

Two useful questions are: How much recent data could we lose? and How long would restoration take? These are recovery point and recovery time objectives. Daily backups can leave a significant gap for a busy shop; restoration time depends on the system and process.

Keep an independently controlled copy where appropriate and test restores. AWS's reliability guidance explicitly includes periodic recovery checks. A “backup completed” notification alone does not prove that a usable site can be restored.

What hosting includes—and what may cost extra

The core service provides some combination of storage, compute and network access. Check the actual package for:

• Domain registration and its renewal.
• Email mailboxes, storage, outbound limits and delivery support.
• Certificates and renewal automation.
• Backups, retention and restoration.
• Website builder, staging and developer tools.
• Control-panel and other software licenses.
• Migration, monitoring, incident help and application support.

Website design, content writing, search optimization, paid plugins, payment fees and ongoing application development are separate unless explicitly included.

SFTP access or an export tool also does not guarantee that every feature of a hosted builder is portable. Confirm how to export files, content and databases, what will need rebuilding, and whether you retain access after cancellation.

How much does web hosting really cost?

There is no single meaningful price without the application, service scope, billing term and currency. Compare total cost over the period you intend to use the service.

Include hosting, domain renewal, email, licenses, backups, traffic/egress, management, migration and taxes. On usage-based services, also check requests, function execution, storage operations, database usage and resources that keep billing while idle. A budget alert is not necessarily a hard spending cap.

A purely illustrative two-year budget, in USD:

• Assume monthly-billed hosting costs $4 per month in year one and $8 per month in year two.
• Assume a domain costs $12 initially and $18 to renew.
• Assume two mailboxes cost $3 each per month throughout.
• Year one: $48 hosting + $12 domain + $72 email = $132.
• Year two: $96 hosting + $18 domain + $72 email = $186.
• Total: $318 before tax, software, labor or other extras.

These invented numbers describe no provider's offer. They show why an advertised hosting rate is not the whole website budget. Some providers keep the same renewal price; others use introductory discounts.

If “$4/month” requires a 36-month purchase, the hosting payment alone could be $144 upfront. Check the checkout total, renewal term, cancellation rules, refund exclusions and who controls any bundled domain.

Our renewal-price guide explains how to compare real offers. For disclosure, Hostlelo publishes this article and sells hosting; use the same questions when reviewing our plans or another provider's.

Get your first website online: a practical sequence

1. Choose how the site will be built. A hosted builder, WordPress site, static site and custom backend need different environments. An AI-generated website still needs a suitable deployment environment; keep private API keys out of browser-delivered code.
2. Choose a domain and keep ownership clear. Use an account your business controls, check renewal costs and protect recovery access. A platform address may be enough for an initial demo.
3. Choose the hosting and management scope. Verify software support, limits, region, recovery and total cost before buying.
4. Deploy and test before changing live DNS. Install the application or upload the build, configure the database and test critical functions. A first WordPress install can use a supported installer; our Softaculous guide covers that workflow.
5. Connect the domain carefully. Update the correct DNS zone. Preserve existing email and verification records if moving nameservers. Follow our domain connection guide.
6. Enable HTTPS on intended hostnames. Verify issuance, redirects and automatic renewal. If using a CDN, check the origin connection too. Our HTTPS guide covers an Apache redirect setup.
7. Configure email if needed. Preserve or create the correct MX records and configure SPF, DKIM and DMARC. Authentication helps receivers assess messages; it does not guarantee inbox placement. See our email authentication guide.
8. Test from outside your admin session. Check mobile pages, forms, login, password resets and any checkout in its test mode. Confirm expected responses, working backups and monitoring.
9. Maintain the site after launch. Assign ownership for renewals, updates, alerts, restores and support. Verify it in Search Console when appropriate and submit its actual sitemap.

For the website connection, the provider may supply an A record for an IPv4 address, an AAAA record for IPv6, or a CNAME pointing to another hostname. Use the exact records supplied for that platform. Updating website records can leave DNS and email management in place; changing nameservers moves which DNS service answers for the domain and requires preserving the full zone.

For an existing site, plan a migration with a verified backup, a rollback path and a final data sync where needed. Keep the old environment available until the new one is tested. Our WordPress migration guide explains a practical route.

Common mistakes and when to upgrade

Avoid buying on storage size or the first-year price alone. “Unlimited,” “cloud,” “NVMe” and “managed” need supporting limits and service definitions. A free certificate does not replace backups; a dedicated machine does not replace security work.

Upgrade when measurements identify the limit: sustained CPU saturation, memory pressure, worker queues, slow database queries, storage limits or repeated resource faults. First examine caching, large assets, inefficient code and database work.

More capacity may be appropriate, but the right change could also be better caching, a separate worker, a different CPU allocation or improved application design. Test again after the change. For planned interruptions, use an appropriate 503 maintenance response and verify normal service afterwards.

Reliable hosting supports availability and a good user experience. It does not guarantee search rankings, sales or inclusion in AI answers.

Questions to send a hosting provider

Ask for written answers that match your actual project:

I need hosting for [website/app and software versions].
My users are mainly in [locations], with [normal and peak activity].
The site needs [database, mailboxes, workers, storage and integrations].

Please confirm:
- Supported software, per-account limits and CPU allocation.
- What management, security and application support include.
- Server/database/backup locations and the uptime SLA scope.
- Backup retention, restore testing, fees and recovery process.
- Full initial payment, renewal, licenses, taxes and usage charges.
- Migration/export options and what happens at resource limits.

Choose a service whose supported software, operational responsibilities and written limits fit your measured workload.