Maintenance Drupal

Drupal hosting requirements — US, EU and Baltic provider shortlist

🎧 Listen to every article back to back

A Drupal site may run on cheap shared hosting, but maintenance, upgrades and security updates quickly show whether the environment is actually suitable. Start with the technical requirements, then choose the provider by region and risk level.

Drupal runs in many server environments, but not all environments work equally well. A simple site may run on minimal hosting, but as the platform grows — more modules, integrations, content, editors and traffic — limitations from the wrong hosting start to show.

The short version: for a maintained Drupal 10 or Drupal 11 site, hosting should provide a supported PHP version, enough memory for Composer, SSH access, reliable backups, cron, logs and a clear path for upgrades.

If any of these are missing, the first serious update becomes slower and riskier than it needs to be.

Start with project type, not a provider name

The best hosting provider depends on the client and the job.

For a US client with a public-sector, university or enterprise Drupal platform, it usually makes sense to start with North American Drupal-focused platforms such as Pantheon, Acquia Cloud Platform or a cloud setup managed by a team that understands Drupal.

For an EU client, data residency, GDPR processes, support hours and regional infrastructure matter more. Upsun, amazee.io and the EU regions offered by Acquia or Pantheon are natural candidates to assess.

For Baltic or Estonian clients, local support can be valuable. Zone.ee and Veebimajutus.ee are practical options for smaller and mid-sized Drupal sites when SSH, Composer, PHP version control and backups are included in the chosen package. WaveCom belongs on the shortlist when the project needs stronger local infrastructure: VPS, VMware Cloud, dedicated servers, server housing or an Estonian data centre provider behind the service.

For a cost-sensitive project, managed cloud hosting such as Cloudways can be reasonable if the team accepts that it is not a Drupal-specific enterprise platform. For a high-risk platform, low price and flexibility do not by themselves make the environment safe to maintain.

Shared hosting, VPS or dedicated server?

Use the hosting level to match the operational risk.

Shared hosting can work for a small Drupal site when SSH, Composer, cron, backups and current PHP are included. It is usually the cheapest sensible option, but resource limits and support boundaries must be clear.

VPS or cloud server is a better fit when the site has more traffic, heavier cron jobs, integrations, custom code, Redis/Solr needs or stricter deployment control. The trade-off is responsibility: someone must manage operating system updates, firewall, monitoring, backups and incident response.

Managed VPS / managed cloud is often the pragmatic middle ground. The client gets more control and resources than shared hosting, but the hosting partner or technical team handles more of the server maintenance.

Dedicated server or server housing / colocation makes sense when the platform has strict performance, compliance, data-location or isolation requirements. This is rarely the first choice for a small Drupal site, but it can be right for business-critical systems.

Keep the shortlist honest

Commercial arrangements can be useful, but they should not decide the shortlist.

The order is:

  1. Does the hosting fit the Drupal requirements?
  2. Does the region fit the client?
  3. Does the provider fit the risk level?
  4. Only then: is there a commercial arrangement that can be used transparently?

If WebPro later uses partner links, discount codes or referral tracking on a hosting recommendation page, they should be marked clearly. The technical recommendation should still be based on fit, not commission.

PHP version

Drupal 11 requires at least PHP 8.3. Current Drupal 10 minor releases support PHP 8.1-8.4, but the exact combination must be checked against the official PHP requirements because support changes between minor releases.

Check which PHP version the hosting provider offers and whether it can be changed when needed. Some cheaper packages stay on older PHP versions, which means Drupal cannot be updated in the future without switching hosting providers.

Minimum requirement: PHP 8.3 for Drupal 11.

Also check whether command-line PHP and web-server PHP use the same version. Composer may run through CLI while the public site runs through Apache or PHP-FPM. If those versions differ, updates can pass in one place and fail in another. We cover this in more detail in PHP version and Drupal hosting.

Memory limits

Drupal itself does not always need huge memory, but Composer updates do.

ScenarioRecommended memory_limit
Simple informational site256 MB
Medium-complexity site512 MB
Complex platform, many modules512 MB - 1 GB

Running Composer updates often requires 512 MB or more. If the memory limit is too low, the update process can fail before Drupal itself is even tested.

Composer and SSH access

