How are web apps hosted? A practical guide to web application hosting (2026 Guide)

A web app is hosted by running its code on a server that someone else owns and maintains, then pointing your domain name at that server so a browser can reach it. In practice that means three separate things need a home: the front end that runs in the browser, the back end that handles logic and authentication, and the database that stores your data. Most modern web applications split those across a content delivery network, a managed compute service and a managed database, rather than putting everything on one machine.

That split is the part people miss. If you are picturing hosting as “buy a server, upload the files”, you are picturing 2010, and you will struggle to compare quotes sensibly.

What web application hosting actually involves

A server is a computer that listens for requests and returns responses. When someone opens your app, their browser asks a server for the page, the server runs whatever code is needed, fetches data and sends back a result. The user installs nothing. That is the main difference between a web application and packaged software: you are renting the machine doing the work.

Hosted applications also need supporting services that are easy to forget when budgeting:

• DNS, so your domain resolves to the right place
• TLS certificates, so traffic is encrypted (usually free and automatic now)
• A database, almost always hosted separately from the application code
• File and object storage, for uploads, images and documents
• Backups and monitoring, not optional once you have real users

None are expensive individually. Together they explain why a hosting bill is rarely a single line item.

The main hosting options compared

Option	Best suited to	Roughly what you manage	How you are billed
Shared hosting	Brochure sites, small PHP apps	Almost nothing	Flat monthly fee, the cheapest tier available
VPS	Predictable traffic, cost control	The whole operating system	Fixed monthly fee per server size
Managed platform (PaaS)	Most business web apps	Your code only	Per instance, rising as you scale out
Containers (Kubernetes)	Multiple services, larger teams	Cluster configuration	Cluster fee plus every node, so the highest baseline
Serverless	Spiky or event-driven workloads	Individual functions	Per request and execution time, near zero when idle

Every provider publishes current prices and a calculator. Check those rather than any figure quoted in an article, because prices change and vary by region.

Shared hosting

Multiple customers share one physical machine. It is cheap and fine for a website, but a poor fit for a web application: limited control over the runtime, background jobs usually blocked, and a noisy neighbour on the same box can slow you down. We would rarely recommend it for anything with logins and a database.

VPS (virtual private server)

A VPS gives you a slice of a physical machine with your own operating system, disk and bandwidth. You get real control and predictable pricing, which matters if traffic is steady and your finance team dislikes variable bills. The trade-off is that you, or someone you pay, is now responsible for security patches, server configuration, log rotation and backups. That is an ongoing job, not a one-off setup task.

Managed platforms

Platform services such as Azure App Service, AWS App Runner, Google Cloud Run, Vercel or Render sit between a VPS and full serverless. You push code, the platform builds and runs it, handles TLS, and scales instances up and down. For most business web applications, this is the sensible default: you give up some low-level control in exchange for not employing anyone to babysit servers.

Containers and Kubernetes

Containers package your app with everything it needs to run, so it behaves the same on a laptop and in production. Kubernetes then orchestrates lots of those containers across machines. It earns its keep once you have several services, several teams and real scale, and before that point it mostly adds operational overhead. If a supplier proposes Kubernetes for a single application with a few hundred users, ask them to justify it.

Serverless hosting

With serverless, you deploy functions rather than servers. The provider allocates compute when a request arrives and charges for what you actually consume, measured in requests and execution time. AWS Lambda, Azure Functions and Cloudflare Workers all work this way.

The appeal is that idle costs approach zero and traffic spikes are absorbed automatically. The honest limitations are cold starts on infrequently used functions, execution time limits that make long-running jobs awkward, and database connection pooling that fits the model badly. It suits event-driven work, scheduled tasks and APIs with uneven traffic, far less so heavy data processing.

AWS, Azure or Google Cloud

Most hosted applications end up on one of the three large providers. They are more alike than the marketing suggests, and the deciding factor is usually your team and your existing contracts rather than technical superiority.

• AWS has the widest service catalogue and the largest pool of engineers who know it. It is the safe general-purpose choice, though the pricing model takes effort to understand and the console is not welcoming to newcomers.
• Azure is the pragmatic pick if your organisation already runs Microsoft 365, Entra ID and .NET. Single sign-on, identity and billing all sit in one place, which removes a category of integration work. UK data residency options are well established.
• Google Cloud is strong on containers, data tooling and Firebase for smaller applications, with a simpler pricing structure. Its catalogue is narrower than AWS.

