Hosting a Web App: Managed Platforms, Servers and Serverless

Four ways to run a web app

For hosting basics such as shared hosting, VPS and domains, see our guide to web hosting explained. A web app usually runs in one of these four ways:

• Your own servers or virtual machines. You, or the team you hire, set up and run the operating system, web server, application and database. Microsoft's shared responsibility page describes this infrastructure-as-a-service model as one where "you manage virtual machines, operating systems, and applications". It gives the most control and the most work.
• Managed application platforms. You hand over your code and the platform runs it. Azure App Service runs web apps, mobile back ends and APIs in .NET, Java, Node.js, Python and PHP "without worrying about managing the underlying infrastructure". With AWS Elastic Beanstalk you upload your application and it "provisions Amazon EC2 instances or EKS clusters, configures load balancing, sets up health monitoring, and dynamically scales your environment".
• Container platforms. Google Cloud Run is "a fully managed application platform for running your code, function, or container". Any language works if it can be packaged as a container image, and for common languages Cloud Run can build the container from source for you.
• Serverless functions. AWS Lambda runs code "without provisioning or managing servers", handling "server maintenance, capacity provisioning, scaling, and patching". Lambda event functions run in response to events or API calls; AWS lists a default limit of up to 15 minutes per invocation, so long-running jobs need a different design.

An app can also mix these, for example a managed platform for the web app, a managed database service, and functions for background jobs such as sending emails or resizing images.

Who looks after what

Every cloud provider publishes a shared responsibility model, and it is worth reading before you choose. AWS's version says AWS operates everything from the host operating system and virtualization layer down to the physical facilities, while the customer is responsible for "the guest operating system (including updates and security patches), other associated application software" and firewall configuration on virtual servers. For patching, "AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications".

Microsoft's matrix shows how the split moves. On virtual machines the customer looks after the operating system; on platform services such as App Service, Microsoft does. But some things never move. "For all cloud deployment types, you own your data and identities": your data, your configuration and settings, and who has access stay your responsibility on every model. A managed platform removes server work; it does not remove the need for someone to own security settings, user accounts and data protection.

Scaling up and down

Managed platforms add and remove capacity for you, which is one of their main attractions. The Cloud Run documentation explains the trade-offs well:

• A service "can rapidly scale out to one thousand instances, or even more if you request a quota increase".
• With no traffic, "even the last remaining instance will be removed", known as scale to zero. The next request has to wait for a new instance, which "can increase the response time for these initial requests".
• You can keep a minimum number of instances running to avoid that delay, and set a maximum number "if you're concerned about costs or overloading downstream systems".

The last point matters for most business apps. The database, a payment provider or a third-party API can have limits of its own, so unlimited scaling of the web tier can simply move the bottleneck. Decide on a maximum, and check how the platform bills for idle and minimum instances in the provider's own pricing pages.

Deploying without downtime

Releasing a new version should not take the app offline. Azure App Service's deployment slots are "live apps with their own host names": you deploy to a staging slot, validate the change, warm it up, then swap it into production. Microsoft says this "eliminates downtime when you deploy your app" and that no requests are dropped during a swap. On other platforms, ask what the equivalent is; on your own servers you have to build it yourself. Whatever the platform, keep the previous version ready so you can switch back quickly.

Runtimes and upkeep

Even serverless code needs maintenance. AWS's Lambda runtime policy says it deprecates a runtime when a major component, usually the language version, reaches the end of community long-term support. After that, AWS "may no longer apply security patches or updates to that runtime", and functions using it are no longer eligible for technical support. Plan to move the app to supported language and framework versions on a schedule, just as you would on a server.

Backups and the database

Do not assume the platform's backup covers everything. Azure App Service's backup documentation shows why: automatic backups exist in the Basic tier and above, but the linked database is "Not backed up" by automatic backups. Microsoft also says that from 31 March 2028 custom backups will no longer back up linked databases, and recommends "the native backup and restore tools provided by each database service instead".

The lesson applies everywhere: list each part of the app (code, configuration, database, uploaded files) and confirm how each one is backed up, where the copies live, and how long they are kept. Then test a restore. Our guide to website backups covers what to back up and how to test it.

Choosing a region

Cloud providers run separate regions around the world. Google Cloud's geography page explains that regions are independent geographic areas made up of zones, and that you choose locations to meet your "latency, availability, and durability requirements". AWS's architecture blog on selecting a region names four factors:

• Compliance: if data is bound by local regulations or data residency laws, that "overrides other evaluation factors".
• Latency: a region close to your users gives faster responses.
• Cost: services are priced differently from one region to another.
• Services and features: new services reach regions gradually, so not every region offers everything.

Keep the app and its database in the same region, and record the choice in your privacy documentation if the app handles personal data.

How to decide

• Who will run it? If nobody on your side will patch servers, choose a managed platform or a team that manages the servers for you.
• How does traffic behave? Steady use suits always-on instances; spiky or occasional use suits platforms that scale to zero.
• What does the app need? Long-running jobs, special system software or background workers can rule some options out.
• Where must the data live? Check compliance before latency and price.
• Whose account is it? The cloud account, billing and admin access should belong to your business; see our guide to what you should own.

Write the answers into your web app project brief so the hosting is planned with the build, not after it.

Frequently asked questions

Is serverless always cheaper?

Not necessarily. Serverless services bill for what you use, which suits occasional or spiky traffic, but keeping minimum instances warm or handling steady heavy traffic changes the sums. Compare using each provider's own pricing pages for your expected usage.

Does a managed platform take care of security?

Only part of it. Under the shared responsibility models published by AWS and Microsoft, the provider looks after the physical infrastructure and, on platform services, the operating system. Your data, configuration, settings and user access always remain your responsibility.

Can we move the app to another provider later?

Usually, but the more provider-specific services an app uses, the more work a move takes. Packaging the app as a standard container and keeping the database in a common engine makes a later move easier.

Can a web app run on ordinary shared hosting?

Small apps sometimes can, but shared hosting limits the software you can install and the resources you get. Our guide to web hosting explained compares shared hosting, VPS, dedicated and cloud options.

We run the applications we build on servers we manage, with monitoring, backups and security updates handled for you; if you would rather use your own cloud account, we can talk that through during discovery. See our web app development service and all our services, or email [email protected].