TOP 7 Drupal-Webhosting-Dienste im Jahr 2026

Drupal-Webhosting bezeichnet eine Serverumgebung, die speziell auf den höheren CPU-, Speicher- und Datenbankbedarf des Drupal-CMS abgestimmt ist. Anders als herkömmliches Shared Hosting, das für einfache oder statische Skripte konfiguriert ist, umfasst Drupal-Hosting vorkonfigurierte PHP-Speicherzuweisungen (in der Regel 256 MB bis 512 MB+), OPcache, Datenbankoptimierungen (etwa die Optimierung des InnoDB-Pufferpools) und serverseitige Caching-Ebenen (Varnish, Redis), die für die reibungslose Verarbeitung komplexer Node-Strukturen und dynamischer Datenbankabfragen erforderlich sind.

Drupal 11 erfordert eine Serverumgebung mit PHP 8.3 oder höher und Unterstützung für JIT-Kompilierung (Just-In-Time). Als Datenbanken werden MySQL 8.0+, MariaDB 10.6+, PostgreSQL 16+ oder SQLite 3.45+ unterstützt. Als Webserver ist Apache 2.4.7+ (mit aktiviertem mod_rewrite und mod_headers) oder Nginx 1.1+ erforderlich. Microsoft IIS wird für den Produktiveinsatz mit Drupal 11 nicht mehr unterstützt.

Der Drupal-Core stützt sich stark auf moderne PHP-Funktionen, objektorientierte Architektur und strikte Typisierung. PHP 8.3 bietet durch verbessertes OPcache und JIT-Kompilierung erhebliche Leistungsoptimierungen, die die Ausführungszeiten für umfangreiche Datenbankabfragen und komplexe Modullogik drastisch reduzieren. Die Verwendung älterer PHP-Versionen führt zu schwerwiegenden Sicherheitslücken und verhindert, dass Websitebetreiber auf neuere Drupal-Core-Versionen aktualisieren können.

Varnish fungiert als HTTP-Beschleuniger in Form eines Reverse-Proxys vor dem Webserver. Wenn ein anonymer Besucher eine Seite anfordert, liefert Varnish das vorgerenderte HTML direkt aus dem Speicher aus, ohne die PHP-Engine zu starten oder die SQL-Datenbank abzufragen. Dadurch sinkt die Seitenauslieferungszeit auf unter 100 Millisekunden, und der Host wird bei starken Traffic-Spitzen vor einem Ausfall geschützt.

Während Varnish vollständige HTML-Seiten für anonyme Nutzer zwischenspeichert, speichern Redis und Memcached flüchtige Datenbankobjekte, Render-Caches und Felddaten für angemeldete Nutzer im RAM. Durch das Abfangen interner Abfrageanforderungen reduziert Objekt-Caching die Datenbank-Lesevorgänge um 60 % bis 80 % und beschleunigt so die Generierung dynamischer Inhalte während angemeldeter Sitzungen.

Shared Hosting ist für kleine Drupal-Websites mit geringem Traffic oder Entwicklungsumgebungen akzeptabel. Da gemeinsam genutzte Umgebungen jedoch CPU, RAM und PHP-Worker auf Hunderte benachbarter Websites verteilen, führen dynamische Drupal-Vorgänge (etwa das Ausführen von Cron-Jobs, Datenbankaktualisierungen oder das Rendern komplexer Ansichten) häufig zu Fehlern wegen erschöpften Arbeitsspeichers oder vorübergehenden Ratenbegrenzungen. Für Produktionsanwendungen werden Managed-Cloud-, VPS- oder PaaS-Umgebungen dringend empfohlen.

