Drupal-Hosting: Was Drupal Wirklich Braucht

Drupal-Hosting ist der Ursprung des größten Teils vom Ruf, Drupal sei langsam, und fast immer ist es eine Einkaufsentscheidung und kein Softwareproblem. Eine Website wird sauber gebaut und geht dann auf einem Tarif live, der für eine Broschürenseite mit einer Handvoll PHP-Dateien kalkuliert wurde. Das Ergebnis ist ein Content-Management-System mit einer ernstzunehmenden Render-Pipeline, das in einem Speicherlimit läuft, das es nicht ändern kann, auf einem Opcode-Cache, den es nicht kontrolliert, ohne Shell für die eigenen Werkzeuge.

Der Vergleich, den die meisten im Kopf haben, ist der mit WordPress, und er ist der falsche. WordPress läuft auf fast allem akzeptabel, weil sein Marktanteil die Hoster gezwungen hat, es auf fast allem akzeptabel laufen zu lassen. Drupal setzt ein aktuelles PHP voraus, eine neuere Datenbank, ein echtes Cache-Backend, eine Kommandozeile und einen Deployment-Prozess, der die Codebasis als Build-Artefakt behandelt statt als Ordner, den man bearbeitet.

Was braucht Drupal tatsächlich von einem Hosting? Eine PHP-Version auf oder über dem Minimum für Ihr Release, ein aktuelles MySQL, MariaDB oder PostgreSQL, in der Praxis 256 MB PHP-Speicher, OPcache, Shell-Zugriff für Composer und Drush, einen echten Cron-Eintrag und einen externen Objekt-Cache, sobald es angemeldete Benutzer gibt. Billiges Shared Hosting scheitert an drei oder vier davon gleichzeitig.

Was Drupal wirklich von einem Server verlangt

Die veröffentlichten Anforderungen sind kurz, konkret und öffentlich, und fast niemand liest sie vor dem Kauf. Sie sind außerdem versionsabhängig, und das zählt gerade jetzt, weil sich zwei der Untergrenzen im Dezember 2026 verschieben.

Die PHP-Version ist keine Verhandlungssache

Drupal 11 verlangt mindestens PHP 8.3 und unterstützt 8.3, 8.4 und 8.5. Drupal 10 verlangt 8.1 und unterstützt bis 8.4, und Drupal 12 hebt die Untergrenze erneut auf PHP 8.5 an. Diese Zahlen stammen aus Drupals eigener Dokumentation der PHP-Anforderungen, der einzigen Fassung dieser Liste, der man trauen sollte.

Das wiegt schwerer, als es aussieht, denn die PHP-Zweige selbst laufen aus. Die Übersicht der unterstützten Versionen auf php.net setzt das Ende des Sicherheitssupports für PHP 8.2 auf den 31. Dezember 2026, für 8.3 auf den 31. Dezember 2027 und für 8.4 auf den 31. Dezember 2028. PHP 8.1 ist bereits darüber hinaus. Ein Hoster, der mit “PHP 8.1 und 8.2 verfügbar” wirbt, bietet einen Stack an, der jetzt ungepatcht ist oder es binnen Monaten sein wird.

Die beiden Termine treffen aufeinander. Drupal 10 erreicht laut Release-Zeitplan des Cores am 9. Dezember 2026 sein Support-Ende, und Drupal 12 erscheint in derselben Woche. Kann Ihr Hoster kein PHP 8.3 oder neuer ausliefern, betreiben Sie danach kein unterstütztes Drupal mehr. Unser Leitfaden zu Kosten, Wegen und Fristen der Drupal-Migration behandelt, was das bedeutet, wenn Sie noch auf 10 sind.

Datenbank-Engines und ihre echten Untergrenzen

Drupal 11 will MariaDB 10.6 oder neuer, MySQL 8.0 oder neuer, PostgreSQL 16 oder neuer oder SQLite 3.45 oder neuer, so die Anforderungen an den Datenbankserver. Drupal 10 ist mit MariaDB 10.3.7, MySQL 5.7.8, PostgreSQL 12 und SQLite 3.26 nachsichtiger, und genau deshalb erzwingt ein Upgrade manchmal ein Datenbank-Upgrade, mit dem der Kunde nicht gerechnet hat.

