Glossary
Web hosting
Web hosting provides the operational environment for a website. It does not automatically include a domain, application management, or high availability; these depend on the specific service and the team’s responsibilities.
Short definition
Resources for an available website, not complete application management.
A web hosting provider rents out part of the infrastructure needed to make a website available over the internet. Depending on the service, this can include disk space, processing power, memory, networking, an operating system, a web server, a PHP runtime, a database, backups or technical support. Responsibility for application updates, data, access permissions and operational limits must always be defined explicitly.
A simple brochure website and an application with PHP, PostgreSQL, Redis, workers and integration jobs have different requirements. Shared hosting may be sufficient for the former, but may not allow long-running processes, custom services or detailed network configuration. A VPS, cloud service or managed platform offers more options while also placing a greater share of operational responsibility on the team or its suppliers.
The problem it solves
It gives an application a place and the conditions to run
Web hosting provides the technical environment that allows a visitor to access web content or use an application through a domain.
- running a static website, online store, administration interface or HTTP API
- running the PHP runtime, a database and, where needed, a cache or message queue
- connecting a public domain, DNS records and a TLS certificate according to the selected model
- basic operational services such as logs, monitoring, backups and administrator access
- separating development, test and production environments according to project needs
Practical example
The same website, three different operational profiles
A brochure website with a few pages primarily needs secure file delivery, a domain and HTTPS. A small PHP online store also needs a suitable PHP version, database, backups, email or payment integrations and a way to deploy changes. An application with PostgreSQL, Redis, a worker and scheduled imports additionally requires isolated services, memory and storage monitoring, network rules and a sensible approach to outages.
This is not a ranking of the “best hosting.” The right choice depends on how the application operates, the sensitivity of its data, expected traffic, recovery requirements and who has the skills to manage the environment. The selected service must also be clearly documented for the next administrator.
How it works
From a domain to a running application
Text diagram: domain name → DNS → hosting infrastructure → web server → application and data → HTTP response.
- The domain receives a DNS record DNS points the domain name to the provider infrastructure or another public application entry point.
- The client connects over HTTPS A browser or other client establishes a connection with the public service and verifies the certificate for the name.
- The web server accepts the request It returns static content or forwards the dynamic part to PHP-FPM or another runtime.
- The application uses internal services As needed, it uses a database, cache, queue, or files that need not be publicly accessible.
- Operations are monitored and restored Logs, monitoring, backups and a tested recovery procedure help identify a problem and reduce its impact.
Important considerations
The service model determines both control and responsibility.
Hosting covers a broad spectrum; the practical agreement and technical documentation must state exactly what the service includes.
Shared hosting
Multiple customers share a managed environment. It suits simpler websites, but the available PHP versions, processes, networking options and extensions are often limited.
VPS and dedicated server
A virtual or physical server offers more control over the software. The team, however, usually takes responsibility for operating system updates, security, monitoring and recovery.
Cloud and managed platform
Services can provide scaling, databases or deployment as part of the platform. This does not mean the provider automatically understands the business logic or the integrity of application data.
Backups and recovery
A backup is a copy of data at a particular time. It has value only when its retention and protection are known and the recovery procedure has been tested.
Monitoring and limits
CPU, memory and disk use, error rates and response times reveal whether the environment matches the workload. An “unlimited” plan usually has specific fair-use limits.
Benefits and limitations
The right environment fits both the application and the team's capabilities.
Benefits
- launching a website faster without purchasing hardware
- choosing the degree of management from a shared service to custom infrastructure
- access to operational services such as TLS, monitoring or backups depending on the offering
- separating public operations from developer computers
Risks and common mistakes
- assuming that hosting includes a domain, email, application updates and data recovery
- selecting a service without support for the required PHP runtime, database or workers
- treating provider backups as a tested recovery plan
- exposing a database or administration port directly to the internet without a clear reason
- failing to document access, DNS, account ownership and the deployment process
When each model makes sense
Use the simplest operational model that meets the real requirements.
For a website with mostly static content, the priorities are often reliable file delivery, DNS, HTTPS and a simple update process. For a PHP application, the available runtime version, database connection, request size and duration, scheduled tasks, upload security and access to error information all need to be verified.
If an application requires multiple services, an internal network, Redis, PostgreSQL or separate workers, an environment with clearly defined isolation and management is usually more appropriate. High availability, geographic redundancy or automatic scaling are valuable only when they match the value of the service and the team can manage data, deployments and incidents in that model.
What to consider
The operational agreement should be specific and verifiable.
Hosting is part of the technical design, not merely a line on an invoice.
- verify supported runtimes, databases, process limits, upload sizes and scheduled task options
- separate production, test and development access and do not use shared passwords
- keep databases, Redis and internal administration interfaces off the public internet unless they have clearly defined protection
- document deployment, DNS, account owners, backups and the recovery procedure
- monitor errors, capacity and availability instead of assuming that a hosting plan eliminates operational risk by itself
Common questions
Web hosting in practice
Is web hosting the same as a domain?
No. A domain is a name registered through a registrar, while hosting provides the website environment. They can be purchased together but managed separately.
Does web hosting always include email?
Not necessarily. Some providers offer it, while others expect a separate email service. The limits, account management and backups need to be checked.
Are provider backups sufficient?
It depends on retention, the scope of the data, recovery speed and the contractual terms. The recovery process must be tested in practice, and responsibility for performing it must be clear.
Is a VPS automatically better than shared hosting?
No. It offers more control but also more responsibility. Managed shared hosting can be more suitable for a simple website if it meets the technical requirements.
How I run applications in practice
I select infrastructure according to application behaviour and team responsibility.
For PHP applications, I connect the runtime, databases, integrations and operational monitoring so that deployments and further development remain predictable.