Verwaltete Platform-as-a-Service-(PaaS-)Lösungen – wie Acquia oder Pantheon – automatisieren die Serverbereitstellung, Betriebssystem-Patches, SSL-Verlängerungen, Sicherheits-Firewalls und die speziell auf Drupal abgestimmte Stack-Optimierung. Ein nicht verwalteter Virtual Private Server (VPS) bietet vollständigen Root-Zugriff, zwingt den Website-Inhaber jedoch dazu, Linux-Pakete manuell zu warten, Webserver zu konfigurieren, Backup-Richtlinien einzurichten und Sicherheitsvorfälle zu bewältigen.

Drupal verwendet Composer als offiziellen Abhängigkeitsmanager, um Core-Updates, Community-Module und PHP-Bibliotheken von Drittanbietern zu installieren. Composer 2.x reduziert den Speicherverbrauch und die Ausführungszeit bei der Paketinstallation im Vergleich zu älteren Versionen erheblich. Ein Hostingserver muss die CLI-Ausführung von Composer 2.7+ unterstützen, um Continuous Integration und eine reibungslose Website-Wartung zu ermöglichen.

Drush ist die Befehlszeilen-Shell und Skriptschnittstelle für Drupal. Mit SSH-Zugriff und vorinstalliertem Drush (Version 13+) können Entwickler Datenbankaktualisierungen ausführen (drush updatedb), Caches leeren (drush cr), Konfigurationen exportieren (drush cex) und Benutzerkonten direkt innerhalb von Sekunden verwalten, ohne die Webbrowser-Oberfläche zu öffnen.

Eine containerisierte „Dev, Test, Live“-Architektur stellt isolierte Umgebungen für Entwicklung, Qualitätssicherung und Produktion bereit. Entwickler übertragen Codeänderungen von Dev nach Test, synchronisieren Datenbankinhalte aus der Produktion in umgekehrter Richtung und prüfen Aktualisierungen sicher, bevor sie veröffentlicht werden. So lassen sich fehlerhafte Builds oder Ausfallzeiten unter der Live-URL verhindern.

Ja, sofern der Webserver das Verknüpfen von Verzeichnissen und die Bindung benutzerdefinierter Domain-Aliase zulässt. Da sich jedoch alle Unterseiten in einer herkömmlichen Multisite-Installation ein einziges settings.php-Ökosystem, ein Code-Repository und eine Datenbankbenutzerinstanz teilen, können eine hohe Auslastung oder ein schwerwiegender Fehler auf einer Website alle anderen beeinträchtigen. Spezialisierte Enterprise-PaaS-Lösungen verwenden eine containerisierte Orchestrierung (wie Acquia Site Factory), um diese Websites sicher voneinander zu entkoppeln.

Nginx: Aufgrund des geringen Speicherverbrauchs und der asynchronen Ereignisverarbeitung besonders für Unternehmensumgebungen mit hoher Parallelität geeignet.

LiteSpeed: Hervorragend für Shared-Hosting- und VPS-Umgebungen geeignet; bietet integriertes serverseitiges Caching (LSWS) und ist als direkter Ersatz mit Apache-.htaccess-Direktiven kompatibel.

Apache: Sehr zuverlässig und von Haus aus mit den .htaccess-Rewrite-Regeln von Drupal kompatibel, daher ideal für Standardbereitstellungen.

Ein einfacher Produktionsserver benötigt mindestens 1 GB bis 2 GB Gesamtsystem-RAM. In PHP sollte die Direktive memory_limit auf mindestens 256 MB für einfache Websites und auf 512 MB bis 1 GB für Websites gesetzt werden, die umfangreiche Module (wie Webform, Commerce oder Media) ausführen, Composer-Updates durchführen oder große Bildtransformationen verarbeiten.

Drupal 11 erfordert MySQL 8.0+, MariaDB 10.6+ oder PostgreSQL 16+. Bei MySQL/MariaDB müssen Datenbank-Engines die InnoDB-Speicher-Engine verwenden, um bei hohem Schreibaufkommen Sperren auf Zeilenebene zu gewährleisten. Die Isolationsstufe für Datenbanktransaktionen sollte auf READ COMMITTED eingestellt sein, um Deadlocks bei automatisierten Hintergrundaufgaben zu vermeiden.