Zwei Details werden gern übersprungen. InnoDB muss auf MySQL und MariaDB die Speicher-Engine sein, weil Drupal auf Transaktionen und Sperren auf Zeilenebene angewiesen ist. Auf PostgreSQL muss die Erweiterung pg_trgm vor der Installation in der Drupal-Datenbank angelegt werden, und ein verwalteter Datenbankdienst, der kein CREATE EXTENSION zulässt, ist nicht brauchbar.

SQLite wird wirklich unterstützt und ist für die lokale Entwicklung in Ordnung, aber es ist keine Antwort für den Produktivbetrieb, sobald mehrere Redakteure Inhalte speichern, denn dann wird die Schreibnebenläufigkeit zuerst zur Grenze.

Speicher, Erweiterungen und der Webserver

Drupals dokumentiertes Minimum sind 64 MB PHP-Speicher, und darunter zeigt es Warnungen. Dieselbe Seite hält fest, dass in der Produktion 128 MB oder 256 MB üblich sind und medienlastige Installationen mehr brauchen. In der Praxis sollten Sie 256 MB als Arbeitswert ansetzen und damit rechnen, ihn für die Kommandozeile anzuheben, denn speicherhungrig sind Composer und große Migrationen, nicht das Ausliefern von Seiten.

Die Liste der Erweiterungen ist unspektakulär und trotzdem eine Prüfung wert: PDO mit einem Datenbanktreiber, XML, JSON, mbstring, cURL, OpenSSL für ausgehendes HTTPS und entweder GD oder ImageMagick für Bildableitungen. Drupal 12 ergänzt Argon2 für das Passwort-Hashing, eine Sache mehr, die ein sehr alter PHP-Build nicht mitbringt.

Beim Webserver unterstützt Drupal Apache 2.4.7 oder neuer und Nginx 1.1 oder neuer und unterstützt Microsoft IIS seit Drupal 11.0.0 nicht mehr. Apache braucht mod_rewrite für saubere URLs und AllowOverride All, damit die mitgelieferte .htaccess greift. Der letzte Punkt erwischt viele: Einige Schutzregeln von Drupal existieren nur in der .htaccess, also muss ein Nginx-Deployment sie von Hand in der Serverkonfiguration nachbilden. Ein Routineschritt, der routinemäßig übersprungen wird, und eines der ersten Dinge, nach denen wir in einem Server-Sicherheitsaudit suchen.

Warum Shared Hosting an Drupal scheitert

Shared Hosting ist kein schlechtes Hosting. Es ist Hosting, das für eine andere Anwendungsform optimiert wurde, und Drupal bricht an seinen Beschränkungen an vier vorhersehbaren Stellen.

Ohne Shell kein Composer und kein Drush

Modernes Drupal ist ein Composer-Projekt. Core, Contrib-Module und deren PHP-Abhängigkeiten werden alle von Composer aufgelöst, und sobald Composer ein Modul verwaltet, muss es auch den Core verwalten. Composer mit manuellen Dateiupdates zu mischen ist der Weg zu einer Website, die sich gar nicht mehr aktualisieren lässt.

Ein Kontrollpanel mit Dateimanager kann das nicht. Ein FTP-Client auch nicht. Ohne SSH verlieren Sie außerdem Drush, mit dem Cache-Neuaufbau, Konfigurationsimporte, Datenbank-Updates und das Zurücksetzen von Passwörtern tatsächlich durchgeführt werden. Eine Website, gegen die Sie kein drush cr laufen lassen können, ist eine Website, auf der jeder Wiederherstellungsschritt zum Support-Ticket wird.

Die Grenzen, die Sie nicht sehen und erst recht nicht ändern

Ein Shared-Account gibt Ihnen ein memory_limit, das jemand anderes gesetzt hat, meist 128 MB und manchmal weniger, ohne Weg, es für die eine Migration anzuheben, die 512 MB braucht.

