cPanel & WHM Release: Neue Funktionen und sichere Update-Strategien

cPanel und WHM klar voneinander abgrenzen

cPanel und WHM gehören zwar zum selben Produkt, bedienen aber unterschiedliche Ebenen eines Hosting-Servers. cPanel ist die Oberfläche für ein einzelnes Hosting-Konto: Kundinnen und Kunden verwalten dort etwa Domains, E-Mail-Postfächer, Dateien, Datenbanken und die für ihr Konto freigegebenen Sicherheitsfunktionen. Welche Bereiche sichtbar und nutzbar sind, bestimmen vor allem Feature Lists, Pakete, Theme, Kontorechte und die Konfiguration des Hosting-Anbieters.

WHM ist dagegen die administrative Ebene des Hosting Panels. Serveradministratoren richten darin Konten, Pakete, Feature Lists und serverweite Dienste ein, während Managed-Hosting-Anbieter zusätzlich Standards für Provisionierung, Updates und Support festlegen. Reseller arbeiten abhängig von den delegierten Rechten mit einem begrenzten WHM-Bereich; daraus folgt nicht automatisch ein Zugriff auf das Betriebssystem, globale Dienste oder sämtliche Serverrichtlinien.

Ein cPanel Update betrifft deshalb nicht nur eine neue Ansicht im Kundenkonto. Änderungen können die Zuordnung von Themes, verfügbare Funktionen in Paketvorlagen und automatisierte Abläufe verändern. Auf Systemebene kommen Schnittstellen, Rechteprüfungen, installierte Erweiterungen und die Wechselwirkung mit dem Betriebssystem hinzu. Das Release Tier bestimmt dabei, welche Produktversion und welcher Build für den Server verfügbar werden, nicht unmittelbar die Sichtbarkeit einzelner Funktionen in einem bestimmten Kundenkonto.

Ein praktisches Beispiel ist die Einführung von Meridian: Wird das Theme über ein WHM-Paket vorgegeben, beeinflusst diese Entscheidung die Oberfläche neuer oder zugeordneter Konten. Nutzen Provisionierungsskripte zugleich APIs oder setzen Support-Anleitungen bestimmte Menüpfade voraus, müssen Theme-Policy, Paketvorlage und Automatisierung zusammen geprüft werden. Ein isolierter Theme-Wechsel kann sonst funktional korrekte, aber für Kunden und Support unerwartete Folgen haben.

Versionsstand, Builds und Release Tiers unterscheiden

Für eine belastbare Update-Planung müssen Hauptversion, Build und Release Tier getrennt betrachtet werden. Zum dokumentierten Stand ist cPanel & WHM 138 die jüngste veröffentlichte Produktions-Hauptversion. Version 134 ist der aktuelle LTS-Zweig mit einem längeren, planbaren Supportfenster. Version 136 erklärt zwar den Ursprung einzelner Änderungen, ihr reguläres Supportende lag jedoch bereits im August 2026; sie ist daher kein sinnvolles neues Upgrade-Ziel.

Eine Hauptversion benennt einen Release-Zweig, beispielsweise 138. Die Buildnummer präzisiert einen konkreten Stand innerhalb dieses Zweigs; im Changelog sind für 138 Änderungen bis zum Build 138.0.13 dokumentiert. Daraus folgt nicht, dass jeder Server diesen Build erhält oder überhaupt auf 138 aktualisiert wird. Maßgeblich ist auch, welchen öffentlichen Auslieferungskanal der Server verwendet.

Das Release Tier steuert, mit welchem Erprobungsgrad und in welchem Rhythmus Updates bereitgestellt werden. LTS, STABLE, RELEASE, CURRENT und EDGE sind daher keine bloßen Etiketten für denselben Softwarestand. Ein Server im LTS-Tier kann bewusst auf einem anderen Hauptversionszweig liegen als ein System im RELEASE-Tier, obwohl 138 allgemein die jüngste Produktions-Hauptversion ist.