Eine auf Drupal abgestimmte WAF prüft eingehenden HTTP-Datenverkehr, bevor er die Anwendungsschicht erreicht. Sie blockiert automatisierte SQL-Injections, Cross-Site-Scripting (XSS), schädlichen Bot-Datenverkehr und Brute-Force-Anmeldeversuche. Spezielle Regelsätze mindern außerdem aufkommende Drupal-Core-Sicherheitshinweise (DSAs) am Edge, bevor Patches manuell auf die Codebasis angewendet werden.

Drupal führt bei jeder Seitenanfrage Dutzende Dateizugriffe aus, um Core-Bibliotheken, aktive Themes, Twig-Vorlagen und Modul-Code-Dateien zu laden. NVMe-Speicher (Non-Volatile Memory Express) bietet Lese- und Schreibdurchsatzraten, die bis zu 4- bis 6-mal höher sind als bei herkömmlichen SATA-SSDs. Das führt zu deutlich kürzeren I/O-Wartezeiten und schnelleren Antworten auf Datenbankabfragen.

Ein Content Delivery Network (CDN) – wie Cloudflare oder Fastly – verteilt statische Assets (Bilder, kompiliertes CSS, zusammengeführtes JS) auf Hunderte globaler Edge-Standorte. In Verbindung mit dem Cache-Tags-System von Drupal invalidiert das CDN zwischengespeicherte Seiten auf globalen Edge-Knoten automatisch, sobald Inhalte im Drupal-Backend bearbeitet werden.

Acquia wurde vom Drupal-Erfinder Dries Buytaert mitgegründet und bietet eine unternehmenstaugliche Umgebung. Die auf AWS basierende Plattform bietet zonenübergreifende Hochverfügbarkeit (99.99% Uptime-SLA), FedRAMP-/HIPAA-Konformität, eine cloudnative IDE und native Erweiterungen wie Acquia Site Factory und Content Hub für die Unternehmensverwaltung.

Pantheon verwendet containerisierte Linux-Umgebungen statt vollständiger virtueller Maschinen. Jede Website läuft in isolierten Containern mit dedizierten Diensten für PHP, Datenbank und Redis. Diese Infrastruktur ermöglicht sofortige Skalierung, Bereitstellungen ohne Ausfallzeiten und die automatisierte Bereitstellung von Umgebungen.

SiteGround bietet leistungsstarkes Hosting auf Basis der Google Cloud-Infrastruktur. Der Anbieter stellt eine benutzerdefinierte PHP-FPM-Ausführung, Nginx-basiertes Caching statischer und dynamischer Inhalte, kostenloses automatisiertes SSL und Drush-Integration bereit und ist damit eine zuverlässige Option für kleine und mittelständische Unternehmen, die eine verlässliche Performance ohne Enterprise-Preise benötigen.

Die Turbo-Tarife von A2 Hosting verwenden LiteSpeed-Webserver anstelle herkömmlicher Apache-Konfigurationen. Diese Architektur verarbeitet statische und dynamische Anfragen schneller, bietet integrierte LiteSpeed-Caching-Mechanismen und bewältigt Spitzen bei gleichzeitigem Datenverkehr mit deutlich geringerem CPU-Verbrauch.

InMotion Hosting bietet Managed-VPS-Hosting mit vollem SSH-Zugriff, garantierten dedizierten Systemressourcen und individuellen Optionen für die Server-Stack-Konfiguration (Nginx oder Apache mit UltraStack). Diese Flexibilität eignet sich für technische Teams, die Root-Zugriff für benutzerdefinierte Module oder Integrationen von Drittanbietern benötigen.

GreenGeeks gleicht den Energieverbrauch seiner Serverinfrastruktur durch den Kauf von Zertifikaten für 300 % erneuerbare Energie über die Bonneville Environmental Foundation aus. Das Unternehmen setzt energieeffiziente LiteSpeed-Server, SSD-/NVMe-Laufwerke und HTTP/3-Unterstützung ein, um Höchstgeschwindigkeit bei gleichzeitig negativer CO₂-Bilanz zu gewährleisten.