OPcache ist das größere Problem. Er legt vorkompilierten Skript-Bytecode im gemeinsamen Speicher ab, damit PHP Dateien nicht bei jedem Request neu parst, und auf einem Shared-Host teilen sich Hunderte Accounts diesen Speicherpool. Drupal hat Tausende PHP-Dateien, ist also ein schwerer Mieter in einem Pool, um den es konkurriert, und es fliegt heraus. Das Symptom ist eine Website, die eine Minute nach einem Besuch schnell ist und eine Stunde später wieder langsam.

Dazu kommt, was komplett fehlt: kein Redis, kein Memcached, keine Kontrolle über den PHP-Prozessmanager und keine Möglichkeit, einen langlaufenden Queue-Worker zu betreiben.

Cron, das nie wirklich läuft

Drupals Modul Automated Cron läuft standardmäßig alle drei Stunden und wird von Besuchern der Website ausgelöst. Auf einer viel besuchten Website heißt das, dass gelegentlich ein Besucher die Suchindizierung mit seiner Ladezeit bezahlt. Auf einer ruhigen Website heißt es, dass Cron faktisch nicht läuft, der Suchindex also veraltet, Logtabellen nie gekürzt und verfügbare Sicherheitsupdates nie geprüft werden.

Die Dokumentation empfiehlt stattdessen, Cron extern auszulösen, weil es dann immer planmäßig läuft und weniger Ressourcen verbraucht. Dafür braucht es einen echten Crontab-Eintrag, den die billigste Stufe nicht bietet.

Die Cache-Schichten und welche Ihr Besucher trifft

Drupal cacht mehr, als die meisten annehmen, und die Schichten sind keine Alternativen. Sie stapeln sich, und jede fängt auf, was die Schicht darüber nicht konnte.

OPcache liegt vollständig unterhalb von Drupal

OPcache ist keine Drupal-Funktion. Er cacht kompilierten PHP-Bytecode auf Interpreter-Ebene und gilt damit für jeden Request, unabhängig davon, ob irgendein Drupal-Cache trifft. Machen Sie das falsch, kann nichts darüber es ausgleichen, denn jeder Request bezahlt die Neukompilierung des Frameworks, bevor er den Router erreicht. Bemessen Sie den gemeinsamen Speicher großzügig und schalten Sie die Zeitstempelprüfung in der Produktion ab, wo sich der Dateibestand nur beim Deployment ändert.

Internal Page Cache und Dynamic Page Cache

Internal Page Cache ist ein Core-Modul, standardmäßig aktiv, und bedient ausschließlich anonyme Besucher. Es geht davon aus, dass jeder anonyme Besucher dieselbe Seite sieht, speichert die gesamte Antwort beim ersten Request und verwendet sie wieder. Auf einer Marketing-Website ohne Personalisierung erledigt diese Schicht nahezu die ganze Arbeit.

Dynamic Page Cache gehört ebenfalls zum Core und ist ebenfalls standardmäßig aktiv, und es cacht für alle, auch für angemeldete Benutzer. Es funktioniert, indem das Render-System die wirklich persönlichen Teile einer Seite in Platzhalter verwandelt und alles ringsum cacht. Deshalb kann eine Drupal-Seite im angemeldeten Zustand trotzdem weitgehend gecacht sein: Nur das Benutzermenü und ein paar Blöcke sind tatsächlich dynamisch.

BigPipe und der Render-Cache

Unter beiden liegt der Render-Cache, der einzelne Blöcke, Felder, Views-Ergebnisse und Entity-Darstellungen cacht. Eine Seite, die den Page Cache verfehlt, wird meist größtenteils aus Render-Cache-Treffern zusammengesetzt statt aus der Datenbank neu aufgebaut.

BigPipe kümmert sich um den Rest. Es ist seit Drupal 8.1 im Core, seit 8.3 stabil und seit 8.5 im Standard-Installationsprofil. Statt zu warten, bis jeder Platzhalter aufgelöst ist, gibt es die cachebare Seite sofort aus und streamt die personalisierten Fragmente danach nach. Es braucht keine Konfiguration und hilft angemeldeten Benutzern weit mehr als anonymen.