Besondere Vorsicht gilt bei Versionsnummern mit ungerader Hauptnummer. Diese gehören zum Entwicklungsrelease im EDGE-Zweig und sind nicht mit einer veröffentlichten Produktionsversion gleichzusetzen. Ihre Existenz belegt weder eine abgeschlossene Entwicklung noch die Eignung für Kundenserver. Für Change-Management und Supportkommunikation sollten Administratoren daher stets installierte Version, konkreten Build und gewähltes Tier gemeinsam dokumentieren.

Warum ein cPanel Update Planung verlangt

Ein Versionswechsel bei cPanel & WHM ist nicht folgenlos rückgängig zu machen: Ein Downgrade auf eine frühere Hauptversion oder ein früheres Release Tier wird nicht unterstützt. Bei größeren Sprüngen arbeitet der Updater über erforderliche Zwischenversionen und prüft vor den einzelnen Schritten die Kompatibilität. Das reduziert ungeeignete Upgrade-Versuche, ersetzt aber keine fachliche Vorprüfung der eigenen Umgebung.

Technische Voraussetzungen können ein Update blockieren oder seinen Pfad bestimmen. Dazu zählen das verwendete Betriebssystem, ausreichend freier Speicher unter /usr/local/cpanel und aktive Sperren des Paketmanagers. Als dokumentiertes Beispiel kann Ubuntu 22 nicht auf cPanel & WHM 136 aktualisiert werden. Solche Hinweise sind keine Aufforderung, auf einen alten Zweig auszuweichen, sondern ein Anlass, Betriebssystemstand und vorgesehenen Migrationsweg vorab zu klären.

Neben dem Basissystem gehört eine betriebliche Prüfliste zum Update. Die dokumentierten Änderungen an SSL-API-Berechtigungen und entfernten Accounting-Helfern zeigen, dass eigene Automatisierungen oder Abrechnungsintegrationen betroffen sein können. Meridian- und CSF-Änderungen machen außerdem Theme-Zuweisungen, Feature Lists, lokale Firewall-Anpassungen und zugehörige Erweiterungen zu sinnvollen Prüfpunkten. Das sind keine vom Updater zugesagten Prüfungen, sondern Abhängigkeiten, die du in deiner Umgebung gezielt bewerten musst.

Als betriebliche Vorsichtsmaßnahme sollte das Update nur mit einem zur eigenen Umgebung passenden Wiederherstellungsplan, einem zuvor geprüften Sicherungsstand und klaren Zuständigkeiten beginnen. Die Herstellerdokumentation empfiehlt, eine neue Hauptversion zunächst auf einem kompatiblen Testsystem zu stagen; erst nach den eigenen Funktionsprüfungen sollte die Produktion kontrolliert folgen. Weil ein Downgrade nicht vorgesehen ist, darf eine mögliche Wiederherstellung aus Sicherungen nicht mit dem Zurückstellen des Release Tiers verwechselt werden.

Release Tiers nach Betriebsziel auswählen

Das Release Tier bestimmt, welchen Entwicklungs- und Prüfstand ein Server erhält; es ist damit eine Betriebsentscheidung und keine bloße Einstellung für automatische Updates. LTS konzentriert sich während seiner Laufzeit auf Sicherheits-, kritische und Kompatibilitätsaktualisierungen. STABLE wird seltener als RELEASE veröffentlicht, während RELEASE für Neuinstallationen der dokumentierte Standard ist.

CURRENT wird häufiger aktualisiert und kann Funktionen enthalten, die noch weiterentwickelt werden. EDGE erhält nur grundlegende Tests und gehört deshalb ausschließlich in kontrollierte Testumgebungen. Ungerade Hauptversionsnummern kennzeichnen Entwicklungsreleases im EDGE-Zweig; sie belegen weder Produktionsreife noch eine sichere Verfügbarkeit einer einzelnen Funktion.

Für planbares Shared Hosting ist LTS sinnvoll, wenn ein länger kalkulierbarer Funktionsstand wichtiger ist als eine neue Oberfläche oder frühe Automatisierungsfunktionen. Das bedeutet nicht, Updates auszusetzen: Sicherheits- und kritische Korrekturen bleiben Teil des Betriebs. Für neue Server spricht RELEASE, sofern Abhängigkeiten vorab geprüft und Wartungsfenster eingeplant sind.