Nein. Ab Drupal 11 wird Microsoft IIS für produktive Bereitstellungen offiziell nicht mehr unterstützt. Drupal Core ist für Unix-/Linux-Betriebssysteme mit Apache- oder Nginx-Webservern ausgelegt. Windows-Umgebungen sind ausschließlich auf die lokale Offline-Entwicklung beschränkt.

Die Nutzung von „Automated Cron“ (wobei Cron bei Seitenbesuchen durch anonyme Nutzer ausgeführt wird) beeinträchtigt die Ladezeit der Seite für diesen Besucher. Bei einer geeigneten Hosting-Konfiguration wird Automated Cron deaktiviert und es werden stattdessen systemweite Linux-crontab-Jobs (crontab -e) oder Drush-Befehle (drush cron) verwendet, die in festen Intervallen (z. B. alle 15 Minuten) im Hintergrund ausgeführt werden.

Ein zuverlässiger Hosting-Anbieter muss automatisierte tägliche (oder stündliche) Backups anbieten, die sowohl den SQL-Datenbank-Dump als auch das vollständige Verzeichnis /sites/default/files enthalten. Er sollte die Wiederherstellung zu einem bestimmten Zeitpunkt mit einem Klick, die manuelle Erstellung von Snapshots vor Code-Deployments und die externe Speicherung von Backups für die Notfallwiederherstellung unterstützen.

In einer entkoppelten Architektur dient Drupal ausschließlich als Back-End-Repository für REST/JSON:API-Inhalte, während ein Node.js-Framework (wie Next.js oder React) das Frontend rendert. Moderne Hosting-Anbieter unterstützen dies durch die Konfiguration von CORS-Headern, schnelle GraphQL-/API-Caching-Ebenen und Webhooks, die bei Inhaltsaktualisierungen den statischen Neuaufbau des Frontends auslösen.

Das Verzeichnis /sites/default/files benötigt Lese-, Schreib- und Ausführungsberechtigungen für den Webserver-Benutzer (z. B. www-data oder apache), damit dort Benutzer-Uploads, zusammengeführte CSS-/JS-Assets und generierte Bildstile gespeichert werden können. Aus Sicherheitsgründen sollten die Berechtigungen auf 755 für Verzeichnisse und 644 für Dateien beschränkt werden; rekursive 777-Berechtigungen dürfen auf einem Produktionsserver niemals verwendet werden.

Verwaltete Plattformen überwachen kontinuierlich die Drupal Security Advisories (DSAs). Wird eine kritische Sicherheitslücke im Core bekannt, wenden verwaltete Hosts (wie Acquia oder Pantheon) sofort WAF-Regeln am Edge an, um ungepatchte Websites zu schützen. Anschließend veröffentlichen sie Patches im Upstream-Repository, die Administratoren mit einem einzigen Klick in der Produktionsumgebung bereitstellen können.

Quellwebsite vorbereiten: Versetzen Sie die Live-Website in den Wartungsmodus und exportieren Sie die vollständige SQL-Datenbank (drush sql-dump).

Dateien übertragen: Kopieren Sie die vollständige Codebasis und das Asset-Verzeichnis /sites/default/files per SFTP/SSH auf den neuen Host.

Datenbank konfigurieren: Importieren Sie die SQL-Datenbank auf den neuen Datenbankserver und aktualisieren Sie die Zugangsdaten für die Datenbankverbindung in /sites/default/file/settings.php.

Cache leeren und testen: Richten Sie das Host-Routing neu ein oder testen Sie über eine temporäre URL, leeren Sie alle Caches (drush cr), überprüfen Sie die Funktionsfähigkeit der URLs und ändern Sie abschließend die DNS-A/CNAME-Einträge, damit sie auf den neuen Host verweisen.