Der anonyme Besucher trifft auf einer gut konfigurierten Website also den Internal Page Cache oder das CDN davor und berührt das meiste davon nie. Der angemeldete Redakteur trifft bei jedem Request Dynamic Page Cache, Render-Cache und BigPipe, weshalb angemeldeter Traffic so viel mehr kostet.

Der externe Objekt-Cache

Jede Schicht darüber braucht einen Ort für ihre Einträge. Standardmäßig ist das die Datenbank, in Cache-Tabellen, was bedeutet, dass Ihre Cache-Lesezugriffe auf demselben Server mit Ihren Inhaltsabfragen konkurrieren.

Das Redis-Modul verlagert die Backends für Cache, Locks, Flood und Queues auf Redis oder einen kompatiblen Speicher wie Valkey, wahlweise über die PhpRedis-Erweiterung, die Relay-Erweiterung oder die reine PHP-Bibliothek Predis. Memcached ist die gleichwertige Alternative. Für eine kleine anonyme Website ändert das wenig. Für eine Website mit angemeldeten Benutzern ist es meist die größte verfügbare Verbesserung, weil es die lauteste Schreiblast von der Datenbank nimmt und Sperren billig macht.

Reverse Proxy und CDN vor Drupal

Ein Reverse Proxy wie Varnish oder Nginx oder ein CDN beantwortet Requests, bevor PHP überhaupt beteiligt ist. Für anonymen Traffic ist das der Unterschied zwischen einer Seite in einstelligen Millisekunden und einer in einigen Hundert. Es ist auch die Schicht, vor der die meisten Angst haben, weil ein veralteter Cache auf einer Nachrichtenseite oder in einem Shop ein sichtbarer Fehler ist.

Cache-Tags machen ein CDN sicher

Drupals Antwort sind Cache-Tags. Cache-Tags beschreiben Datenabhängigkeiten und werden als Zeichenketten wie node:5, user:3 oder node_list geschrieben. Jeder gecachte Eintrag hält fest, von welchen Tags er abhängt, sodass die Bearbeitung von Node 5 jedes gecachte Fragment, jede Seite und jede View entwertet, die ihn referenziert haben, wo immer er auftauchte.

Der wichtige Teil ist, dass Drupal diese Tags nach außen veröffentlichen kann. Contrib-Module geben sie als Surrogate-Key-Header für Fastly oder als Cache-Tag-Header für Cloudflare aus, und das CDN leert dann nach Tag, wenn Drupal es sagt. Das macht aus einem CDN statt einer zeitbasierten Wette einen ereignisgesteuerten Cache: Sie können eine lange Gültigkeitsdauer setzen, weil eine Bearbeitung genau die betroffenen URLs binnen Sekunden leert.

Achten Sie auf das Header-Budget. Cloudflares Dokumentation zum Leeren nach Cache-Tag begrenzt den gesamten Cache-Tag-Header nach dem Feldnamen auf 16 KB, grob 1.000 eindeutige Tags, mit maximal 1.024 Zeichen pro Tag in einem API-Aufruf und 100 Tags pro Löschung über das Dashboard. Eine Drupal-View, die viele Entities auflistet, kann weit mehr Tags erzeugen, sodass eine Seite, die alles auflistet, den Header stillschweigend überläuft, sofern das Modul nicht auf Kürzen oder Hashen konfiguriert ist.

Drupal-Hosting wählen: vier Stufen, ehrlich betrachtet

Es gibt vier echte Optionen, und die richtige entscheidet sich daran, ob Sie angemeldeten Traffic haben und ob Sie jemanden haben, der den Server betreibt. Die Bänder unten sind das, was britische Kunden nach unserer Erfahrung typischerweise zahlen, ohne Mehrwertsteuer, und sie sind Anhaltspunkte statt Angebote eines Anbieters.

Shared Hosting