Die Auswahl sollte außerdem zur Testorganisation passen. Wie bei anderen Hosting Panels ist nicht eine einzelne Versionsnummer entscheidend, sondern das Zusammenspiel aus Panel, Erweiterungen, Betriebssystem und Kundenstack. Der Beitrag Plesk-Updates für Hosting-Anbieter kontrolliert planen verdeutlicht diesen allgemeinen Grundsatz für eine andere Plattform. Eine Verzögerung von mehreren Geschäftstagen betrifft laut Update-Dokumentation nur automatische Upgrades auf die nächste Hauptversion im RELEASE-Tier und nur unter den dort genannten Bedingungen; EDGE, CURRENT, STABLE und LTS sind davon ausgenommen.

Neue Funktionen in Version 138 prüfen

Version 138 führt Meridian als Kundenoberfläche ein. Für WHM-Verantwortliche ist nicht allein das geänderte Layout relevant: Theme-Auswahl, Paketzuordnung, Feature Lists, Schulungsunterlagen und Supportabläufe müssen zusammenpassen. Das Release Tier bestimmt, ob der erforderliche Produkt- und Buildstand auf dem Server verfügbar ist; welche Bereiche ein einzelnes Konto sieht, hängt dagegen vor allem von Theme, Paket, Feature Lists und Anbieter-Konfiguration ab.

Bei Meridian ist eine flächige Umstellung ohne Policy riskant. Konten, die mit Meridian erstellt wurden und Jupiter nie verwendet haben, können nicht selbst zu Jupiter zurückwechseln. Administratoren können das Theme jedoch über WHM, ein Paket oder die API festlegen. Daher sollten Paketvorlagen und die Kommunikation an eine kleine Pilotgruppe vor der breiten Einführung verbindlich abgestimmt sein.

Die WHM-API-1-Funktion set_primary_domain_docroot kann das Document Root einer primären Domain ändern und wurde nach 134 und 136 zurückportiert. Das erleichtert Provisionierung oder Migration, ersetzt aber keine Prüfung der Anwendung. Ein CMS, ein Redirect, Dateirechte oder ein Deployment-Skript kann weiterhin den bisherigen Pfad voraussetzen; ein erfolgreicher Updater-Lauf erkennt diese fachliche Annahme nicht automatisch.

Ab Build 138.0.10 benötigen API-Funktionen zum Abruf von SSL-Zertifikaten und Schlüsseln das Feature sslinstall oder sslmanager. Eingeschränkte Feature Lists und externe Billing-Integrationen müssen deshalb gezielt geprüft werden. Zusätzlich entfernte cPanel veraltete Helferdateien aus Cpanel/Accounting; direkte Einbindungen in individuelle Abrechnungslösungen sind ein Anpassungsfall, keine automatisch behobene Kompatibilität.

Build 138.0.13 verändert außerdem die Anforderungen an Reseller-ACLs bei der Nameserver-Konfiguration. Reseller, die DNS-Clustering verwalten, benötigen möglicherweise das Privileg all, um die Nameserver-Einstellungen des Servers zu ändern. Prüfe daher vor der Aktualisierung delegierte Betriebsmodelle, die Rollen der verwendeten Reseller und automatisierte DNS-Cluster-Abläufe. Das Privileg erweitert den Zugriff deutlich und sollte nicht pauschal, sondern nur nach einer Rollen- und Sicherheitsprüfung zugewiesen werden.

Updates mit Inventur und Pilotierung vorbereiten

Vor dem Update wird zuerst der Ist-Zustand erfasst: installierte Version, Release Tier, Betriebssystem, Drittanbieter-Plugins, eigene API-Aufrufe, Firewall-Anpassungen sowie Backup- und Wiederherstellungsverfahren. Die Version lässt sich ohne Systemänderung im Terminal feststellen. Diese Inventur verbindet technische Komponenten mit ihren Verantwortlichen und verhindert, dass erst nach dem Update unklare Abhängigkeiten sichtbar werden.