For UK businesses handling personal data, the more useful question is which region your data sits in and what your processing agreement says, not which logo is on the invoice. All three offer UK regions. If you are in a regulated sector, confirm this in writing before you build.

How we usually structure hosting

There is no single correct architecture, but a pattern we return to for web application development projects looks like this:

1. Front end on a CDN. Static assets are served from edge locations close to the user, which is the cheapest performance improvement available.
2. Back end on a managed platform. Containers running on a service that handles scaling, with a staging environment alongside production.
3. Database as a managed service. Automated backups, point-in-time recovery and patching handled by the provider. Running your own database server is a job nobody thanks you for.
4. Object storage for files. Uploads never live on the application server, because application servers are disposable.
5. Deployment through a pipeline. Every change is built, tested and released the same way, so releases are boring.

That structure is neither exotic nor expensive. It is a set of decisions that stop you painting yourself into a corner once the app starts to matter, and it overlaps with how you build the app securely, because network boundaries, secrets management and access control are hosting decisions as much as code decisions.

What hosting costs in practice

We will not quote a monthly figure here, because an honest one does not exist without knowing your workload. The bill is driven by a short list: how much compute runs continuously, the size and tier of your database, how much data you store and how much leaves the provider’s network, whether you keep a staging environment running, and how strict your availability and backup requirements are. Heavy media, large datasets and multi-region redundancy move the number most. Price your own case on the provider’s calculator, including the lines people forget: backups, logging and monitoring.

The bigger number is the build, not the running cost. Our published ranges are £10,000 to £50,000 for a simple application, £50,000 to £150,000 for a mid-range one, and £150,000 to £1,000,000 or more for something complex. Hosting is a rounding error against that, which is why choosing infrastructure purely on price is a false economy. You can sanity-check your figures with our cost estimator.

One cost worth naming: someone has to maintain it. Patching, certificate renewals, dependency upgrades and responding when something breaks at 7am. Whether that is your team, ours or a managed service, budget for it.

Frequently Asked Questions

How are web apps hosted?

A web app is hosted by deploying its code to a server, or a managed service that runs servers on your behalf, and pointing your domain at it through DNS. The front end is usually served from a content delivery network, the back end runs on a cloud compute service, and the database is a separate managed service. Users reach all of it through a browser, with nothing installed on their own machine.

What is the difference between web hosting and web application hosting?

Web hosting typically serves fixed files: pages, images and stylesheets that are the same for everyone. Web application hosting also runs code on demand, connects to a database, handles user sessions and processes requests that differ per user. That means it needs more compute, a database, background job processing and stricter security controls, which is why application hosting costs more and requires more active management than a standard website.

How much does it cost to host a web application in the UK?

There is no single answer, because the bill follows the workload. What matters is how much compute runs continuously, the size of your managed database, how much you store and transfer, and whether you need redundancy and strict uptime. A small internal tool costs a fraction of an application serving video to thousands of users. Price your own case on the provider’s calculator, and remember that maintenance time is a separate cost, often larger than the infrastructure itself.

Is serverless hosting cheaper than a server?

Serverless is usually cheaper for uneven or low traffic, because you pay only for the requests you actually serve and idle costs are close to zero. It becomes more expensive than a fixed server once traffic is high and constant, since you are paying per invocation rather than for a fixed monthly instance you are already paying for. Steady, predictable workloads are generally cheaper on a managed platform or a virtual private server.

Can I move my web app to a different host later?

Yes, though the effort depends on how tightly the application is tied to provider-specific services. An app built with containers and a standard database can usually be moved in days. One built heavily around a single provider’s proprietary functions, queues and authentication takes considerably longer. If avoiding lock-in matters to you, say so at the design stage rather than after the build.

Who is responsible for hosting after the project is finished?

That depends on the arrangement, and it should be written down. Clients own 100% of the code, and we will normally deploy into infrastructure accounts you control, so the running application stays in your hands rather than ours. Some clients then run it in house, others keep us on for maintenance and monitoring. What matters is that one named party is accountable for patching, backups and incident response before the app goes live.

Where to go next

Hosting rarely sits on its own. It follows from your architecture, your data and how you expect the application to grow, which is why we settle it during design rather than at deployment. If you want a second opinion on an existing setup, our technical consulting work often starts exactly there. You can read more about how we work, or get in touch and we will talk it through against your actual requirements.