Passt zu niemandem, der Drupal produktiv betreibt. Es scheitert gleichzeitig an Shell-Zugriff, Speicher, Opcode-Caching, Objekt-Caching und Cron. Wenn das Budget wirklich hier endet, ist eine kleine unverwaltete Instanz zum ähnlichen Preis die bessere Verwendung des Geldes.

Unverwalteter VPS oder Cloud-Instanz

Grob GBP 20 bis GBP 120 im Monat kaufen eine Maschine mit vollem Root-Zugriff, was zur großen Mehrheit der Drupal-Websites passt. Sie wählen die PHP-Version, dimensionieren OPcache, installieren Redis, setzen eine Crontab und konfigurieren Nginx richtig. Was Sie nicht bekommen, ist jemand, der das tut, patcht, überwacht oder um zwei Uhr nachts wiederherstellt. Diese Stufe ist richtig, wenn Sie einen Entwickler oder eine Agentur auf Retainer haben, und der Retainer ist der eigentliche Kostenblock, nicht die Instanz.

Verwaltete Drupal-Spezialplattformen

Verwaltetes Drupal-Hosting beginnt für eine kleine Website bei etwa GBP 40 im Monat und steigt mit Traffic, Umgebungen und Supportstufe schnell an. Sie kaufen einen vorgegebenen Stack, der bereits richtig ist, dazu Git-basiertes Deployment, Staging-Umgebungen, Backups und jemanden am Telefon, der Drupal versteht. Das ist sein Geld wert, wenn die Alternative niemand ist, und keines, wenn Sie Plattformpreise für eine Broschürenseite mit 4.000 Besuchen im Monat zahlen.

Vollständig eigene Infrastruktur

Getrennte Datenbank, eigene Cache-Knoten, Anwendungsserver hinter einem Load Balancer, Objektspeicher für Dateien. Das beginnt oberhalb von grob GBP 400 im Monat sinnvoll zu werden, und nur dann, wenn angemeldeter Traffic, Integrationen oder Compliance-Anforderungen die verwalteten Stufen unpassend machen. Es ist die leistungsfähigste Stufe und die anspruchsvollste, denn Patching, Monitoring und Notfallwiederherstellung gehören jetzt Ihnen. Unser Leitfaden zur Drupal-Webentwicklung behandelt, woher diese Komplexität auf Anwendungsseite kommt.

Deployment: Dateien werden nicht auf dem Server bearbeitet

Weil Composer den gesamten Abhängigkeitsbaum auflöst, ist die Codebasis auf dem Server ein Ergebnis und kein Arbeitsbereich. Eine Moduldatei an Ort und Stelle zu bearbeiten heißt, dass das nächste composer update sie überschreibt, und es heißt, dass Ihr Produktivcode nichts mehr entspricht, was in Git steht.

Ein vernünftiger Release-Prozess baut das Artefakt woanders. Führen Sie composer install aus der eingecheckten composer.lock in der CI aus, damit der Build reproduzierbar ist und der Produktionshost weder Composer noch PHP-Speicher für die Abhängigkeitsauflösung noch Schreibrechte auf vendor braucht. Liefern Sie das Ergebnis aus, führen Sie Datenbank-Updates aus, importieren Sie die Konfiguration, bauen Sie die Caches neu. Zurückrollen heißt, auf das vorherige Artefakt zu zeigen.

Damit ist die Hosting-Frage nebenbei geklärt. Ein Hoster, der erwartet, dass Sie Dateien per FTP bearbeiten, ist mit der Art unvereinbar, wie Drupal gepflegt wird, was auch immer sein Datenblatt behauptet.

Wo die Konfigurationssynchronisierung hineinpasst

Drupal hält die aktive Konfiguration in der Datenbank und exportiert sie in YAML-Dateien, und so wandern Inhaltstypen, Felder, Views und Einstellungen zwischen Umgebungen. Die Dokumentation zum Konfigurationsmanagement erklärt, dass die Site-UUID zwischen Quelle und Ziel übereinstimmen muss, was der übliche Grund ist, warum ein erster Import scheitert.