/usr/local/cpanel/cpanel -V

Für einen Upgrade-Lauf verlangt cPanel mindestens 5 GB freien Speicher unter /usr/local/cpanel. Aktive Paketmanager-Sperren können den Vorgang blockieren; auch der Betriebssystempfad kann versionsabhängig Grenzen setzen. Diese Punkte gehören vor das Wartungsfenster, ebenso eine Wiederherstellung, deren Ablauf und Zugriffsrechte vorab geklärt sind.

Danach folgt Staging auf einem separaten, vergleichbaren Testsystem. Dort werden die maßgeblichen Pakete, Themes, Plugins und API-Integrationen mit nachgebildeten Testkonten geprüft. Teste typische Abläufe wie Anmeldung, Zertifikatsautomatisierung, Provisionierung und Anwendungsbetrieb. Die Herstellerdokumentation empfiehlt ausdrücklich, das Upgrade zuerst auf einem Testsystem zu stagen, bevor das Produktionssystem aktualisiert wird.

Eine Produktionspilotierung ist davon getrennt zu behandeln. Reale Kundenkonten werden nur nach ausdrücklicher Freigabe, mit begrenztem Umfang, Überwachung und einem kommunizierten Supportweg einbezogen. Lege vorher fest, welche Funktionsprüfungen erfolgen, wer im Störungsfall entscheidet und welche Wiederherstellung für das jeweilige Konto oder den Server möglich ist. Ein Test auf nachgebildeten Konten ersetzt diese Betriebsfreigabe nicht; umgekehrt ist ein Kundentest kein risikofreies Staging.

In WHM aktualisiert „Upgrade to Latest Version“ auf den neuesten Build des ausgewählten Release Tiers. Die Funktion garantiert daher nicht den Wechsel zur allgemein jüngsten Hauptversion. Bei RELEASE kann zudem eine automatische Verzögerung gelten; ein erzwungenes Update umgeht diese. Sicherheitsrelevante Betriebsmaßnahmen rund um Zugänge, Backups und Firewall sollten parallel zum Updateprozess gepflegt werden; praktische Grundlagen erläutert der Beitrag Hosting-Control-Panel-Sicherheit in WHM und cPanel.

Meridian und CSF kontrolliert betreiben

Meridian ist in cPanel & WHM 138 mehr als eine neue Kundenansicht. Das Theme bündelt Aufgaben in Bereichen wie Websites, E-Mail, Dateien, Datenbanken, Sicherheit und Performance. Für den Betrieb zählt deshalb nicht allein, ob die Oberfläche optisch passt, sondern ob Kunden die vorgesehenen Aufgaben mit ihren gebuchten Funktionen weiterhin eindeutig finden und ausführen können.

Vor der Freigabe sollte der Administrator eine verbindliche Theme-Policy festlegen: Welche Konten erhalten Meridian, welche Paketvorlagen weisen das Theme zu, und welche Feature Lists begrenzen einzelne Funktionen? Diese Einstellungen gehören zusammen. Ein Paket kann zwar ein Theme vorgeben, aber eine fehlende Funktion in der Feature List bleibt für das zugehörige Konto trotzdem nicht verfügbar.

Praktisch empfiehlt sich eine begrenzte Pilotgruppe mit repräsentativen Tarifen, etwa einem einfachen Webhosting-Konto, einem Konto mit mehreren Domains und einem Reseller-Szenario. Prüfe dabei typische Supportwege wie Postfachverwaltung, Datenbankzugriff und die Suche nach Sicherheitsfunktionen. Kundenkommunikation sollte Zeitpunkt, sichtbare Änderungen und einen erreichbaren Supportkanal nennen, statt den Wechsel als rein kosmetisch anzukündigen.

