Agency Services Applied AI Projects Contact
Home Journal Choosing hosting that fits your project
Journal
Technology8 min read

Choosing hosting that fits your project

A company website, a customer portal and an application exchanging data all day need different infrastructure. Yet hosting is often decided before anyone has looked closely at the requirements. The existing provider gets another project, or the agency uses its usual setup. We start with the application and the people who will look after it.

Author: Rudolf BohrerUpdated:

For smaller projects, we work with providers such as World4You and Host Europe. For medium-sized websites, we use mittwald and mStudio. Hetzner Cloud is a frequent choice for our web applications. We also build on AWS, work with Kubernetes and deploy into our clients’ own data centres. Cloudflare handles specialised web services. Each has earned a place through different project requirements. A larger budget does not automatically call for a more elaborate setup.

Start with the application’s day-to-day needs

A website with service pages, a blog and a contact form will usually work well on a conventional web hosting plan. An application that processes documents, exchanges data with an ERP system and runs background jobs needs different capabilities. The number of pages tells you very little about that.

We look at the software, the services it relies on and the systems it connects to. Then we look at who will run it. Is there an internal IT team? Who can deploy a new version? How long can the application be unavailable before the disruption becomes expensive?

Existing infrastructure matters too. If a company already has a managed cloud environment or its own data centre, using it may make more sense than opening another account elsewhere. Every additional provider brings contracts, credentials and people who need to coordinate.

Compare hosting providers and operating models

Choose two options to compare side by side, or show all seven. On a phone, the table displays your two selected options.

This comparison covers the specific services discussed here, not every product each provider sells. For AWS, we use its EKS Kubernetes service as an example. For Cloudflare, we look at Workers. On-premises means running the application in the client’s own data centre. Our assessment of operational effort comes from project experience, not a performance benchmark. Features and responsibilities depend on the plan and the support agreement.

Capabilities and implementation · reviewed 19 October 2026
CriterionWorld4You Web HostingHost Europe Web Hostingmittwald mStudioHetzner CloudAWS with EKSOn-premisesCloudflare Workers
Typical useSmaller websites whose CMS works within a standard web hosting environment.Smaller websites built on a conventional PHP application and database.Website projects with several contributors and central project management.Web applications that need a custom-configured server environment.Several container services, or applications joining an existing AWS or Kubernetes environment.Applications integrated into the client’s infrastructure and operating procedures.Individual web services and APIs running on Workers, including alongside an existing website.
Operational work for your teamLess server administration. The application, content and their maintenance are separate responsibilities.Less server administration. The CMS, extensions and custom code still need maintenance.The provider runs the hosting platform. Your applications and containers still need maintenance.Maintain the guest OS, runtimes, applications and monitoring yourself or through an operations partner.AWS runs the control plane. Responsibility for nodes varies; applications and permissions remain with the team.Internal IT and agreed partners maintain the infrastructure and application.No server administration for Workers. Code, permissions and connected services still need attention.
Technical flexibilityPHP and databases within the plan’s limits. Not a freely configurable server environment.PHP and MariaDB within the web hosting service. Server configuration is predefined.Managed applications, with custom containers on suitable plans. Resource limits still apply.Your choice of operating system and software configuration on virtual servers.Containers and connected cloud services, within the constraints of the chosen services and cluster policies.Depends on the available hardware, virtualisation and internal IT requirements.A platform-specific runtime with execution and resource limits, not a general-purpose virtual server.
DeploymentFile transfer and, depending on the plan, SSH. Automation must work with the available access.File transfer and SSH; check the chosen plan. Set up the deployment process separately.mStudio, CLI and API. Container deployments can also be automated with mittwald’s tools.Provision servers through the API. Arrange code or container deployment separately.Container releases through Kubernetes. CI/CD, approvals and infrastructure management need setting up too.Through the access methods and release procedures approved by the client’s IT team.Deploy Worker code with Cloudflare’s tools. CI/CD integration is available.
Growth and traffic spikesCheck resources and plan limits. Upgrade the plan or change the hosting model if needed.Larger plans are available. More storage will not fix every application bottleneck.Choose suitable resources and hosting. Limits depend on the plan and application.Larger or additional servers. Load balancing and data storage need to support the change.Autoscaling can be configured. Account for databases, quotas and costs as well.Depends on spare capacity. Additional hardware may require procurement and lead time.Distributed execution across the platform. Service limits and downstream systems can still be constraints.
Backups and recoveryCheck what the chosen plan backs up, how long copies are retained and how restoration works.Check the plan’s coverage. Plan to restore files and the database together.Check coverage for each service, explicitly including custom container data and additional services.Configure server and application backups, including consistent database copies.Plan backups for each data service. A managed cluster is not a backup of application data.Use the IT team’s backup arrangements and test recovery of the application.Version the code. Back up stored data through the relevant services and keep it recoverable.
Cost modelPlan price, contract term and extras. Include the regular price after any introductory offer.Plan price and additional services. Budget separately for application maintenance.The hosting service and resources chosen, plus support for your applications.Resources plus administration. Include storage, backups and networking.Cluster, compute and additional services. Budget for usage, traffic and operational work together.Hardware, licences, data centre and staff. Existing capacity is not free.Plan and usage, plus storage or other services. Account for platform limits and extra consumption.
Moving elsewhere laterFiles and databases are usually portable. Check versions, email, DNS and configuration separately.Conventional applications are usually portable. Check exports and differences in the target environment.Applications and containers can move; mStudio automation and connected services need adapting.Common runtimes make moving easier. Infrastructure, networks and data still need to be set up.Kubernetes helps with moving deployments. AWS services and data may still require substantial changes.Internal integrations, identity systems and networks can make moving outside the company difficult.Depends on the use of Workers-specific APIs and data services. Not a drop-in move to a conventional server.
Sources by system · official documentation
World4You Web Hosting
Host Europe Web Hosting
mittwald mStudio
Hetzner Cloud
AWS with EKS
On-premises
Cloudflare Workers

