Web hosting

What it means

Web hosting provides the environment that serves a website's files or runs its server-side application, together with the connectivity needed to receive requests. The environment might be a file-publishing service, a shared account, a virtual machine or a physical server. What matters is whether it supports the site's actual work and which operational tasks the agreement assigns to you. A domain identifies a name; it is not the machine that serves the site. Web server roles · Publishing and domain choices

Try it

Simulation — follow a request through a small hosting environment. Start with the static site and run to the result. Then choose the dynamic site without changing the environment: the trace stops at the missing runtime. Add the runtime, then the database capability, and compare the outcomes. The example dynamic application explicitly needs a database; not every dynamic site does.

The scene is local and uses declared capabilities, not a provider recommendation or availability measurement. Back reviews the trace; Reset restores the static example, service plan, fault and position. Without JavaScript, the initial example is a static site with reachable networking and published files: its modeled request can complete.

Follow the work, not the product label

A static server can return a prepared HTML document, stylesheet, image or JavaScript file. The browser may then run that JavaScript and react to the visitor. That browser activity does not turn the original file delivery into server-side page generation. A dynamic server runs application logic before producing some responses. The difference concerns where and when the work happens, not whether the page looks modern. Static and dynamic serving

In our example, a brochure site needs published files and a reachable serving endpoint. A database-backed catalog needs those basics plus its compatible application runtime and database access. The lab stops at the first unsatisfied dependency. It deliberately does not invent an HTTP status for each failure: a disconnected network, an unavailable application and a missing file need not produce the same observable symptom.

This is a dependency explanation, not a complete protocol trace. DNS resolution, TLS negotiation, routing through a CDN, authentication and application-specific behavior are outside the scene. An actual request may involve several services; the host shown in a sales dashboard need not be the only component serving it.

Capabilities and responsibilities are different questions

A capability tells you what the environment can do. Responsibility tells you who must keep it working. A runtime being available today does not answer who applies tomorrow's security update. Likewise, storage capacity does not say whether a deleted database can be restored.

These are our evaluation questions, not universal promises. The lab's managed and self-managed plans are explicit teaching contracts. Real services can draw the line elsewhere. For example, Amazon's EC2 documentation assigns customers responsibility for the guest operating system, software and security configuration while AWS operates the underlying infrastructure. That is evidence about EC2, not a definition of every managed hosting product. EC2 responsibility boundary

Resources do not explain everything

Before treating a larger server as a solution, identify the bottleneck or missing capability. Extra memory will not publish an omitted file. More CPU does not give a static-only product a server-side runtime. A plan with generous disk space still needs a data-retention and recovery process.

For a capacity discussion, record the workload, expected concurrency, largest responses, storage growth and maintenance needs. Ask how the provider measures the relevant limits and what happens when they are reached. Keep marketing labels separate from the guarantees written into the particular service agreement. This article does not estimate visitors per server or compare advertised benchmarks.

In practice

For a small documentation site, first confirm that the deployment produces complete static output and that the host can serve its routes and assets. For a custom application, separately establish runtime compatibility, persistence, background-work requirements and the recovery path. A database on another service is still a dependency; moving it off the web machine does not remove it from the design.

Before connecting a custom domain, check the host's hostname and HTTPS setup. Registration, DNS and publishing remain distinct tasks even when a platform presents them in one wizard. A successful upload alone does not prove the public name points to that deployment. Publishing options

Write a short responsibility record: the service owner, deployment owner, application maintainer and person able to restore the data. When a task is not clearly covered, mark it unresolved rather than assuming the hosting provider performs it.

Keep the boundary clear

Hosting supplies a serving environment, not an automatic guarantee of security, recovery or uninterrupted availability. Match capabilities to the request's dependencies, then match operational responsibilities to a real agreement. Use the lab to explain why a dependency is missing; use the provider's current documentation and your own verified deployment to establish what a real service does.