Modern Drupal projects use Composer to manage modules and dependencies. A reliable Composer workflow needs:

  • SSH access — Composer runs from the command line, not through a web browser.
  • Composer installed on the server — or the ability to install it safely.
  • Enough memory for Composer — otherwise updates fail during dependency resolution.

Without SSH or an equivalent deployment workflow, Drupal security updates are harder to manage reliably. Uploading files manually via FTP is a poor workflow for a maintained Drupal site.

Database

Drupal supports MySQL, MariaDB and PostgreSQL. Most hosting providers offer MySQL or MariaDB, which works well.

Check the database version before moving to Drupal 11. A provider may advertise current PHP while still running an older database layer that blocks future upgrades.

Filesystem and private files

Drupal writes uploaded images, generated styles, cache files and private files. The server must allow Drupal to write where it needs to write, while keeping private files outside public web access.

On basic shared hosting this can be restricted. It is worth checking before installation or migration.

Cron jobs and queues

Drupal needs regular background tasks: cache clearing, search indexing, queues, scheduled publishing and email sending.

Poorman's Cron can work for a small site, but server-level cron is more predictable. Larger sites should not depend on page visits to run maintenance tasks.

Backups and restore

A backup is useful only if it can be restored quickly.

Before choosing hosting, ask:

  • how often file and database backups are created;
  • how long backups are retained;
  • whether a single database or file directory can be restored;
  • whether restore can be tested before an urgent incident.

This matters during Drupal maintenance, PHP version changes and Drupal upgrades.

Provider shortlist by offer type

Use this as a starting point, not as a fixed ranking. Every provider still needs a project-specific check: PHP version, Composer, SSH, backups, cron, logs, staging and support response.

Enterprise Drupal PaaS / WebOps: Pantheon and Acquia Cloud Platform are natural first checks for serious Drupal projects in North America and international enterprise work. They are Drupal-focused, support team workflows and fit organisations that want a managed platform instead of custom server ownership.

EU-focused PaaS and open-source platform hosting: Upsun and amazee.io are stronger candidates when data location, infrastructure-as-code workflows, European support hours and open-source hosting architecture matter.

Estonian shared hosting and business hosting: Zone.ee, Veebimajutus.ee, Virtuaal.com and Radicenter are worth checking for smaller and mid-sized Drupal sites. The decisive details are not the headline price, but SSH, Composer, PHP version control, cron, backups and restore terms.

Estonian VPS, cloud, dedicated and data centre infrastructure: WaveCom, Zone.ee CloudServer VPS, Core Hosting, EstNOC and Estoxy are more relevant when the project needs VPS, cloud server, dedicated server, high-bandwidth hosting, server housing or local data-centre-backed infrastructure. For Drupal, this usually means WebPro or another technical team must own more of the operating model.

Budget-managed cloud: Cloudways can be useful for smaller PHP/Drupal projects where the client wants managed cloud basics without an enterprise Drupal platform. Check backup, staging, Redis, cron and support limits before recommending it.

DIY cloud and VPS: DigitalOcean Droplets, AWS Lightsail, Google Cloud, Microsoft Azure and Hetzner Cloud can all run Drupal well, but then your team owns more of the operating model: security updates, backups, monitoring, deployment and incident response.

Dedicated / colocation for special cases: WaveCom, Telia equipment hosting, Estoxy dedicated servers and HostSlim Tallinn are not the first answer for a normal Drupal website, but they can matter for data-location, high-bandwidth, isolation or colocation requirements.

Summary — what to ask your hosting provider

Before signing a contract, ask:

  1. Which PHP version is available and can it be changed?
  2. Do CLI PHP and web-server PHP match?
  3. What is the default memory_limit and can it be adjusted?
  4. Is SSH access included in the package?
  5. Is Composer available on the server?
  6. Which database version is in use?
  7. Can cron jobs be configured?
  8. How are backups restored?
  9. Can logs be accessed without support tickets?
  10. Is staging included or easy to create?

If all of these have clear answers, the hosting may be suitable for Drupal. If the answers are vague, check the environment before committing. WebPro can review the fit as part of a technical audit or Drupal maintenance onboarding.

Subscribe via RSS
Kaido Toomingas, WebPro technical leadWebPro Company OÜ Technical lead: Kaido Toomingas

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us