Der Rückwechsel zu Jupiter muss Teil dieser Planung sein. Konten, die mit Meridian erstellt wurden und Jupiter nie verwendet haben, können nicht selbst zu Jupiter zurückwechseln. Administratoren können das Theme weiterhin in WHM, über ein Paket oder per API ändern. Daraus folgt: Die Theme-Zuweisung und der zuständige Prozess müssen feststehen, bevor neue Konten standardmäßig mit Meridian angelegt werden.

CSF ist von der cPanel-&-WHM-Hauptversion getrennt zu betrachten. WebPros stellt den Fork auf unterstützten cPanel-&-WHM-Versionen als separat versioniertes Paket cpanel-csf bereit; es wird über die cPanel-Paketverwaltung installiert und aktualisiert. Die zuvor angekündigte Migration nicht unterstützter oder veralteter CSF-Installationen auf den unterstützten Fork wurde auf alle unterstützten cPanel-&-WHM-Versionen zurückportiert. Deshalb lässt sich der CSF-Stand nicht zuverlässig allein aus dem installierten cPanel-Build ableiten.

Als Prüfbasis brauchst du den installierten cpanel-csf-Paketstand, das separate CSF-Changelog, den Status der Paketverwaltung und die lokale Konfiguration. Sichere und vergleiche eigene Regeln, Allow- und Deny-Listen, Hooks, Benachrichtigungen sowie Plugins oder Deployment-Skripte. Prüfe zusätzlich, ob externe Werkzeuge Dateien oder Befehle einer früheren CSF-Installation voraussetzen. Der cPanel-Build bleibt für den allgemeinen Update-Kontext relevant, ersetzt aber weder diese Paketprüfung noch die Bewertung der lokalen Firewall-Konfiguration.

Fehler nach dem Update systematisch eingrenzen

Wenn nach einem Update Funktionen ausfallen, beginnt die Analyse mit dem gewählten Release Tier und dem tatsächlich installierten Build. Die allgemein jüngste Hauptversion ist nicht automatisch der Stand eines Servers; maßgeblich ist, welcher Build im konfigurierten Tier ausgeliefert wurde. Notiere außerdem Zeitpunkt, betroffene Konten und die konkrete Funktion, bevor Änderungen zur vermeintlichen Fehlerbehebung erfolgen.

Danach wertest du Update-Protokolle und mögliche Upgrade-Blocker aus. Bei größeren Versionssprüngen durchläuft der Updater Zwischenversionen und führt Kompatibilitätsprüfungen durch; aktive Paketmanager-Sperren oder unpassende Betriebssystempfade können den Ablauf beeinflussen. Ein abgebrochenes oder nur teilweise abgeschlossenes Upgrade rechtfertigt kein blindes Wiederholen mit erzwungenen Optionen, sondern zunächst die Klärung der protokollierten Ursache.

Anschließend testest du Abhängigkeiten in einer festen Reihenfolge: zuerst eigene WHM- oder cPanel-API-Aufrufe, dann Feature Lists und Theme-Zuweisungen, danach Plugins sowie Firewall-Regeln. So trennt die Fehlersuche eine zentrale Berechtigungsänderung von einem einzelnen Kundenkonto oder einer Erweiterung. Änderungen sollten nachvollziehbar dokumentiert und möglichst zunächst auf Staging oder einem abgegrenzten Konto geprüft werden.

Ein konkretes Fehlerbild betrifft SSL-Automatisierungen: Ab Build 138.0.10 benötigen API-Funktionen zum Abruf von SSL-Zertifikaten und Schlüsseln das Feature sslinstall oder sslmanager. Liefert ein Skript nach dem Update keine Zertifikatsdaten mehr, prüfst du deshalb zuerst die dem Konto zugewiesene Feature List und die Berechtigungen des verwendeten Zugangs, nicht nur Netzwerk oder Zertifikatsbestand.

Bei geänderten Document Roots beweist ein erfolgreicher API-Aufruf ebenfalls noch keine funktionierende Website. Die Funktion set_primary_domain_docroot kann den Pfad der primären Domain setzen, während CMS-Konfigurationen, Redirects, Dateirechte, VHost-Annahmen oder Deployment-Skripte weiterhin auf den alten Pfad zeigen. Teste daher Auslieferung, Administrationsbereich und Schreibvorgänge der Anwendung getrennt.

