--- title: "Drupal hosting 2026: Criteria and costs" lang: en type: blog canonical: https://www.arocom.de/en/blog/drupal-hosting-2026 alternate: https://www.arocom.de/blog/drupal-hosting-entscheidung author: "Axel Roth" published: 2026-08-08 last_updated: 2026-10-31 --- # Drupal hosting 2026: Criteria and costs The hosting decision for a Drupal website is a business decision about costs, responsibility, and where data lives, not a purely technical question. This guide explains the difference between managed and self-hosted, frames the legal situation around the EU data location, shows the full cost model beyond the monthly price, and provides a checklist for the choice. The core point: the lowest list price is rarely the cheapest solution, because maintenance, security, and your own staff are the real cost drivers. ## Hosting decision 2026: Criteria, costs, sovereignty The question of where a website runs sounds like a matter for IT. In practice it is a business decision. It determines who is liable at three in the morning when something breaks, how quickly a security hole gets closed, in which country the customer data lives, and how much internal staff the whole thing ties up. Whoever looks only at the monthly price regularly buys the most expensive mistake. This guide frames the hosting decision for Drupal websites from a decision-maker's point of view. It clarifies the options, the legal situation around the data location, and the full cost picture, and it ends with a checklist you can take into your next sales conversation. ## Managed or self-hosted: the real question 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. | Model | Who operates it | Fits | | --- | --- | --- | | Self-hosted (your own server) | Your team, from operating system to Drupal update | Organisations with available in-house IT operations and special requirements | | Managed hosting (Drupal-specific) | Provider handles server, updates, and monitoring; you maintain content | Most mid-sized companies without their own operations team | | Platform/PaaS (e.g. specialised Drupal platforms) | Provider supplies a standardised environment with a deployment workflow | Organisations with their own developers who want standardisation without running servers | 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 available in-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](https://www.arocom.de/en/knowledge/drupal/choosing-hosting). ## Sovereignty: data location and dependencies 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](https://www.arocom.de/en/blog/make-or-buy-ai). ## The honest cost model beyond the monthly price 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. ## What matters especially with Drupal 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](https://www.arocom.de/en/knowledge/drupal/drupal-11). The hosting choice helps decide whether this change runs smoothly. ## Checklist for the selection conversation 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. ### Is self-hosted cheaper than managed hosting? On paper often yes, in the full calculation rarely. The pure server price is lower, but the maintenance and staff hours for updates, security, and incidents come on top and appear in no offer. Once you count in those internal hours, for most mid-sized companies without their own operations team, managed hosting is cheaper overall and, above all, more reliable. ### Is a normal web host enough for Drupal? Technically sometimes, in practice rarely well. Drupal needs a matching PHP environment, enough memory, Composer support, and ideally a cache such as Redis. A generic web space does not always provide that, and what is missing becomes your task. A Drupal-specific provider sets these points up by default, which markedly improves performance and update safety. ### Must the servers be located in Germany? Not necessarily. The GDPR does not require a location in Germany but a legally sound handling of the data. Hosting in the EU with a provider subject to EU law is the simplest safe route and spares you the laborious review of third-country safeguards. The specific case, especially with special categories of data, should be assessed by your data protection officer. ### How often should updates be applied? Security updates promptly, ideally within a few days of release, because known holes are actively exploited. Feature and module updates can be bundled on a planned rhythm, for instance monthly, always with a test in a staging environment before going live. With managed hosting this rhythm is part of the service; with self-hosted you must ensure it yourself. ## The first step 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](https://www.arocom.de/en/future-check) we look together at the costs, data location, and update capability of your website. Reach us directly via [Contact](https://www.arocom.de/en/contact).