World4You and Host Europe for smaller websites

For many smaller websites, a web hosting plan is a sensible choice. The provider runs the web server, PHP environment and databases. Most businesses do not want to take on that work just to operate a website.

Before choosing a plan, we check support for the required CMS version, available resources and how updates can be deployed. SSH access, scheduled tasks and a separate test environment often matter more than another increase in storage.

The limits become apparent when an application needs a different runtime, a long-running process or a particular server configuration. At that point, we compare other options instead of reshaping the application to fit the wrong plan. Equally, a website that works well does not need to move just because a more sophisticated hosting service exists.

mittwald and Hetzner put different demands on the team

For medium-sized website projects, we work with mittwald and its mStudio management interface. It brings projects, access and resources together. A CLI and API allow us to automate tasks, and suitable plans support containers. That is useful when several people work on a project and the CMS needs additional services alongside it.

We use Hetzner Cloud for web applications where we configure the server environment ourselves. Virtual servers can run the operating system, runtimes and services the application needs. Someone then has to maintain that setup, apply updates and monitor it. Creating the server is only the beginning of that responsibility.

The monthly hosting bill is therefore only part of the comparison. A more managed environment can cost less overall than an inexpensive virtual machine that requires regular administration from an external team. If the client’s IT department already handles that work, the calculation changes.

When AWS and Kubernetes earn their place

AWS is an option when an application needs several cloud services or has to fit into an existing AWS environment. Databases, storage and other services can be connected to the application there. We choose them around the project and the team that will operate it.

Kubernetes manages containerised applications across machines and handles the rollout of new versions. It is not an AWS product: it also runs in other clouds and in private data centres. On AWS, EKS provides a managed Kubernetes service. AWS operates the control plane; responsibility for the rest varies with the operating model. The application, its permissions and its configuration still need an accountable team.

For a single website, this setup will usually create more work than it saves. It becomes more useful when several services need to run together, or when the company already has an established Kubernetes platform. Our article on moving TYPO3 to the cloud covers how we prepare for that kind of project.

On-premises: working within the client’s infrastructure

Some of our applications run directly in our clients’ data centres. That can be a good fit when important business systems are already there, internal access rules apply or an experienced IT team manages the environment.

We adapt the application to the existing networks, access controls and operating procedures. That includes the route a new version takes from development into production and the approvals it needs along the way. Working with internal IT starts before implementation, not on launch day.

Having servers already does not make this option free. Capacity, maintenance, replacement hardware and staff time all belong in the budget. An in-house server also needs protected backups and a tested recovery process. Its location alone tells you little about how well data and access are secured.

Cloudflare for specialised web services

Not every extra feature needs its own server. Cloudflare can run small API services through Workers or deliver content through a CDN. We use it for specialised web services, including alongside a website hosted elsewhere.

That split can be practical: the CMS stays with its current provider while an individual function runs separately. The function must suit the runtime, though. Workers are not freely configurable virtual servers. Execution limits, supported APIs and connected data services need to be considered during development.

A small service still needs someone to look after it. We agree who has access, what data it processes, how it is monitored and what happens if it fails. Each additional service becomes another part of the application to consider when making changes.

What managed hosting actually covers

The label does not tell you who will update an ageing CMS or fix a broken extension. A provider may maintain the server and runtime while application maintenance requires a separate agreement.

Before launch, we agree who handles which updates, who receives alerts and who responds to an incident. For backups, we want to know which data is covered, how far back the copies go and how restoration works. An application with frequent changes needs a different backup schedule from a website that is rarely edited.

Privacy requirements also apply to the whole setup. Storage, email, analytics and support services often sit alongside the main hosting. With the relevant people at the client, we establish where data goes and which contractual requirements apply. Our article on web security and shared responsibilities explains how we approach that work.

Budget for ongoing work and a possible move

A useful cost comparison includes setup and ongoing support. With cloud services, the bill may also include compute, storage, traffic, backups and other services, depending on usage.

We also consider what a future move would involve. An application built on widely used runtimes and a conventional database is generally easier to relocate than one tightly connected to a platform’s proprietary services. Those services may still be the right choice. Their benefits and the potential cost of replacing them both belong in the decision.

Our clients contract directly with hosting providers. We do not run our own hosting infrastructure for clients or earn referral commissions. We help with selection, setup and agreeing how the service will be operated. Accounts, data and access remain under the client’s control, including if they later change agencies.

If you are planning a website or are unhappy with its current hosting, we can review the application and its operation with you. The answer might be a different provider, a change to the configuration or keeping what already works. Tell us about your project.

How we can help

Keep reading

Privacy Legal notice
Privacy Legal notice