Praktisch heißt das: Konfiguration ist Code. Sie wird eingecheckt, geprüft und mit allem anderen ausgeliefert, und der Importschritt läuft als Teil des Releases, statt hinterher in der Verwaltungsoberfläche durchgeklickt zu werden. Das Hosting muss das tragen: Sie brauchen einen Ort, an dem der Import laufen kann, und eine Umgebung, in der ein gescheiterter Import zurückgerollt werden kann, statt halb angewendet in der Produktion zu stehen.

Dateien, Medien und Backups

Drupal hat zwei Dateisysteme, und der Unterschied trägt Last. Das öffentliche liegt unterhalb des Web-Roots und wird direkt vom Webserver ausgeliefert. Das private liegt außerhalb des Web-Roots, und jeder Request auf eine private Datei läuft durch Drupal, damit der Zugriff geprüft werden kann.

Private Dateien sind deshalb weit teurer als öffentliche, weil jeder Download PHP hochfährt, und eine Website, die große private Dokumente ausliefert, braucht Reserven, die ein statischer Dateiserver nicht bräuchte.

Medien in Objektspeicher auslagern

Sobald Dateien auf dem Anwendungsserver liegen, werden horizontale Skalierung und Neuaufbauten mühsam, und jedes Backup schleppt die gesamte Mediathek mit. Das öffentliche Dateisystem in S3-kompatiblen Objektspeicher zu verlagern trennt beides, lässt das CDN Medien direkt ausliefern und macht einen Anwendungsserver wirklich entbehrlich.

Ein Wiederherstellungstest beweist, was ein Backup nicht kann

Ein Backup beweist, dass eine Datei existiert. Ein Wiederherstellungstest beweist, dass die Datei vollständig ist, dass Datenbank und Dateien aus demselben Moment stammen, dass Ihre Zugangsdaten noch funktionieren und dass Sie wissen, wie lange es dauert. Das sind vier getrennte Fehlerarten, und keine davon ist an einem grünen Haken im Kontrollpanel zu erkennen.

Testen Sie es mindestens zweimal im Jahr gegen eine echte Uhr und schreiben Sie die Zahl auf. Dauert die Wiederherstellung sechs Stunden und Ihre Toleranz liegt bei einer, ist die Architektur das Problem, nicht das Backup. Wiederherstellungszeit ist eine Hosting-Anforderung und gehört in die Spezifikation statt in einen Störfall.

Ein Drupal-Hosting richtig dimensionieren

Seitenaufrufe sind die falsche Einheit. Eine Website mit 200.000 anonymen Seitenaufrufen im Monat hinter einem CDN kann auf einer kleinen Instanz bequem laufen, während eine Website mit 8.000 Seitenaufrufen ins Straucheln gerät, wenn die meisten davon angemeldet sind.

Angemeldeter Traffic ist der eigentliche Treiber

Anonyme Requests können vom Page Cache oder vom CDN beantwortet werden, ohne PHP zu berühren. Angemeldete Requests nicht. Jeder einzelne durchläuft die Render-Pipeline, prüft Zugriffsrechte an jeder Entity, löst Platzhalter auf und schreibt Sitzungsdaten. Die praktische Frage ist nicht, wie viele Besuche Sie bekommen, sondern wie viele gleichzeitig angemeldete Benutzer Sie haben und was diese Benutzer sehen dürfen.

Redakteure sind der Extremfall. Die Oberflächen zur Inhaltsverwaltung gehören zu den schwersten Seiten in Drupal und sind per Definition nicht cachebar, also hat eine Website mit zwölf gleichzeitig arbeitenden Redakteuren eine echte Nebenläufigkeitsanforderung, die ihr öffentlicher Traffic nie nahelegt.

Views, Taxonomie und Queue-Arbeit

Jenseits des angemeldeten Traffics sind die verlässlichen Kostentreiber große Views mit vielen Filtern und Beziehungen, die teure Joins erzeugen, tiefe Taxonomiebäume, deren Begriffshierarchien bei jedem Rendern durchlaufen werden, und Cron- oder Queue-Arbeit wie Suchindizierung, Feed-Importe und die Erzeugung von Medienableitungen.