Auch individuell eingebundene Accounting-Integrationen können betroffen sein, weil veraltete PHP-Helferdateien aus Cpanel/Accounting entfernt wurden. Ist ein Abrechnungsprozess geschäftskritisch und keine kompatible Anpassung verfügbar, sind Wartungsstopp oder Wiederherstellung aus einem geprüften Backup angemessener als ein weiteres erzwungenes Update. Herstellerdokumentation und Protokolle liefern dann die Grundlage für einen belastbaren Anpassungsplan.

Die passende Update-Strategie verbindlich festlegen

Eine tragfähige Update-Strategie beginnt mit dem Betriebsziel, nicht mit der höchsten sichtbaren Versionsnummer. Entscheidend sind Supportzeitraum, Bedarf an neuen Funktionen, erwartete Kundenwirkung, verfügbare Testkapazität, Drittanbieterabhängigkeiten und der Sicherheitsbetrieb. Diese Kriterien müssen pro Servergruppe bewertet werden: Ein Shared-Hosting-Cluster, eine neue Managed-Plattform und ein internes Testsystem haben unterschiedliche Risiken und Änderungsrhythmen.

LTS eignet sich, wenn ein langfristig planbarer Stand wichtiger ist als fortlaufend neue Funktionen. Während seiner Laufzeit erhält dieser Zweig vor allem Sicherheits-, kritische und Kompatibilitätsaktualisierungen. LTS bedeutet daher weder, Updates auszusetzen, noch ersetzt es Backup-, Wiederherstellungs- und Abhängigkeitstests. Für etablierte Shared-Hosting-Angebote kann diese Begrenzung des Funktionswechsels den Support besser kalkulierbar machen.

STABLE wird seltener veröffentlicht als RELEASE und hat mehr öffentliche Erprobung durchlaufen. RELEASE ist funktionsvollständig und der Standard für Neuinstallationen. Beide sind sinnvolle Optionen, wenn neue Funktionen benötigt werden, aber Tests vor der breiten Einführung stattfinden. Welche der beiden Stufen passt, hängt daher davon ab, ob frühere Verfügbarkeit oder ein zusätzlicher Erprobungszeitraum wichtiger für die jeweilige Plattform ist.

CURRENT wird häufiger aktualisiert und kann Funktionen enthalten, die noch weiterentwickelt werden. EDGE erhält nur grundlegende Tests und ist ausschließlich für kontrollierte Testumgebungen vorgesehen. Ungerade Hauptversionsnummern gehören zu Entwicklungsreleases im EDGE-Zweig; sie belegen nicht, dass eine Funktion für die Produktion stabil verfügbar ist. Für produktive Kundenserver ist EDGE deshalb keine Abkürzung zu früheren Features.

Lege die Release-Policy schriftlich fest: zulässiges Tier je Serverklasse, Verantwortliche für Freigaben, Mindestumfang des Staging-Tests, Wartungsfenster und Kriterien für einen Abbruch. Eine Verzögerung von mehreren Geschäftstagen gilt ausschließlich für automatische Upgrades auf die nächste Hauptversion im RELEASE-Tier, sofern das Upgrade nicht manuell oder erzwungen gestartet wird und nur eine Hauptversion überspringt. EDGE, CURRENT, STABLE, LTS und fest eingetragene Versionsstände erhalten diese Verzögerung nicht.

Typische Fehlentscheidungen sind EDGE in Produktion, das Festschreiben einzelner Buildnummern in /etc/cpupdate.conf, fehlendes Staging und die Annahme, LTS erfordere keine Sicherheitsupdates. Ebenso problematisch ist es, einen erfolgreichen Updater-Lauf mit einer fachlichen Freigabe gleichzusetzen. Erst wenn Kundenfunktionen, Automatisierungen, Plugins und Schutzmechanismen im geplanten Umfang geprüft sind, wird aus einem technischen Update ein kontrollierter Betriebswechsel.