Hosting decision 2026: Criteria, costs, sovereignty

The first fork is how much operational responsibility you want to carry yourself. Simplified, there are three models, which differ above all in who is accountable for updates, security, and availability.

The more important question is not "What does the server cost?" but "Who looks after things when something breaks, and does that person have the time and the knowledge for it?" A root directory full of updates that no one applies is not saved money but an open security hole.

In our projects, most mid-sized companies do best with Drupal-specific managed hosting. The reason is rarely the price but the responsibility: updates and security patches run reliably, without an already stretched internal IT having to squeeze them in between other tasks. Self-hosted pays off when real operational know-how is in the house and special requirements justify it. Which criteria count in detail is covered in depth by our knowledge article Drupal hosting: what to look for.

Where the data of your website and your users lives is no longer a side issue in 2026. Two levels must be separated: the legal and the strategic.

Legally: the GDPR does not flatly forbid hosting outside the EU but ties a transfer to third countries to conditions, such as an adequacy decision or appropriate safeguards. In practice that means for most mid-sized companies: hosting with servers and processing in the EU, with a provider subject to EU law, is the simplest safe route. It spares you the laborious review of third-country safeguards and the uncertainty of whether they hold up in a dispute. This is a framing, not legal advice; the specific case is assessed by your data protection officer.

Strategically it is about dependency. A provider whose data formats, deployment paths, and interfaces are open can be changed. A provider with a proprietary platform binds you through the migration costs, even if the contract is cancellable annually. Before signing, ask what an exit would look like: do you get the database, files, and configuration out in a common format, or does a project of its own begin? This make-or-buy logic applies not only to hosting; how to make such decisions cleanly in general is described in our article Make or buy for AI solutions.

The monthly price of a hosting plan is the smallest and most visible part of the total cost. Whoever compares offers only by this figure compares the wrong thing. Four cost blocks belong in the calculation:

• Operations (visible): the monthly hosting price, plus any costs for traffic, storage, and additional environments such as staging.
• Maintenance (often hidden): Drupal core and module updates, security patches, backups, and their testing. With managed hosting this is priced in; with self-hosted it becomes internal staff hours that do not show up in the server price.
• Staff (most often underestimated): your own people's time for operations and incidents. One hour of firefighting per quarter on average costs more than the price difference between most hosting offers.
• Risk (rarely quantified): the expected cost of an outage or a security breach. Whoever saves here by having no one apply updates pays a multiple of it when damage occurs.

From this follows the most common miscalculation we see: a cheap server is compared with an expensive managed offer without counting in the server's internal maintenance and staff hours. Once those hours are on the table, the picture flips in many cases. So calculate in total cost of ownership over three years, not in the monthly price.

Drupal makes its own demands on a hosting plan that a run-of-the-mill web space does not always meet. Look for a PHP environment matching your version, enough memory, Composer support for clean updates, and a cache such as Redis or Memcache for performance. A provider who knows Drupal sets this up by default; with a generic host it becomes your task.

Particularly important is the ability to update across version boundaries. Drupal evolves on a fixed rhythm, and outdated versions lose their security support. Good hosting turns the jump to a new major version into a routine rather than a major project. What a new version concretely brings and why the change is not optional is set out in our knowledge article on Drupal 11. The hosting choice helps decide whether this change runs smoothly.

These seven questions separate a solid offer from a nice price tag in the sales conversation. Ask them before you sign:

1. Where are the servers, and who is subject to which law? EU location and an EU provider are the simplest safe route. 2. Who applies Drupal updates and security patches, and in what time frame? Get the commitment in writing. 3. What do backups look like, and are they tested? A backup no one has restored is a hope, not a backup. 4. What does a version jump cost, for instance to the next Drupal major version? Routine or special project? 5. How do I get back out? Have the export of database, files, and configuration in a common format committed to you. 6. Who is reachable in an incident, and how fast? Clarify response times and availability, not just the price. 7. What total cost over three years, including your own staff time? Only this figure makes offers comparable.

If a provider answers these questions clearly and in writing, you have a partner. If the answers evade, you know your risk before it gets expensive.

Take your current hosting offer and answer the seven checklist questions as far as you can from the contract. Even this pass usually shows where you carry more risk today than you realised, and where the low monthly price gets expensive later.

If you want to set up the decision cleanly or have an existing setup reviewed, in our Future Check we look together at the costs, data location, and update capability of your website. Reach us directly via Contact.