Queue-Worker sollten sich die Ressourcen des Webservers nach Möglichkeit nicht mit Besuchern teilen. Auf einer größeren Website gehören sie in einen eigenen Prozess oder auf eine eigene Instanz, damit ein Importrückstau das Frontend nicht verlangsamen kann. Das ist eine Architekturentscheidung, die beim Kauf fällt, und der Punkt, an dem die verwalteten Stufen nicht mehr passen und eigene Infrastruktur zu passen beginnt.

Die Entscheidung richtig treffen

Das Muster ist beständig. Das Hosting ist nicht zu klein, es hat die falsche Form: keine Shell, kein Objekt-Cache, ein Opcode-Cache, den jemand anderes kontrolliert, und eine PHP-Version kurz vor dem Support-Ende. Dieselbe Website auf eine korrekt spezifizierte Instanz zu ähnlichem Preis zu verlegen schlägt in der Regel jede Menge Frontend-Optimierung.

Mecanik spezifiziert, baut und pflegt Drupal-Infrastruktur als Teil unserer Website-Entwicklung und prüft bestehende Stacks über ein Server-Sicherheitsaudit, wenn es um Angriffsfläche statt um Tempo geht. Wenn Sie Menschen statt einer Plattform brauchen, behandelt unser Leitfaden zum Beauftragen eines Drupal-Entwicklers, worauf zu achten ist.

Häufig gestellte Fragen

Was sind die Mindestanforderungen an einen Server für Drupal 11? PHP 8.3 oder neuer, und als Datenbank MariaDB 10.6, MySQL 8.0, PostgreSQL 16 oder SQLite 3.45. Auf Webserverseite Apache 2.4.7 oder Nginx 1.1 und neuer, wobei Microsoft IIS ab Drupal 11.0.0 nicht mehr unterstützt wird. Drupal warnt unterhalb von 64 MB PHP-Speicher, realistisch sind in der Produktion aber 256 MB.

Kann Drupal auf Shared Hosting laufen? Es installiert sich und liefert Seiten aus, aber Shared Hosting scheitert meist an drei oder vier Anforderungen gleichzeitig: kein Shell-Zugriff für Composer oder Drush, ein PHP-Speicherlimit, das Sie nicht anheben können, kein Redis oder Memcached, und Cron, das nur feuert, wenn zufällig ein Besucher eine Seite lädt. Genau diese Bedingungen erzeugen den Ruf, Drupal sei langsam.

Was sollte Drupal-Hosting kosten? Eine kleine Drupal-Website auf einer korrekt konfigurierten unverwalteten Instanz liegt typischerweise bei GBP 20 bis GBP 120 im Monat, bevor sie jemand betreut. Verwaltete Drupal-Plattformen beginnen üblicherweise nahe GBP 40 und steigen mit Traffic und Umgebungen in die Hunderte. Eigene Infrastruktur wird oberhalb von grob GBP 400 sinnvoll. Die billigste Stufe ist selten das billigste Ergebnis.

Braucht Drupal Redis? Nicht für eine kleine anonyme Website, wo der Internal Page Cache und die Datenbank ausreichen. Sobald Sie angemeldete Benutzer, Redakteure oder einen Mitgliederbereich haben, verlagert ein externer Objekt-Cache wie Redis oder Memcached Cache-Lesezugriffe, Sperren und Queues von der Datenbank weg, und das ist meist die größte Verbesserung, die für das Geld zu haben ist.

Ist ein CDN vor einer dynamischen Drupal-Website sicher? Ja, sofern Sie nach Cache-Tag statt nach Zeit invalidieren. Drupal notiert Tags wie node:5 für alles, wovon eine Antwort abhängt, und Module übersetzen diese in Cache-Tag- oder Surrogate-Key-Header, sodass das CDN genau die Seiten leert, die eine Bearbeitung betroffen hat. Ohne Tag-Invalidierung wählen Sie zwischen veralteten Seiten und einem Cache, der nie hilft.