SixPanel: das Hosting-Panel, gebaut für eine Aufgabe — 6amMart betreiben
Sie mieten einen frischen Server, führen einen Befehl aus und bekommen eine Webseite zurück, die Ihren Shop betreibt. SixPanel installiert den Webserver, die Datenbank, PHP, den Cache, den Hintergrund-Worker, den Scheduler, den Websocket-Server und HTTPS — alles so konfiguriert, wie 6amMart es tatsächlich braucht.
Alles läuft auf Ihrem Server. Ihre Datenbank, Ihre Bilder, die Daten Ihrer Kunden.
- Schneller als ein vollständig abgestimmtes aaPanel — gleiche Hardware, gleicher Shop, gemessen
1,76×
Schneller als ein vollständig abgestimmtes aaPanel — gleiche Hardware, gleicher Shop, gemessen
- Betreibt einen ganzen Shop
2 Kerne / 4 GB
Betreibt einen ganzen Shop
- Auf CodeCanyon veröffentlicht, erste Einrichtung für Sie erledigt
Kostenlos
Auf CodeCanyon veröffentlicht, erste Einrichtung für Sie erledigt
- Sprachen der Panel-Oberfläche
8
Sprachen der Panel-Oberfläche
Lesen Sie diese Seite mit einem KI-Assistenten?
SixPanel bekommen
SixPanel installiert sich mit einem einzigen Befehl. Nichts anzumelden, kein Schlüssel einzugeben, kein Code einzufügen — es ist derselbe Befehl für alle. Es ist kostenlos.
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashWas einen Befehl als root schützt, ist nicht die Adresse — es ist die Signatur der Veröffentlichung. Der Installer trägt unseren Signierschlüssel und lehnt jede Datei, die nicht dazu passt, automatisch ab. Die Installationsseite erklärt es.
Ausprobieren, bevor Sie herunterladen
Nur-Lesen-Zugang
Username: demo Password: g5b7h878vjQN
Read-only: every change is refused and secrets are masked.
The shop runs a real dataset — tens of thousands of orders — so the screens behave the way they will on yours, not the way a demo with forty products does. Two things are switched off on the demo: maps and SMS one-time passwords. Both use keys locked to a single server, which is how they should be held, so they cannot answer from a demo host. They work normally on your own install.
SixPanel holen
Free- Updates inklusive — jede Veröffentlichung erscheint ohne weitere Kosten bei CodeCanyon, und das Panel kann sich auch selbst aktualisieren. Kein Lizenzserver, kein Schlüssel zu erneuern.
- Die erste Einrichtung ist kostenlos — schicken Sie Ihren Kaufcode und die Serverdaten per WhatsApp oder E-Mail.
Nichts zu aktivieren — läuft auf Ihrem eigenen Server, meldet sich nirgends, und funktioniert weiter, auch wenn diese Website ausfällt.
Was es ist und was es ersetzt
Das Script gehört Ihnen. Den Server muss trotzdem jemand betreiben.
Sie haben das 6amMart-Script bei CodeCanyon gekauft. Es ist ein Ordner voller Dateien. Bevor es eine Bestellung annehmen kann, muss jemand einen Webserver, eine Datenbank, PHP, einen Cache, einen Hintergrund-Worker und ein HTTPS-Zertifikat installieren — und das alles dann am Laufen halten.
SixPanel ist der Teil, der das erledigt. Sie mieten einen frischen Server, führen einen Befehl aus und bekommen ein Web-Control-Panel zurück. Aus diesem Panel verbinden Sie Ihre Domain, bekommen kostenloses HTTPS, installieren Ihren 6amMart-Code aus git, aktualisieren ihn, sichern ihn und sehen, was kaputt ist, wenn etwas kaputtgeht.
Alles läuft auf Ihrem Server. Ihre Datenbank, Ihre Bilder, die Daten Ihrer Kunden.
Drei Wege, es zu bedienen
Das Panel
Im Browser. Hier erledigen Sie fast alles.
Der sixpanel-Befehl
Auf dem Server, für den Fall, dass sich das Panel nicht öffnen lässt.
Der Installer
Den Sie einmal ausführen.
Mit versus ohne
Jede Zeile ist dieselbe Aufgabe, auf zwei Arten erledigt. Links, was der Betrieb von 6amMart ohne SixPanel von Ihnen verlangt; rechts, was daraus mit SixPanel wird.
Den Server zum Laufen bringen
Ohne
Einen Server von Hand bauen — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, eine Prozessüberwachung — und das alles am Leben halten
Mit SixPanel
Ein Installationsbefehl. Docker Compose ist der Supervisor, mit Restart-bei-Absturz, Restart-bei-Neustart, Speicherobergrenzen, Log-Rotation und Health-Checks, alles an einer Stelle deklariert.
Datenbank und PHP dimensionieren
Ohne
Die Datenbank- und PHP-Einstellungen raten oder jemanden fürs Abstimmen bezahlen
Mit SixPanel
Autotune liest die tatsächliche Maschine aus und schreibt die Größen: PHP-Worker, Datenbank-Buffer-Pool, Cache-Speicher, temporäre Tabellen, Sort- und Join-Buffer und das Redo-Log. Es deckt 1 Kern / 2 GB bis 16 Kerne / 32 GB ab, und die beiden Stellen, die diese Zahlen berechnen, werden bei jedem Build gegeneinander geprüft — weil sie sich einmal bei 66 von 432 Werten uneinig waren.
Eine Änderung ausliefern
Ohne
Für jedes Deployment einen Entwickler bezahlen
Mit SixPanel
Push nach git, der Shop aktualisiert sich. Deploy-Historie und Rollback, mit den letzten 30 Deploys.
Wissen, dass das Backup funktioniert
Ohne
Hoffen, dass das Backup funktioniert
Mit SixPanel
Backups laufen nach Zeitplan mit Aufbewahrung, und einmal pro Woche lädt das Panel das neueste Backup in eine Wegwerf-Datenbank, zählt, was darin ist, und löscht sie wieder.
Wenn der Shop ausfällt
Ohne
Einen Stack Trace lesen, um herauszufinden, warum der Shop offline ist
Mit SixPanel
Eine Zustandsseite mit etwa zwanzig Prüfungen, jede mit einem klaren Satz über die Folge und genau einer Schaltfläche zur Behebung.
Was es kostet
Ohne
Diesen Stack selbst zu bauen und zu pflegen ist der Preis — ob Sie ihn in Stunden oder in Rechnungen zahlen.
Mit SixPanel
Nichts. SixPanel ist kostenlos auf CodeCanyon, die erste Installation und Einrichtung ist kostenlos, und der Installationsbefehl ist derselbe öffentliche Befehl für alle — kein Schlüssel einzugeben, kein Code einzufügen. Updates kommen über CodeCanyon, und das Panel kann sich zusätzlich selbst aktualisieren.
Was es nicht ersetzt
Es verkauft Ihnen nicht das 6amMart-Script.
Das kaufen Sie bei CodeCanyon, und SixPanel installiert den Code, der Ihnen bereits gehört.
Es ist kein Shared Hosting.
Kein cPanel-Konto, keine anderen Websites auf der Maschine. SixPanel erwartet den ganzen Server.
Es betreibt nicht Ihren Shop.
Preise, Produkte, Fahrer und Bestellungen leben im eigenen Admin-Panel von 6amMart.
Es ist kein CDN und kein DDoS-Dienst.
Cloudflare ist die echte Edge-Schicht, und die Dokumentation sagt das auch.
Zwei Betriebsarten
Ein Panel, zwei Laufzeitumgebungen — und eine davon ist die Empfehlung
Beide sind dasselbe Produkt mit demselben Panel, denselben Befehlen und demselben Handbuch. Sie unterscheiden sich nur darin, wie die darunterliegende Software installiert wird, und dieser Unterschied ist messbar.
- Empfohlen
SixPanel
Läuft direkt auf dem Server
nginx, PHP-FPM, MariaDB und Redis, installiert aus dem eigenen Distributionsarchiv des Releases und von systemd überwacht. Nichts ist containerisiert, jeder Sprung läuft daher über einen Unix-Socket, und die Datenbank ist auf die Maschine abgestimmt und nicht auf einen Container. Das ist die schnellere der beiden, und dort geht die gesamte neue Arbeit hin.
Installationsbefehl
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- Betriebssystem
- Ubuntu 26.04 LTS (empfohlen), Ubuntu 24.04 LTS oder Debian 13
- PHP
- 8.5 auf Ubuntu 26.04, 8.4 auf Debian 13, 8.3 auf Ubuntu 24.04 — immer das eigene Paket des Releases
- Datenbank
- MariaDB 11.8 auf Ubuntu 26.04 und Debian 13, 10.11 auf Ubuntu 24.04 — aus demselben Archiv
- Überwacht von
- systemd
SixPanel Docker
Läuft in Containern
Derselbe Stack als Docker-Compose-Dienste. Sein Vorteil ist, dass die PHP- und die Datenbankversion überhaupt nicht vom Host abhängen: die Images sind auf PHP 8.4 und MariaDB 10.11 festgelegt, auf welchem Release Sie sie auch betreiben. Es installiert weiterhin, und Server, die es schon betreiben, erhalten weiter Updates.
Installationsbefehl
curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash- Betriebssystem
- Ubuntu 24.04 / 26.04 LTS, Debian 13 — und Debian 12, das installiert, aber nicht empfohlen ist
- PHP
- 8.4, im Container
- Datenbank
- MariaDB 10.11, im Container
- Überwacht von
- Docker Compose
Welche sollten Sie nehmen?
Nehmen Sie SixPanel, sofern nicht etwas ausdrücklich die andere Variante verlangt. Es ist auf jedem gemessenen Endpunkt schneller, es isoliert Projekte im Kernel statt innerhalb von PHP, und es ist die Laufzeitumgebung, die weiter verbessert wird.
Nehmen Sie SixPanel Docker, wenn Sie den gesamten Stack in Containern isoliert haben möchten, oder wenn Sie speziell MariaDB 10.11 auf einem Release brauchen, dessen Archiv es nicht mitbringt — die Images sind unabhängig vom Host auf PHP 8.4 und MariaDB 10.11 festgelegt. Es installiert außerdem weiterhin auf Debian 12, aber starten Sie dort keinen neuen Shop: der Sicherheitssupport von Debian 12 endete im Juli 2026, und Kernel, glibc, Docker und OpenSSH kommen weiterhin aus dem Archiv des Hosts.
Ganz offen: Die neue Entwicklung geht in die native Laufzeitumgebung. SixPanel Docker wird gepflegt, nicht erweitert. Wenn Sie heute installieren und das Betriebssystem frei wählen können, nehmen Sie die native Variante.
Gemessen, nicht behauptet
Drei Server, derselbe Shop, ein Unterschied
Jede Leistungszahl auf dieser Seite stammt aus einer Messreihe auf echten Servern mit den Daten eines echten Shops. Aufbau, Methode und Skripte sind veröffentlicht — und ebenso der Teil, der bis heute unerklärt ist.
1.76×
schneller als ein vollständig abgestimmtes aaPanel
1,82×, wenn vier Anfragen gleichzeitig eintreffen. Gemessen über die Endpunkte, die auf beiden Servern PHP erreichen.
Wie gemessen wurde
- Drei Server
- AMD EPYC 7713, 2 vCPU, 4 GB, Ubuntu 24.04 — identisch bis auf das Panel, das getestet wurde
- Dieselbe Anwendung
- Derselbe 6amMart-Code auf allen dreien, Byte für Byte überprüft: identische Dependency-Lockfile, identischer Hash über Anwendung, Routen, Module und Konfiguration
- Derselbe Shop
- 66.701 Bestellungen · 3.865 Artikel · 85 Stores · 17.534 Kunden — ein echter Datensatz, Zeile für Zeile kopiert
- Die Methode
- Jede Maschine misst sich selbst über Loopback, mit ihrem echten Hostnamen und ihrem echten Zertifikat. 40 Messwerte pro Zelle nach einem verworfenen Aufwärmlauf, und jede angegebene Zahl ist der Median abwechselnd gepaarter Durchläufe.
- Nichts wird stillschweigend weggeworfen
- Null ratenbegrenzte Antworten und null Fehler in jeder veröffentlichten Zeile. Eine blockierte oder fehlgeschlagene Anfrage antwortet sehr schnell — ein Durchlauf, der sie verbirgt, meldet also eine bessere Zahl als die Wahrheit.
Jeder Endpunkt, alle vier Konfigurationen
Median in Millisekunden — eine Anfrage / vier gleichzeitig. Weniger ist besser.
| Endpunkt | SixPanel | SixPanel Docker | aaPanel, Auslieferungszustand | aaPanel, abgestimmt |
|---|---|---|---|---|
/api/v1/categoriesAuf allen dreien zu PHP gezwungen — die sauberste Zeile mit gleichen Voraussetzungen | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allDie Store-Liste, die jeder Kunde zuerst sieht | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchDer schwerste Lesevorgang in der Anwendung | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularJoins über den gesamten Katalog | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listAngemeldet und nicht cachebar — der langsamste Aufruf auf jeder Maschine | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)SixPanel leitet mit 430 Bytes um; aaPanel rendert 352 KBAndere Arbeit | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeSixPanel rendert die Seite; bei aaPanel ist es ein Treffer im Proxy-CacheAndere Arbeit | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeZeit bis zur Annahme der Verbindung | 2.35.8 | 4.211.6 | 2.66.3 | —— |
Grün ist die schnellste Konfiguration in dieser Zeile.
Zwei Zeilen sind markiert, weil die Server darin nicht dieselbe Arbeit leisten. Die Zahlen sind echt; sie sind nur kein fairer Vergleich, und sie werden gezeigt statt weggelassen.
Dann wurde der Konkurrent vollständig abgestimmt, und der Abstand schloss sich nicht
Einen Wettbewerber in seinen Standardeinstellungen zu schlagen beweist nichts. Also wurde die aaPanel-Maschine so abgestimmt, wie ein kompetenter Administrator sie abstimmen würde, und jede Zahl wurde erneut erhoben.
- PHP-opcache von 128 MB auf 256 MB angehoben, mit abgeschalteter Zeitstempel-Prüfung
- Datenbank-Buffer-Pool von 256 MB auf 1152 MB angehoben — viereinhalbmal so groß
- Datenbank-Logdatei von 128 MB auf 320 MB angehoben und der Query-Cache abgeschaltet
- PHP-Worker von überbuchten 50 auf bemessene 14 korrigiert
- Pfad-Cache vervierfacht und die Puffer des Webservers verdoppelt
Sein PHP 8.4 und sein JIT-Compiler blieben bewusst eingeschaltet. Das sind seine Vorteile, und sie wegzunehmen hätte den Test manipuliert.
Gegen die Maschine im Auslieferungszustand war SixPanel 1,65× / 1,80× schneller. Gegen die vollständig abgestimmte Maschine sind es 1,76× / 1,82×. Der Abstand hat sich leicht in die andere Richtung verschoben.
Die Datenbank-Batterie bewegte sich überhaupt nicht. Ein viereinhalbmal so großer Buffer-Pool änderte nichts, denn diese Reports sind prozessorgebundene Arbeit über Zeilen, die ohnehin schon im Speicher lagen. Die internen Werte verbesserten sich durchaus — Cache-Trefferquote von 99,856 % auf 99,930 %, auf die Festplatte auslagernde temporäre Tabellen von 47,3 % auf 22,1 % — und die Antwortzeiten folgten nicht.
Woher der Abstand tatsächlich kommt
Eine Geschwindigkeitsbehauptung ist ohne Ursache sehr wenig wert. Also wurde der Unterschied auf den fünf Endpunkten, die auf beiden Maschinen PHP erreichen, auseinandergenommen, eine Variable nach der anderen.
| Konfiguration | Eine Anfrage | Vier gleichzeitig |
|---|---|---|
| So wie die beiden Maschinen ausgeliefert werden | 1.99× | 1.91× |
| Nach dem Abschalten der Verzeichnisbeschränkung von aaPanel | 1.32× | 1.29× |
| Nach zusätzlicher Korrektur seines JIT-Compiler-Modus | ≈1.25× | ≈1.21× |
Der Abstand, aufgeschlüsselt
- Eine PHP-Verzeichnisbeschränkung60%
- Der falsche JIT-Compiler-Modus8%
- PHP-Version0%
- Weiterhin unerklärt32%
Etwa ein Drittel des Unterschieds ist nicht zugeordnet und wird als unerklärt veröffentlicht, statt uns gutgeschrieben zu werden. Der führende, ungetestete Kandidat ist, dass aaPanel sein PHP selbst kompiliert, während Ubuntu ein Paket ausliefert. Weder das noch der verbleibende Einstellungsunterschied lässt sich auf einer einzelnen Maschine isolieren, also wird keines von beiden behauptet.
Die Form zählt mehr als das Verhältnis
Die Abgabe ist ein fester Aufwand pro Anfrage, sie dominiert also kurze Arbeit und verschwindet bei langer. Derselbe 20,9 Sekunden lange Admin-Report liegt zwischen den beiden Maschinen nur 1,17× auseinander. Wenn Ihr Shop überwiegend schwere Reports fährt, wird der Unterschied klein sein. Wenn er überwiegend API-Aufrufe von Telefon-Apps bedient — und genau das ist ein Lieferdienst-Shop überwiegend —, ist er der gesamte Unterschied.
Der Rechenweg, vollständig
Die größte Einzelursache war eine einzige PHP-Einstellung, und sie kostete 16 bis 26 ms bei jeder Anfrage≈60 % des Abstands
aaPanel schränkt ein, welche Verzeichnisse PHP anfassen darf. Das ist eine echte Sicherheitsfunktion, sie verdiente also eine echte Messung, statt als Ballast abgetan zu werden.
Drei abwechselnde Paare, wobei der „Aus“-Arm eine leere Einstellungsdatei schreibt, damit der Scan pro Verzeichnis in beiden Armen weiterhin stattfindet — sonst würde der Vergleich den Scan messen statt die Einstellung.
Jeder Endpunkt bewegte sich zwischen 17 % und 46 %. Eine statische Datei, die PHP überhaupt nie erreicht, bewegte sich um nichts — das ist die Kontrolle, und sie macht den Rest zu einem Ergebnis statt zu einem Zufall. Die Streuung von Arm zu Arm liegt auf diesen Maschinen bei 1 % bis 13 %.
Der Mechanismus wurde dann auf drei getrennte Arten gezählt: 5.862 Dateisystem-Lookups pro Anfrage mit eingeschalteter Beschränkung, 214 mit ausgeschalteter und 217 auf SixPanel. Mit eingeschalteter Beschränkung fügen 400 Pfadauflösungen null Einträge zu PHPs Pfad-Cache hinzu; mit ausgeschalteter fügen sie 509 hinzu. Der Cache ist schlicht deaktiviert, und genau deshalb brachte aaPanel seine eigene abgestimmte Cache-Größen-Einstellung nichts.
Auf einer zweiten Maschine in der anderen Richtung bestätigt: Dieselbe Beschränkung für SixPanel einzuschalten reproduzierte 17 bis 23 ms zusätzliche Zeit pro Anfrage.
Nützlich zu wissen, wenn Sie einen Server administrieren: Diese Einstellung stand in einer Datei pro Verzeichnis, die vier andere Stellen nicht zeigten. Den Wert aus dem Prozess zurückzulesen, der die Anfragen tatsächlich bedient, ist die einzige verlässliche Prüfung.
| Endpunkt | Beschränkung ein | Beschränkung aus | Änderung |
|---|---|---|---|
/api/v1/config | 37.7 | 20.3 | −46% |
/api/v1/stores/get-stores/all | 39.8 | 23.5 | −41% |
/api/v1/items/search | 40.6 | 24.1 | −41% |
/api/v1/categories | 55.4 | 33.7 | −39% |
/api/v1/items/popular | 70.7 | 51.5 | −27% |
/ (admin entry) | 85.7 | 66.4 | −23% |
/api/v1/customer/order/list | 154.9 | 128.9 | −17% |
static assetKontrolle — erreicht PHP nie | 0.4 | 0.4 | 0% |
aaPanel fährt für diese Anwendung den falschen JIT-Compiler-Modus≈8 % des Abstands
PHPs JIT-Einstellung ist eine vierstellige Zahl und kein Ein-/Ausschalter, und die beiden benannten Modi sind verschieden: „function“ ist 1205 und „tracing“ ist 1254. Ein Tuning-Skript, das nur prüft, ob JIT aktiviert ist, lässt bereitwillig den falschen stehen und meldet die Aufgabe als erledigt.
aaPanel liefert 1205 aus. SixPanel liefert tracing aus. Drei abwechselnde Paare setzten tracing bei einer Anfrage auf 9 von 9 Endpunkten vorn und bei vier gleichzeitig auf 9 von 9 — geometrisches Mittel 5,1 % und 6,2 %.
Jeder einzelne dieser Unterschiede liegt innerhalb des Rauschens dieser Maschinen. Achtzehn von achtzehn, die in dieselbe Richtung fallen, nicht.
Für 6amMart im Besonderen ist tracing der richtige Modus: function-JIT zielt auf enge numerische Schleifen, die ein Laravel-Request nicht ausführt.
Eine PHP-Version zurückzuliegen kostet nichts — gemessen, nicht angenommen0 % des Abstands
SixPanel installiert das PHP, das das eigene Archiv des Releases mitbringt — 8.5 auf Ubuntu 26.04, 8.4 auf Debian 13, 8.3 auf Ubuntu 24.04 — denn bei den eigenen Paketen der Distribution zu bleiben bedeutet, dass Sicherheitsupdates automatisch ankommen, ohne ein Drittanbieter-Repository im ausliefernden Pfad. Der naheliegende Einwand ist, dass ein neueres PHP schneller wäre.
Auf der aaPanel-Maschine sind beide Versionen installiert, sie konnte das also sauber beantworten. Der 8.3-Pool bekam zuerst das gesamte 8.4-Tuning — er war auf Standardwerten belassen worden, was das Ergebnis manipuliert hätte — und die Einstellungen wurden aus dem laufenden Prozess überprüft, nicht aus einer Datei.
Drei abwechselnde Paare: geometrisches Mittel von 8.3 gegen 8.4 ist 0,9994. 8.3 lag in 3 von 7 Zeilen vorn, und jeder Unterschied war kleiner als die Lauf-zu-Lauf-Streuung mindestens eines der beiden Arme. Der langsame Admin-Report bestätigte das.
Die Regel, die SixPanel bei den eigenen Paketen der Distribution hält, ist also kostenlos — sie kostet keine Geschwindigkeit. Es gibt auch keine Obergrenze zu umgehen: die composer.json von 6amMart deklariert eine Grenze unterhalb von 8.5, aber das ist eine Deklaration und keine Messung, und den Code auf 8.5.4 laufen zu lassen ergab sowohl auf dem reinen CodeCanyon-Baum als auch auf unserem eigenen Fork einen bytegleichen Tabellenexport und ein Laravel, das startet.
Was geprüft wurde und sich nicht als Ursache erwiesSechs Kandidaten
Jeder davon ist eine plausible Erklärung, die jemand anbieten könnte. Jeder wurde gemessen und ausgeschlossen.
- Der Webserver
- Jeder Endpunkt wurde über die Leitung gemessen und noch einmal innerhalb eines einzelnen PHP-Prozesses, auf beiden Maschinen. Der Unterschied beträgt 0 bis 7 ms auf aaPanel und 3,5 bis 5 ms auf SixPanel, größtenteils der Verschlüsselungs-Handshake. Der von aaPanel ist nicht größer, obwohl es pro Anfrage einen Zugriffs-Log-Eintrag schreibt.
- Die Datenbank
- Abfragezeiten über alle drei Konfigurationen praktisch identisch. Datenbestände in jeder Tabelle innerhalb von etwa 1 %, und Konfigurationen nach dem Abstimmen bis auf den Patch-Stand übereinstimmend.
- Wie PHP die Datenbank erreicht
- Beide über den lokalen Socket, überprüft aus dem laufenden Prozess statt aus einer Konfigurationsdatei.
- Die Cache-Schicht
- Gezählt statt aus einer Konfigurationsdatei gelesen: 17,1 Cache-Befehle pro Anfrage auf aaPanel, 18,1 auf SixPanel. Keiner von beiden fällt still auf die Festplatte zurück.
- PHPs Cache für kompilierten Code
- Null Speicherüberläufe, null Hash-Kollisionen und null manuelle Neustarts auf beiden. SixPanel bei einer Trefferquote von 99,86 % und 0 % Verschwendung.
- Die Hardware
- Identisch bis hin zum Prozessormodell und zum Satz der aktivierten Sicherheits-Mitigationen.
Das Langsamste in 6amMart ist nicht der Server, und kein Panel kann es behebenAnwendungscode
Alle 297 Admin-Seiten wurden auf dem echten Datenbestand mit 66.701 Bestellungen gemessen. 290 davon antworten in unter 300 ms. Das Panel ist nicht breitflächig langsam.
Sieben Seiten machen das gesamte Problem aus. Die schlimmste, der tagesweise Transaktionsreport, braucht 20,86 Sekunden, davon 12,43 Sekunden innerhalb des Datenbanktreibers — und eine einzige Abfrage läuft 122-mal zu je 87,6 ms, was für sich genommen 10,7 Sekunden sind.
Er ist auf jedem getesteten Server vorhanden und blieb von jeder ausprobierten Einstellung unberührt, einschließlich des vollständigen aaPanel-Tuning-Durchgangs: 20.925 ms davor, 20.470 ms danach.
Das ist der eigene Code von 6amMart, also kann kein Control-Panel das beheben, und keines sollte das behaupten. Es ist vollständig gegen die Anwendung selbst dokumentiert, und es ist genau die Art von Sache, für die es unseren 6amMart-Installationsservice gibt.
Alles, was wir veröffentlichen
Jeder Bericht, an einem Ort
Keine Zahl auf dieser Seite steht allein — jede stammt aus einem veröffentlichten Bericht mit seiner Methode, seinen Vorbehalten und den Ergebnissen, die uns nicht geschmeichelt haben. Lesen Sie sie, bevor Sie kaufen; dafür sind sie da.
SixPanel vs. aaPanel
1.76× schneller bei einer Anfrage, 1.82× bei vier gleichzeitig eintreffenden — gegen ein voll getuntes aaPanel, mit aufgeschlüsselter Ursache und 32% der Lücke ehrlich als ungeklärt ausgewiesen.
SixPanel vs. SixPanel Docker vs. aaPanel
Drei Panels auf identischer Hardware und einem byte-identischen Shop — die vollständige Methode hinter den Schlagzeilen-Zahlen.
SixPanel vs. CloudPanel
Ein fairer Vergleich: CloudPanel ist gute Allzweck-Software. Die Frage ist, welches Problem Sie lösen.
SixPanel vs. ein blanker Server
Was das Panel gegenüber dem handgebauten Server hinzufügt, mit dem die meisten Betreiber anfangen — und was das über ein Jahr kostet.
Welches Betriebssystem
Ubuntu 26.04 gegen Ubuntu 24.04 gegen Debian 13, gemessen: die Geschwindigkeit ist ein Gleichstand, die Support-Fenster sind es nicht.
Welche Datenbank-Engine
Fünf Engines gegen einen echten Shop. MariaDB 11.8 und 10.11 sind über die gesamte Anwendung ein Gleichstand; beide MySQLs können sie unverändert nicht betreiben.
Optimiertes 6amMart — die gemessenen Ergebnisse
Der 22× schnellere Featured-Streifen, der Admin-Durchlauf über 297 Seiten, ein 17.5-Sekunden-Bericht auf 0.7 gebracht — samt der zwei absichtlich langsam gelassenen Seiten, veröffentlicht neben den Erfolgen.
Der Skalierungstest
66,701 echte Bestellungen, 113,231 Bestellpositionen — der Datensatz, in dem die stillen Defekte zutage traten.
Behobene Defekte
Die, die Geld kosten, ohne je einen Fehler anzuzeigen — Gutscheine, Uhren, Lagerbestand, doppelte Zahlungen.
Was noch offen ist
Die Seite, die die anderen vier lesenswert macht: was wir nicht gelöst haben, klar benannt.
Das Changelog
Jedes Release, samt der Fehler und dem, was wir daraus gelernt haben.
Was Sie tatsächlich bekommen
Gruppiert so, wie ein Käufer über die Aufgabe nachdenkt
Zwei Dinge tragen einen ausdrücklichen Vorbehalt. Die Übernahme von einem alten Server und die Wiederherstellung auf derselben Maschine wurden in der Runde vom 15. August nur im Code geprüft und nicht ausgeführt. Sie sind unten markiert. Alles andere hier wurde ausgeführt oder ist eine ausgelieferte, einsehbare Oberfläche — aber die ehrliche Form des Satzes lautet „das wird mitgeliefert“, nicht „das ist auf Ihrer Art von Server bewiesen“.
Zum Laufen bringen
Vom gemieteten Server zur Panel-Anmeldung, ohne einen von Hand gebauten Stack.
- Ein Befehl. Der Installationsbefehl wird geladen, gegen einen veröffentlichten Fingerabdruck geprüft und erst dann ausgeführt. Stimmen die Fingerabdrücke nicht überein, bricht der Befehl ab und es wird nichts installiert.
- Er verweigert einen Server, auf dem er nicht laufen kann, mit Namen und bevor irgendetwas heruntergeladen wird: falsches Betriebssystem, falscher Prozessortyp, zu wenig Speicher, ein anderes Control-Panel vorhanden oder etwas, das bereits Port 80 oder 443 belegt.
- Ein Einrichtungsassistent bei der ersten Anmeldung: Grundlagen → Passwort → Domain → SSL → App → Backups.
- Autotune bei der Installation und später auf Wunsch. Es bemisst Datenbank, Cache und PHP-Worker anhand der echten Maschine.
- Betreibt einen ganzen Shop auf 2 Kernen und 4 GB.
- Im Code geprüft, nicht ausgeführt: Oder ziehen Sie einen bestehenden Shop um. SixPanel kann eine laufende Installation über SSH von einem alten Server holen — die Einstellungsdatei, die Uploads und einen Datenbank-Dump, der herüber gepipet wird. In der Runde vom 15. August nicht ausgeführt, nur im Code geprüft. Führen Sie es gegen einen Ersatzserver aus, bevor Sie sich darauf verlassen, und behalten Sie die alte Maschine, bis Sie das getan haben.
Warum das zählt: Am ersten Tag verlieren die meisten Shops eine Woche — dieser endet mit einer funktionierenden Seite.
Ihre Domain und HTTPS
Echte Zertifikate, für Sie erneuert, und Cloudflare sauber behandelt.
- Kostenlose Let's Encrypt-Zertifikate, automatisch erneuert von einem täglichen Job.
- Mehr als eine Domain pro Shop, pro Ziel (Admin, Storefront, Websocket), jede mit eigenen Kennzeichen für primär, SSL und Cloudflare.
- Cloudflare-bewusst. Es versucht zuerst ein echtes Let's Encrypt-Zertifikat durch den Cloudflare-Proxy, was mit Full (strict) funktioniert. Geht das nicht, fällt es auf ein selbstsigniertes Origin-Zertifikat mit 10 Jahren Laufzeit zurück, das Full benötigt. Es liefert die IP-Bereiche von Cloudflare mit, damit Ihre Logs die echte Adresse des Besuchers zeigen und nicht die von Cloudflare.
- Ein Cloudflare-Token, und das Panel verwaltet eine Reihe von Cloudflare-Optionen für Sie. Es zeigt für jeden Punkt Soll gegen Ist und einen Abgleich per Push oder Pull. Ihre eigenen Regeln überstehen einen Schreibvorgang.
- Eine Firewall-Seite, die die genauen Regeln für Ihren Server ausgibt, dazu beide Cloudflare-Bereichslisten und die Befehle, um sie zu prüfen. Das Panel fasst die Firewall Ihres Anbieters selbst nie an.
Warum das zählt: HTTPS-Ausfälle sind der klassische stille Killer — ein Zertifikat, das an einem Samstag abläuft, reißt den Shop mit.
Codeänderungen ausliefern
Zwei Arten von Update, die nie miteinander verwechselt werden.
- Push zum Deployen. Ein signierter Webhook von Ihrem git-Host startet das Deployment.
- Deploys → Update bewegt Ihren 6amMart-Code. Einstellungen → Self-Update bewegt SixPanel. Keines von beiden fasst Ihre Einstellungsdatei, Ihren data/-Ordner oder Ihre Datenbank an.
- Historie und Rollback, mit den letzten 30 Deploys.
- Ein Schutz für den unveränderten Baum. Wenn Sie Dateien auf dem Server bearbeitet haben, verweigert das Update und nennt die Dateien, statt Ihre Arbeit zu überschreiben.
Warum das zählt: Die riskantesten Minuten im Betrieb eines Shops sind die direkt nach dem „Deploy“ — hier werden sie langweilig.
Nichts verlieren
Geplant, inkrementell und einmal pro Woche bewiesen statt angenommen.
- Inkrementelle Backups (restic), nach Zeitplan, mit Aufbewahrung.
- Vier Ziele: derselbe Server, S3, SFTP oder Google Drive.
- Ein wöchentlicher automatischer Wiederherstellungstest in eine Wegwerf-Datenbank — Ihre echten Daten werden nie angefasst, und das Ergebnis erscheint sowohl auf der Backup-Seite als auch auf der Zustandsseite.
- Ein Backup enthält die Datenbank jedes Projekts, die hochgeladenen Dateien und die Einstellungsdatei der Anwendung. Es enthält nicht Ihren Code — der kommt aus git zurück.
- Ein gemeinsames Backup-Passwort, einmal erzeugt und im Zustand des Panels aufbewahrt. Verlieren Sie es, lässt sich nie wieder ein Backup öffnen.
- Im Code geprüft, nicht ausgeführt: Die Wiederherstellung wurde in der Runde vom 15. August im Code geprüft, nicht ausgeführt. Lesen Sie auch die zwei Grenzen zur Wiederherstellung weiter unten — sie sind der Grund, warum das wichtig ist.
Warum das zählt: Ein nie geöffnetes Backup ist eine Hoffnung, kein Backup. Der wöchentliche Restore-Test macht den Unterschied.
Den Alltag bewältigen, ohne Systemadministrator zu sein
Das Panel benennt das Problem und gibt Ihnen die Schaltfläche.
- Zustandsseite: etwa 20 Prüfungen, sortiert nach Handlungsbedarf, in Ordnung und Information, jede mit einem Satz zur Folge und einer Schaltfläche zur Behebung. Jede Prüfung ist auf 2 Sekunden begrenzt und die ganze Seite auf 10 Sekunden, eine hängende Prüfung kann die Seite also nicht aufhängen.
- Drei Quellen sind sich bei dieser Zahl uneinig. Das mitgelieferte Handbuch sagt „mehr als zwanzig“, die Code-Inventur zählt etwa 20 Prüfungen, und eine ältere Seitenspezifikation sagt etwa fünfzehn. Diese Seite druckt etwa 20 — den niedrigeren der beiden Werte, die im ausgelieferten Produkt belegt sind.
- Ein Watchdog, der fehlerhafte Container neu startet. Docker startet einen Container nicht neu, der läuft, aber nicht funktioniert, weil unless-stopped nie bei einer fehlgeschlagenen Health-Check auslöst. SixPanel's eigene Schleife tut es, und die Health-Checks testen die Arbeit, nicht nur ob der Prozess lebendig ist.
- Eine Job-Engine. Ein langer Job zur Zeit, der Rest wartet in der Warteschlange. Das Log läuft live in den Browser. Die letzten 20 Jobs werden aufbewahrt, je 2,000 Zeilen.
- Ein Editor für die Einstellungsdatei Ihrer App, der Ihre Kommentare, Ihre Reihenfolge und Ihre unbeteiligten Zeilen erhält, jedem Schlüssel das passende Eingabefeld gibt und die Schlüssel, die dem Stack gehören, als schreibgeschützt markiert.
- Ein Dateimanager, eingezäunt auf genau zwei Ordner: Ihren Admin-Code und Ihren Storefront-Code.
- phpMyAdmin bei Bedarf — von der Datenbankseite gestartet und gestoppt, nie dauerhaft laufen gelassen.
- Die Aufzeichnung langsamer Abfragen, die Sie auf der Datenbankseite einschalten und leeren können.
- Ein sixpanel-Befehl auf dem Server, mit Handbuchseite, Spickzettel, nummeriertem Menü, einer Meinten-Sie-Erkennung und Shell-Vervollständigung.
- Das vollständige Kundenhandbuch im Panel, hinter derselben Anmeldung — 24 Aufgabenseiten.
- Ein Support-Paket mit einem Befehl. Es sammelt Versionen, Zustandsergebnisse, Dienstzustände, Speicherbelegung und die letzten 500 Zeilen jedes Logs. Bevor es geschrieben wird, wird Ihre Einstellungsdatei auf reine Schlüsselnamen reduziert, die eigene Zustandsdatei des Panels wird gar nicht erst gesammelt, und der geheime Code in Ihrem Panel-Link sowie übliche passwortartige Werte werden maskiert.
Warum das zählt: Das Panel, das Sie tatsächlich jeden Tag öffnen, sollte „Ist alles in Ordnung?“ mit einem Blick beantworten, nicht mit einer Stunde.
Andere Leute hereinlassen
Zeitlich begrenzter Zugang, statt Ihr Passwort herauszugeben.
- Temporäre Zugänge für einen Entwickler: eigener Name und eigenes Passwort, ablaufend nach 1 Stunde, 8 Stunden, 24 Stunden oder 7 Tagen, bis zu 20 gleichzeitig aktiv. Das Passwort wird genau einmal angezeigt. Sie können die Website betreiben. Sie können nicht ändern, wer hereinkommt, und Ihre Geheimnisse nicht lesen.
- Ein schreibgeschützter Demo-Zugang, um jemandem das Panel zu zeigen. Zwei Stunden Sitzungsdauer, jeder Schreibvorgang abgelehnt, sensible Werte maskiert.
- Ein Aktivitätsprotokoll und eine Liste aktiver Sitzungen, die Sie einzeln oder alle auf einmal beenden können.
- Im Code geprüft, nicht ausgeführt: Das Aktivitätsprotokoll deckt nicht alles ab. Das Anlegen, Bearbeiten und manuelle Ausführen einer geplanten Aufgabe wird aufgezeichnet, aber das Löschen schreibt überhaupt keinen Protokolleintrag.
Warum das zählt: Die meisten Panel-Einbrüche sind nicht raffiniert — sie sind ein erratenes Passwort auf einer sichtbaren Login-Seite. Diese hier ist nicht sichtbar.
Mehr als ein Shop auf einem Server
Konstruktionsbedingt getrennt, nicht per Konvention.
- Jedes Projekt hat seine eigenen Container, seine eigene Datenbank und seinen eigenen Datenbank-Benutzer, seinen eigenen Anwendungsordner, seinen eigenen vhost und seine eigene Redis-Cache-Datenbank – also den Cache auf einem Shop zu leeren kann den eines anderen nie leeren.
- Zwei Projekte können nicht dieselbe Datenbank teilen: Der Name wird aus einem validierten, eindeutigen Slug abgeleitet.
- Rechnen Sie mit rund 2 GB mehr RAM und 1–2 zusätzlichen Kernen pro weiterem Shop — planen Sie 2 Kerne ein, das obere Ende dieser Spanne, denn Unterdimensionierung ist der teure Fehler.
Warum das zählt: Der zweite Shop einer Agentur sollte die Daten des ersten nicht einmal theoretisch lesen können — hier erzwingt das der Kernel, und wir haben es per Angriff überprüft.
Geschwindigkeit, die bereits konfiguriert ist
Ein fünf-Sekunden-Mikro-Cache im nginx-Container auf Ihrem eigenen Server, auf die Anfragemuster von 6amMart zugeschnitten.
- Ein fünf-Sekunden-FastCGI-Mikro-Cache in nginx über eine feste Liste öffentlicher Katalog-Endpunkte. Wenn 100 Anfragen an den Config-Endpunkt in einem Fünf-Sekunden-Fenster ankommen, verwandelt der Cache sie in einen PHP-Start statt 100 – das ist Arithmetik aus dem Cache-Fenster, kein gemessenes Durchsatz-Ergebnis. Der Speicher ist auf 64 MB im nginx-Container begrenzt, mit 60-Sekunden-Idle-Verdängung.
- Warum das hier besonders zählt: Der Storefront rendert auf dem Server, jede Käuferseite wird also zu mehreren API-Aufrufen zurück auf dieselbe Maschine, und jeder Kaltstart der mobilen App sind weitere 15–20 API-Aufrufe.
- Er liefert nie eine persönliche oder angemeldete Antwort aus. Jeder Authorization-Header umgeht ihn. Überhaupt jedes Cookie umgeht ihn. nginx weigert sich, eine Antwort zu speichern, die Set-Cookie trägt. Eine separate Sperrliste deckt Admin, Händler-Panel, Login, Checkout, Warenkorb, Bestellung und Zahlungs-Callbacks ab.
- Zone, Modul und Sprache sind Teil des Cache-Schlüssels, die Stores einer Stadt können also nie an eine andere Stadt ausgeliefert werden.
- Er hält den Shop am Laufen, wenn PHP es nicht tut. Wenn der PHP-Pool klemmt, liefert nginx die leicht veraltete Kopie aus und aktualisiert im Hintergrund — ein funktionierender Storefront statt einer Wand aus 502-Fehlern.
- Alles andere folgt der Hardware auch: MariaDB, opcache, Redis-Speicher und nginx-Buffer werden alle von Autotune dimensioniert.
- Stufen für die Anfragerate, bemessen für echte Netze. Enge Grenzen für Login, OTP und Passwort-Zurücksetzen; weitere für normales Browsen; separate für Suche und für Schreibvorgänge in Warenkorb und Bestellung. Die Dokumentation nennt das beim Namen — ein Flutschutz, kein DDoS-Schutz — denn Grenzen pro Adresse können nicht genau sein, wenn eine ganze Stadt sich eine Mobilfunk-IP teilt.
- „Edge“ bedeutet auf dieser Website Cloudflare, die tatsächliche Edge-Schicht. Dieser Cache ist das nicht und wird auch nicht so genannt.
Warum das zählt: Geschwindigkeit ist das eine, was ein Kunde bei jedem einzelnen Besuch spürt — und der Grund, warum diese Zahlen samt Methode veröffentlicht sind.
Optionale Bausteine
Schalten Sie sie ein, wenn der Shop sie braucht.
- Live-Bestellverfolgung über Websockets (Reverb).
- Die optionale Next.js-Kundenwebsite, deren statische Dateien als unveränderlich ausgeliefert werden.
- Nur über die mobilen Apps zu verkaufen, ohne Website, ist eine unterstützte Form.
Warum das zählt: Werkzeuge, die Sie selten brauchen, sollten im Leerlauf nichts kosten — diese starten bei Bedarf und gehen dann aus dem Weg.
Shop-Check (SixPreflight, enthalten)
Er prüft die Einstellungen in Ihrem Shop, im Unterschied zu dem Server, um den sich SixPanel kümmert.
- SixPreflight ist mitgeliefert und im Panel als Seite Shop-Check eingebunden. Es trägt etwa 134 Prüfungen, eine gewichtete Punktzahl und eine Note.
- Warum 134 und keine größere Zahl: Drei interne Quellen geben drei Antworten. Eine direkte Zählung der eindeutigen Prüfschlüssel im Code ergibt 163; die technische Übergabe verzeichnet 134–136 und weist den niedrigeren der beiden Werte an; eine ältere Seitenspezifikation sagt etwa 100. Diese Seite druckt ~134, den niedrigsten Wert, den eine aktuelle Quelle vertritt.
- Wenn es innerhalb von SixPanel läuft, ändert es absichtlich sein Verhalten: Die Konfigurationsblöcke zum Kopieren und Einfügen verschwinden für die Schichten, die dem Panel gehören, und die Einstellungen, die zum Admin-Panel Ihres eigenen Shops gehören, werden getrennt vom Server bewertet.
Warum das zählt: Der Server kann perfekt sein, während eine falsche Einstellung im Shop still Bestellungen kostet — ein zweites Paar Augen liest genau die.
Was von allein läuft
Die Automatisierung, aufgeschlüsselt
„Automatisiert“ ist ein Wort, das sich leicht drucken lässt. Hier steht jeder Job, den das Panel ohne Sie erledigt — was ihn jeweils auslöst, und was Sie sonst um Mitternacht von Hand tun würden.
- Einmal, zu Beginn
Der ganze Server, aus einem Befehl
Ein einziges Einfügen auf einem frischen Ubuntu-Server installiert den Webserver, die Datenbank, PHP, den Cache, den Queue-Worker, den Scheduler, den Websocket-Server und das Panel selbst — jeweils dimensioniert für die Maschine, auf der es landet. Sie tippen eine Domain; alles andere wird platziert, konfiguriert und gestartet.
- Vor jedem Ablauf
HTTPS, das sich selbst erneuert
Zertifikate werden automatisch ausgestellt — per DNS, wenn Cloudflare die Domain verwaltet, sie funktionieren also, bevor das Internet die Maschine überhaupt erreichen kann — und jede Erneuerung lädt den Webserver über einen Hook pro Zertifikat neu, sodass ein defektes Zertifikat nie die anderen einfrieren kann.
- Nach Ihrem Zeitplan
Backups, die wirklich laufen
Inkrementelle Backups nach dem Zeitplan, den Sie festlegen — auf denselben Server, nach S3, SFTP oder Google Drive, mit Aufbewahrungsregeln nach jedem Lauf. Datenbank, hochgeladene Dateien und Einstellungen jedes Projekts — der Code kommt aus git zurück.
- Jede Woche
Ein Restore-Test, keine Erfolgsmeldung
Einmal pro Woche stellt das Panel das neueste Backup in eine Wegwerf-Datenbank wieder her und zählt die Zeilen. Ein Backup, das sich nicht wirklich öffnen lässt, färbt die Health-Seite rot — denn eine Erfolgsmeldung ist kein Beweis.
- Alle paar Minuten
Selbstheilung für die stillen Ausfälle
Der Watchdog startet einen Dienst neu, der läuft, aber kaputt ist — der Fall, den ein gewöhnlicher Supervisor komplett übersieht, weil nichts abgestürzt ist. Jeder Neustart, den er ausführt, erscheint im Aktivitätsprotokoll samt Begründung.
- Bei Installation und Update
Tuning, dimensioniert für die Maschine
Der Buffer Pool der Datenbank, der Cache-Speicher, die Größen temporärer Tabellen und die PHP-Worker werden aus dem tatsächlichen Speicher und den Kernen der Maschine berechnet — eine Dimensionierungsleiter, vermessen über 36 Server-Konfigurationen, identisch angewendet vom Installer und vom Panel.
- Jede Nacht
Datenbank-Pflege
Ein nächtlicher Durchlauf räumt die abgelaufenen Zeilen weg, die die Anwendung selbst nie löscht, und sonntags werden die Tabellen optimiert — nur wenn der freie Plattenplatz es zulässt, und mit jedem Ergebnis geprüft statt bloß angenommen.
- Bei jedem Deploy
Vermessene Indizes, die bleiben
Ein Paket von Datenbank-Indizes — jeder einzelne an einem echten Shop mit 66,701 Bestellungen vermessen, bevor er aufgenommen wurde — wird nach jeder Codeänderung geprüft und neu angewendet. Geprüft wird, was ein Index abdeckt, nicht sein Name — ein umbenannter Index kann die Prüfung also nicht täuschen.
- Bei jedem git push
Push-to-Deploy, von Anfang bis Ende
Ein Push in Ihr Repository, und der Shop aktualisiert sich selbst: Pull, Abhängigkeiten, Datenbank-Migrationen, der Config-Cache nur dort neu gebaut, wo das für genau Ihren Code als sicher vermessen ist, PHP neu geladen, ohne einen Request zu verlieren. Ein Rollback-Button hält das vorherige Release bereit.
- Fortlaufend
Health-Checks, die die Lösung benennen
Über dreißig Checks laufen nach eigenen Zeitplänen — Dienste, Platte, Zertifikate, DNS, Cloudflare, die eigenen Dateien des Panels gegen das Release, das sie ausgeliefert hat. Eine fehlschlagende Zeile benennt die exakte Lösung, nicht nur das Problem.
- Wenn Sie gebraucht werden
E-Mail, die Ihr Postfach respektiert
Höchstens eine E-Mail pro Problem alle sechs Stunden, mit einem farbigen Urteil, das schon in der Postfach-Vorschau lesbar ist — und einem grünen „behoben“, wenn das Problem verschwindet, sodass Stille nie interpretiert werden muss.
- Auf Knopfdruck
Updates per Knopfdruck, signaturgeprüft
Ein Knopf holt das Release, prüft seine Signatur gegen den auf Ihrem Server gepinnten Schlüssel — ein ausgetauschter Download-Host kann Ihre Maschine nicht umschlüsseln — wendet es an und startet die Dienste in einer vermessenen Reihenfolge neu, bei der der Shop weiter ausliefert.
Das Muster hinter allem: Das Panel erledigt die Arbeit, schreibt auf, was es getan hat, und prüft sein eigenes Ergebnis — und was es nicht verifizieren kann, meldet es, statt es zu behaupten.
Unter der Haube
Fortgeschrittene Technik, die von selbst läuft
Nichts davon ist ein Häkchen auf einer Featureliste. Jeder Punkt ist echte Maschinerie mit gemessenem Verhalten, harten Sicherheitsregeln und einem Bericht, den Sie lesen können.
Selbstheilender Supervisor
Eine 60-Sekunden-Schleife repariert, was Live-Shops wirklich lahmlegt: eine hängende Queue, ein abgelaufenes Zertifikat, vergessener Wartungsmodus. Begrenzt durch harte Regeln — sie startet nie, was Sie gestoppt haben, und handelt nie während eines Deploys oder Backups.
Inkrementelle, verschlüsselte Backups
Auf restic gebaut: Jeder Lauf speichert nur, was seit dem letzten neu oder geändert ist — dedupliziert und verschlüsselt. Tägliche Backups bleiben schnell und klein, und jeder Snapshot lässt sich vollständig wiederherstellen. Ziele: lokale Platte, S3, SFTP, Google Drive.
Backups bewiesen, nicht vermutet
Ein grüner Backup-Job ist kein Beweis. Eine geplante Prüfung öffnet den neuesten Snapshot und kontrolliert, ob Ihr Datenbank-Dump wirklich darin liegt — die ehrliche Antwort auf „Kann ich wiederherstellen?“ kommt vom Artefakt, nicht vom Exit-Code.
Automatisch auf Ihren Server abgestimmt
Eine gemessene Dimensionierungsleiter berechnet Datenbank-Bufferpool, Redis-Speicher und PHP-Worker aus RAM und CPU Ihrer Maschine — bei der Installation und erneut bei jeder Größenänderung. Installer und Panel teilen eine einzige Definition, gesichert durch ein Build-Gate.
Ein nachweislich sicherer Micro-Cache
Heiße API-Endpunkte antworten aus dem nginx-Cache — gemessen von 16,9 ms auf 0,6 ms — aber nur Endpunkte, die nachweislich aufruferunabhängig sind, kommen hinein: ein statisches Gate liest die Handler der App, und eine Live-Probe mit drei Armen bestätigt, dass kein Kunde je Daten eines anderen sieht.
Jedes Projekt vollständig isoliert
Jeder Shop bekommt einen eigenen Unix-Benutzer, einen eigenen PHP-FPM-Pool und eine eigene passwortgeschützte Redis-Instanz; seine Worker laufen in einer systemd-Sandbox mit schreibgeschütztem System und ohne Rechteausweitung. Ein kompromittiertes Projekt kann kein anderes lesen.
Kryptografisch signierte Updates
Jedes Release trägt ein ed25519-signiertes Manifest mit Ablaufdatum. Das Panel weist alles ab, was unsigniert, veraltet oder mit dem falschen Schlüssel signiert ist — und ein rotierter Schlüssel muss sich erst am Release beweisen, bevor ihm vertraut wird.
Es liest Ihre App, bevor es handelt
Das Panel behauptet nichts blind. Config-Caching wird entschieden, indem der Code Ihres eigenen 6amMart gelesen wird — ein Build, der Einstellungen zur Laufzeit liest, geht nie still kaputt. Unberührter CodeCanyon-Code und der optimierte Build bekommen beide die richtige Antwort.
Selbstheilung, inkrementelle Backups, signierte Updates — Sie konfigurieren nichts davon. So ist das Panel einfach gebaut.
Warum es sich leicht anfühlt
Einfach ist eine Designentscheidung, kein Anstrich
Nichts davon ist ein vereinfachter Modus, der die echten Bedienelemente versteckt. Es sind die echten Bedienelemente, so angeordnet, dass der nächste Schritt immer offensichtlich ist.
Einmal einfügen, keine Voraussetzungen
Kein Docker zu lernen, keine Compose-Dateien, keine SSH-Folklore. Der Stack besteht aus Ubuntus eigenen Paketen, überwacht von systemd, und ein Befehl legt alles davon an.
Ein Assistent, der seine Antworten selbst vorschlägt
Sechs Schritte — Grundlagen, Passwort, Domain, HTTPS, Anwendung, Backups. Jeder Schritt schlägt die vernünftige Antwort vor; die Einrichtung besteht überwiegend aus Bestätigen, nicht aus Entscheiden.
Eine Domain tippen, den ganzen Plan bekommen
Aus einer einzigen Domain plant das Panel die Hosts für Dashboard, Storefront und Websocket, die anzulegenden DNS-Einträge und welche davon Cloudflare proxyen soll. Namen, die HTTPS still kaputt machen würden, werden abgelehnt — samt der Schreibweise, die funktioniert.
Probleme kommen mit angehängter Lösung an
Kein nacktes „fehlgeschlagen“. Eine rote Zeile nennt Ihnen die genaue Einstellung, Datei oder den Button, der das Problem löst — der Unterschied zwischen einem To-do und einem Rätsel.
Jede Aktion ist ein Job, dem Sie zusehen können
Installationen, Deploys, Backups und Korrekturen laufen als Jobs mit Live-Logs. Buttons zeigen einen Spinner, während sie arbeiten, und ein Job weigert sich, Erfolg zu melden, solange seine eigene Nachprüfung nicht besteht.
Das Handbuch wohnt im Panel
Jeder Hilfe-Link landet auf der Seite zu genau dem, was Sie gerade vor sich haben. Dasselbe Handbuch liegt dem Download bei und ist auf dieser Website veröffentlicht.
Eine Kommandozeile für den schlechten Tag
Ein sixpanel-Befehl auf dem Server spiegelt das Panel — mit Manpage und Shell-Completion — für den Tag, an dem der Browser keine Option ist.
Es spricht Ihre Sprache
Acht Sprachen. Kommen Sie von dieser Website, öffnet sich das Panel in der Sprache, in der Sie gelesen haben; folgen Sie einem Link zurück, macht die Website dasselbe.
Die drei Dinge, die sonst niemand macht
Drei Aussagen, jede mit dem Grund, warum sie wahr ist, nicht mit einem Adjektiv
Wir haben uns gegen einen vollständig abgestimmten Konkurrenten gemessen und veröffentlicht, woher der Vorsprung kommt
Jeder kann einen Benchmark veröffentlichen, den er gewonnen hat. Der Test, der sich zu fahren lohnt, ist der, bei dem die Gegenseite ordentlich eingerichtet ist — also wurde die aaPanel-Maschine zuerst abgestimmt: Cache für kompilierten Code verdoppelt, Datenbank-Buffer-Pool viereinhalbmal so groß, Worker von überbuchten 50 auf bemessene 14 korrigiert. Sein PHP 8.4 und sein JIT-Compiler blieben bewusst eingeschaltet, denn das sind seine Vorteile.
Der Abstand schloss sich nicht. 1,65× / 1,80× gegen die Maschine im Auslieferungszustand; 1,76× / 1,82× gegen die abgestimmte. Er verschob sich leicht in die andere Richtung.
Dann wurde der Unterschied Variable für Variable auseinandergenommen. Etwa 60 % davon sind eine einzige PHP-Verzeichnisbeschränkung, etwa 8 % sind der falsche JIT-Compiler-Modus, und die PHP-Version ist exakt nichts wert. Etwa 32 % sind weiterhin unerklärt und werden als unerklärt veröffentlicht, statt uns gutgeschrieben zu werden.
Warum das zählt: Ein Verhältnis ohne Ursache dahinter ist eine Marketingzahl. Dieses hier hat für zwei Drittel seiner selbst eine gemessene Ursache und für den Rest ein Eingeständnis.
Wir haben drei Betriebssysteme gemessen, ein Unentschieden bekommen und das Unentschieden veröffentlicht
Drei Server von einem Anbieter, zusammen bestellt, identisch außer dem Betriebssystem. Gleiche Container, gleiche Optimierung, gleiche Daten – eine echte Shop-Datenbank mit 66.701 Bestellungen.
Sie lagen gleichauf. Der Abstand zwischen den drei Maschinen (3.5 %) war kleiner als der Abstand, den eine Maschine zu sich selbst hatte, über zwei Durchläufe ihrer eigenen Konfiguration (8.6 %).
Also wurde die Empfehlung danach entschieden, wie lange jedes System weiter Sicherheitsupdates bekommt, und nicht nach Geschwindigkeit. Und der Bericht hat seine eigenen schmeichelhaftesten Zeilen verworfen, weil sie rechnerisch unmöglich waren.
Warum das zählt: Die Bereitschaft, ein negatives Ergebnis zu veröffentlichen, ist der Beleg dafür, dass die Methode echt ist. Ein gewonnenes Benchmark kann jeder veröffentlichen.
Caching und Grenzen, zugeschnitten auf die Anfragemuster von 6amMart
nginx-Micro-Caching steht jedem offen. Spezifisch ist hier alles drumherum, und nichts davon kann jemand schreiben, der diese Anwendung nicht kennt:
- Die Allowlist genau der öffentlichen Endpunkte, die zwischengespeichert werden dürfen, abgeglichen auf der rohen URI, standardmäßig verboten.
- Zone, Modul und Sprache im Cache-Schlüssel, weil 6amMart aus derselben URL verschiedenen Städten verschiedene Stores ausliefert.
- Fünf Umgehungsregeln, die eine personalisierte Antwort unmöglich zwischenspeicherbar machen.
- Stufen für die Anfragerate, die Login und OTP vom Browsen, von der Suche und von Warenkorb-Schreibvorgängen trennen.
- Zeitlimits, die bewusst aufeinander abgestimmt sind — PHP 120 s, nginx-Lesen 120 s, Worker-Abbruch 130 s — weil 6amMart Excel-Exporte, Massenimporte und schwere Store-Berichte innerhalb der Web-Anfrage ausführt statt im Hintergrund.
Warum das zählt: Eine nicht authentifizierte Suchflut konnte früher den Cache-Server füllen und anfangen, Sitzungen zu verdrängen, was angemeldete Käufer stillschweigend abmeldete. Es brauchte etwa 278 Anfragen, rund 67 Sekunden über eine Verbindung, auf einer Testmaschine mit zwei Projekten und 8 GB. Das wurde gemessen, eingegrenzt und auf derselben Maschine erneut gemessen — über die drei Fluten, die die Belegdatei auflistet, null Verdrängungen, die Sitzung jedes Mal am Leben.
SixPanel im Vergleich
SixPanel im Vergleich mit aaPanel, CloudPanel und Handarbeit
Das ist ein Vergleich für eine Aufgabe: einen 6amMart-Shop betreiben. Es ist kein Vergleich dieser Panels im Allgemeinen, und es wäre unehrlich, ihn als solchen darzustellen.
Was wir über die zwei Wettbewerber haben, exakt formuliert
Die Tabelle hat 14 Zeilen und zwei Wettbewerber-Spalten, also 28 Wettbewerber-Zellen. Vier dieser 28 sagen etwas anderes als „das haben wir nicht getestet“, und hier ist jede einzelne davon:
- Eine Zelle hält fest, was wir bei einem Produkt eines Wettbewerbers beobachtet haben. aaPanel setzt das Document Root stillschweigend zurück, sobald irgendeine Website-Einstellung gespeichert wird — auf einer laufenden Installation festgestellt. Das ist die Zeile Document Root, Spalte aaPanel.
- Zwei Zellen beruhen auf dem Verhalten eines Dritten, das wir überprüft haben, nicht auf einem Test der Panels. Weder das Archiv von Ubuntu 26.04 noch das von Debian 13 führt MariaDB 10.11, und beide Panels installieren die Datenbank aus den Paketen des Hosts — auf diesen Releases können sie diese Version also nicht liefern. Die native Laufzeitumgebung von SixPanel nimmt stattdessen 11.8 aus demselben Archiv, und SixPanel Docker bringt 10.11 in seinem Image mit. Das ist die MariaDB-10.11-Zeile, beide Wettbewerber-Spalten.
- Eine Zelle berichtet unsere eigene Messung eines Wettbewerbers. aaPanel wurde auf identischer Hardware mit den Daten desselben Shops installiert, von uns zuerst abgestimmt und dann gemessen — das ist die Zeile Geschwindigkeit, Spalte aaPanel, und die vollständige Methode steht oben. CloudPanel wurde nicht gemessen, und genau das sagt seine Zelle.
- Die restlichen 24 Wettbewerber-Zellen sagen alle „von uns nicht getestet“. Das ist der wörtliche Wortlaut in jeder einzelnen davon — gezählt, nicht angenommen.
Wir behaupten nichts darüber, wie alt einer der beiden Wettbewerber ist. Keine Quelle in diesem Bestand belegt das Alter eines der beiden Produkte, deshalb erscheint keine solche Behauptung. Was die Zeile Erfolgsbilanz ehrlich sagen kann, ist nur das, was wir über unser eigenes Alter wissen.
Wir haben SixPanel nie gegen ein anderes Panel gemessen, und diese Seite macht keinen Geschwindigkeit-Vergleich zwischen ihnen.
| Für die Aufgabe, 6amMart zu betreiben | SixPanel | aaPanel | CloudPanel | Einfacher Server, von Hand |
|---|---|---|---|---|
| Wofür es gebaut ist | Nur eine einzige Anwendung — 6amMart | Allgemeines Webhosting — von uns nicht getestet; lesen Sie die Funktionsliste des Anbieters | Allgemeines Webhosting — von uns nicht getestet; lesen Sie die Funktionsliste des Anbieters | Was immer Sie bauen |
| Geschwindigkeit, gleiche Hardware und gleicher Shop | Gemessen: 1,76× schneller als ein vollständig abgestimmtes aaPanel bei einer Anfrage, 1,82× bei vier gleichzeitig, über die Endpunkte, die auf beiden PHP erreichen | Der Vergleich oben. Wir haben es installiert, abgestimmt und sein PHP 8.4 und sein JIT eingeschaltet gelassen | Von uns nicht getestet — es wird keine Geschwindigkeitsbehauptung darüber aufgestellt | Was immer Ihr Techniker erreicht |
| MariaDB 10.11 auf Ubuntu 26.04 / Debian 13 | Mit der Docker-Laufzeitumgebung ja — das Image ist auf 10.11 festgelegt, was der Host auch betreibt. Die native Laufzeitumgebung nimmt stattdessen MariaDB 11.8 aus den eigenen Archiven dieser Releases, und am selben Shop gegen 10.11 gemessen ist das ein Gleichstand. | Nicht verfügbar. Keines der beiden Releases führt 10.11 in seinem Archiv, und dieses Panel installiert aus Host-Paketen | Nicht verfügbar — gleicher Grund | Nur, wenn Sie selbst Container betreiben |
| Andere Websites, Mail, DNS, FTP auf derselben Maschine | Nein. Der Installer verweigert einen Server, auf dem bereits aaPanel, CloudPanel, cPanel oder Plesk läuft oder auf dem etwas auf den Ports 80/443 liegt | Hier gewinnen sie. Dafür sind allgemeine Panels da — von uns nicht getestet; fragen Sie beim Anbieter nach | Hier gewinnen sie — von uns nicht getestet; fragen Sie beim Anbieter nach | Möglich, und ganz Ihr Problem |
| Benutzer, Rollen, Teams | Nein. Ein Admin-Konto. Dazu temporäre Zugänge und ein schreibgeschützter Demo-Zugang | Hier gewinnen sie. Von uns nicht getestet; fragen Sie beim Anbieter nach | Hier gewinnen sie. Von uns nicht getestet; fragen Sie beim Anbieter nach | Was immer Sie konfigurieren |
| Ab Werk auf diese Anwendung abgestimmt | Autotune schreibt PHP-Worker, Datenbank-Buffer-Pool, Cache-Speicher, temporäre Tabellen, Puffer und das Redo-Log anhand der echten Maschine, 1 Kern / 2 GB → 16 Kerne / 32 GB — und beide Stellen, die das berechnen, werden bei jedem Build gegeneinander geprüft | Von uns nicht getestet; fragen Sie beim Anbieter nach | Von uns nicht getestet; fragen Sie beim Anbieter nach | Was immer Sie wissen |
| Micro-Cache in 6amMart-Form | Eingebaut: Allowlist, Zone/Modul/Sprache im Schlüssel, 5 Umgehungen, Ausliefern der veralteten Kopie, wenn PHP klemmt | nginx-Micro-Caching gibt es überall — die 6amMart-spezifischen Regeln muss jemand schreiben. Von uns nicht getestet | Genauso. Von uns nicht getestet | Genauso |
| Backups | restic, geplant, Aufbewahrung, vier Ziele, wöchentlicher automatischer Wiederherstellungstest | Von uns nicht getestet — vergleichen Sie gezielt den automatischen Wiederherstellungstest | Von uns nicht getestet — genauso | Was immer Sie skripten |
| Kostenloses HTTPS | Ja, mit automatischer Erneuerung und Cloudflare-bewusster Ausstellung | Von uns nicht getestet; fragen Sie beim Anbieter nach | Von uns nicht getestet; fragen Sie beim Anbieter nach | certbot, von Ihnen |
| Deploys | Push nach git; Historie und Rollback mit den letzten 30 Deploys; weigert sich, Ihre eigenen Änderungen zu überschreiben | Von uns nicht getestet; fragen Sie beim Anbieter nach | Von uns nicht getestet; fragen Sie beim Anbieter nach | Was immer Sie skripten |
| Das Document Root bleibt, wo Sie es hingelegt haben | Ja | Auf einer Live-Installation festgehalten: aaPanel setzt das Document Root still zurück, sobald irgendeine Site-Einstellung gespeichert wird | Von uns nicht getestet | Ihre Sache, das richtig zu machen |
| Erfahrungsnachweis | SixPanel steht bei seinem aktuellen Release, und es ist neu. Wir können Ihnen keine Jahre zeigen, die wir nicht hatten | Von uns nicht getestet; prüfen Sie, wie lange der Anbieter schon ausliefert | Von uns nicht getestet; prüfen Sie, wie lange der Anbieter schon ausliefert | Linux ist über 30 Jahre alt |
| Lesbarer Quellcode auf Ihrem Server | Hier gewinnen sie möglicherweise. Das Panel-Backend wird als V8-Bytecode ausgeliefert, die lesbaren Quellen sind entfernt. Wir nennen das Abschreckung, nicht Sicherheit | Von uns nicht getestet; fragen Sie beim Anbieter nach | Von uns nicht getestet; fragen Sie beim Anbieter nach | Alles ist lesbar |
| Wer es repariert, wenn es kaputtgeht | Die Zustandsseite benennt die Behebung; Support-Bundle mit einem Befehl | Von uns nicht getestet; prüfen Sie, welchen Support der Anbieter bietet | Von uns nicht getestet; prüfen Sie, welchen Support der Anbieter bietet | Sie |
Es gibt keine Preiszeile, weil es keinen Preis gibt. SixPanel ist kostenlos, auf CodeCanyon veröffentlicht, und der Installationsbefehl ist derselbe öffentliche Befehl für alle — kein Schlüssel einzugeben, kein Code einzufügen, keine Anmeldung. Die erste Installation und Einrichtung ist ebenfalls kostenlos. Updates kommen über CodeCanyon, und das Panel kann sich zusätzlich selbst aktualisieren.
Wann aaPanel oder CloudPanel die bessere Wahl ist
Fünf echte Fälle. Wenn einer davon auf Sie zutrifft, kaufen Sie das allgemeine Panel und nicht dieses:
- 1Sie wollen mehr als eine Website auf diesem Server. SixPanel nimmt die ganze Maschine und weigert sich, sie zu teilen.
- 2Sie brauchen Mail-, DNS- oder FTP-Hosting auf derselben Maschine. SixPanel macht das überhaupt nicht.
- 3Sie brauchen mehrere Mitarbeiterkonten mit unterschiedlichen Rechten. SixPanel hat ein Admin-Konto und keine Rollen.
- 4Sie betreiben etwas anderes als 6amMart. Jeder Vorteil auf dieser Seite kommt daher, eine Anwendung gut zu kennen.
- 5Eine lange Erfolgsbilanz im Produktivbetrieb ist Ihr erstes Kriterium. SixPanel ist neu. Das ist ein fairer Grund zu warten.
Und einer für die Handarbeit: Wenn Sie einen Systemadministrator haben, ist ein von Hand gebauter Server nicht schlechter. Eine kompetente Fachkraft kann MariaDB abstimmen, Cache-Regeln schreiben und Backups skripten. Was SixPanel beseitigt, ist die Notwendigkeit, diese Person zu haben, und die Notwendigkeit, daran zu denken, all das nachzuprüfen.
Betriebssystem
Welches Betriebssystem installieren, und warum der Grund die Support-Laufzeit ist und nicht die Geschwindigkeit
Beide Laufzeitumgebungen empfehlen Ubuntu 26.04 LTS. Ubuntu 24.04 LTS und Debian 13 sind die beiden anderen unterstützten Releases.
Nicht weil es schneller wäre. Sechs Achsen wurden auf identischer Hardware gemessen — Betriebssystem, PHP, MariaDB, nginx, Redis und Kernel — und kein Versionswechsel ergab einen berichtbaren Unterschied. Zwei bytegleiche Maschinen wichen in 20 von 20 Zeilen um 11,6 % voneinander ab, das Grundrauschen ist also größer als jeder gefundene Effekt.
Die native Laufzeitumgebung nimmt PHP, MariaDB, nginx und Redis aus dem eigenen Distributionsarchiv des Releases, und alle drei unterstützten Releases bringen einen funktionierenden Satz mit: Ubuntu 26.04 liefert PHP 8.5 und MariaDB 11.8, Debian 13 liefert 8.4 und 11.8, Ubuntu 24.04 liefert 8.3 und 10.11. Bei gleicher Geschwindigkeit bleibt als einzige Achse, wie lange Sicherheitsupdates weiter ankommen — und 26.04 wird bis April 2031 mit Patches versorgt.
SixPreflight empfiehlt Ubuntu 26.04 LTS, aus demselben Grund wie die native Laufzeitumgebung.
| Wahl | SixPanel | SixPreflight (keine Container) |
|---|---|---|
| Empfohlen | Ubuntu 26.04 LTS, beide Laufzeitumgebungen | Ubuntu 26.04 LTS |
| Ebenfalls unterstützt | Beide Laufzeitumgebungen: Ubuntu 24.04 LTS und Debian 13. Die Docker-Laufzeitumgebung installiert außerdem auf Debian 12, das die native namentlich ablehnt | Ubuntu 24.04 LTS, Debian 13 |
| Warum | Die Geschwindigkeit ist über alle drei gleich, entscheidend ist daher die Support-Laufzeit: 26.04 wird bis April 2031 mit Patches versorgt. Die native Laufzeitumgebung nimmt PHP und MariaDB aus dem Release, das Sie wählen. | Derselbe Grund: die Datenbank kommt aus dem Betriebssystem, jedes unterstützte Release bringt eine funktionierende Version mit, und was zu entscheiden bleibt, ist die Laufzeit. |
Unterstützt ist nicht dasselbe wie gemessen. Die native Laufzeitumgebung unterstützt drei Releases, und alle drei wurden gemessen — Ubuntu 24.04, Ubuntu 26.04 und Debian 13. Debian 12 wird namentlich abgelehnt: sein kostenloser Sicherheitssupport endete im Juli 2026. Die Docker-Laufzeitumgebung installiert weiterhin darauf, und Sie sollten dort dennoch keinen neuen Shop starten, denn Kernel, glibc, Docker und OpenSSH kommen aus dem Archiv des Hosts, ganz gleich was in einem Container läuft.
Warum jetzt alles in dieselbe Richtung zeigt
Eine frühere Datenbank-Engine-Runde stellte MariaDB 10.11 an die erste Stelle, und eine Zeit lang spaltete das die Empfehlung, weil nur Ubuntu 24.04 diese Version mitbrachte. Auf identischen Maschinen mit demselben Shop von 66.701 Bestellungen nachgemessen, ist diese Spaltung verschwunden.
MariaDB 11.8 gegen 10.11 ist über die gesamte Anwendung ein Gleichstand. Die Messwerte, die etwas anderes nahelegten, wurden verworfen, weil die Messumgebung einen verschlüsselten Handshake statt der Datenbank gemessen hat.
Die eine Stelle, an der 11.8 langsamer aussah, verrichtet überhaupt keine Arbeit.
Es war SELECT 1 — eine Abfrage, die keine Arbeit verrichtet, und die auf einem Arm 12 ms gegenüber 29 ms und 37 ms auf den beiden anderen ergab. Eine Untergrenze, die sich verdreifacht, ist keine Abfrageausführung: MariaDB 11.8 verhandelt TLS auf dem Unix-Socket und 10.11 nicht, die Messung erfasste also einen Handshake. Direkt gemessen: 24 ms pro Client-Aufruf auf 11.8 gegenüber 6 ms mit abgeschaltetem TLS und 10 ms auf 10.11. Ein Shop zahlt das nie — mysqlnd verhandelt auf einem Socket kein TLS, 0,12 bis 0,21 ms pro Verbindung.
Die alte Zahl „11.x ist 2,7× langsamer“ betraf nie 11.8.
Sie kam von einer einzigen Report-Abfrage auf dem Kostenmodell von MariaDB 11.0 und wird als Aussage über die gesamte Anwendung zurückgezogen. Nichts spricht also mehr dafür, ein älteres Release festzuschreiben: die native Laufzeitumgebung nimmt 11.8 aus den eigenen Archiven von Ubuntu 26.04 und Debian 13 und 10.11 aus dem von Ubuntu 24.04.
Eine Antwort, und keine Geschwindigkeitsantwort. Nehmen Sie das Release, das am längsten weiter Patches bekommt.
Wie gemessen wurde
- Gemessen am 15. August 2026, auf dem an diesem Tag aktuellen Stack-Build. SixPanel wurde seitdem weiter ausgeliefert, und nichts in diesem Abschnitt wurde auf dem aktuellen Release erneut ausgeführt. Das Datum ist es, was die Messung festhält.
- Drei Server vom selben Anbieter, zusammen bestellt, identisch bis auf das Betriebssystem — also jedes Release, das die native Laufzeitumgebung unterstützt.
- Derselbe Prozessor auf allen dreien: 2 × AMD EPYC 7713, 2 Kerne. RAM 3,915 / 3,910 / 3,921 MB. Je 79 GB Festplatte.
- Die Software war über alle drei bytegleich — MariaDB 10.11, derselbe PHP-Build, derselbe Webserver. Diese Runde lief auf der Container-Laufzeitumgebung, und genau das machte es möglich: sie hält den Stack still, sodass das Betriebssystem das Einzige ist, was sich ändert.
- Echte Daten, kein Testbestand. Die Datenbank eines echten Produktiv-Shops: ein 410 MB großer Dump, der zu 515 MB wiederhergestellt wird, 66,701 Bestellungen, dazu 894 MB echte Uploads.
- Eine frische SixPanel-Installation auf jeder Maschine, über den normalen Kundenweg. Keine Abstimmung von Hand — Autotune hat jeden Wert gewählt, und es wählte auf allen dreien dieselben Werte.
- Warmlaufen, dann messen. Proben aus dem Warmlaufen verworfen; berichtet wird der zweite Durchlauf.
- Perzentile, keine Durchschnitte.
Anfragen pro Sekunde — der Such-Endpunkt, 20 Personen gleichzeitig, 30 Sekunden
Das ist die Zahl, der man trauen kann.
| Betriebssystem | Abgeschlossene Anfragen | Anfragen pro Sekunde |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
Abstand zwischen den dreien: 3.5 %. Die Ubuntu 26.04-Maschine wich über zwei Durchläufe ihrer eigenen identischen Konfiguration um 8.6 % von sich selbst ab — 49.6, dann 53.9.
Ein Hinweis zur Rechnung, denn eine Seite, die es sich zur Tugend macht, unmögliche Zahlen zu entlarven, kann keine Prozentwerte drucken, die eine Leserin aus den danebenstehenden Zahlen nicht nachvollziehen kann. Der interne Bericht druckt den Abstand als 3,7 % und die Eigenabweichung als 8,7 %. Beide sind aufgerundet, deshalb druckt diese Seite stattdessen die abgeschnittene Neuberechnung: (1.616 − 1.561) ÷ 1.561 = 3,5234 % → 3,5 % und (53,9 − 49,6) ÷ 49,6 = 8,6694 % → 8,6 %. Der Befund bleibt unverändert — der Abstand zwischen den Maschinen ist weiterhin kleiner als die Abweichung einer Maschine von sich selbst. Die Spalte pro Sekunde ist die eigene Rundung der Quelle auf 1 Nachkommastelle: 1.616 ÷ 30 = 53,8666 und 1.595 ÷ 30 = 53,1666 ergeben abgeschnitten 53,8 und 53,1, und nur 52,0 ist bereits abgeschnitten. Die Spalte bleibt so, wie die Quelle sie druckt, damit sich die beiden Dateien nebeneinanderlegen lassen; die Prozentwerte sind die dieser Seite, und sie sind die Zahlen, die zitiert werden.
Lesen Sie den ganzen Block als „etwa 53 Anfragen pro Sekunde auf 2 Kernen, am Such-Endpunkt, bei 20 gleichzeitigen Nutzern, über 30 Sekunden“ — und nicht mehr. Jede dieser Einschränkungen reist mit der Zahl mit, wo immer sie auf dieser Seite wiederholt wird.
Latenz im Leerlauf — erfasst und bewusst nicht gedruckt
Die serielle Latenz wurde auf jedem Zweig gemessen: Storefront-Startseite, Admin-Login und die API-Endpunkte, eine Anfrage nach der anderen auf einer unbelasteten Maschine.
Diese Werte pro Zelle stehen nicht auf dieser Seite, und das ist der Grund. Der interne Bericht verbietet jede Angabe „X % schneller“, die aus diesen Tabellen stammt. Eine dreispaltige Tabelle mit Millisekundenwerten ist genau diese Angabe, nur eine Subtraktion entfernt: Jede Leserin mit einem Taschenrechner und jede KI-Zusammenfassung ohne einen wird den Vergleich anstellen, den der Bericht ausschließt. Die Tabelle zu drucken und „aber vergleichen Sie diese nicht“ hinzuzufügen, funktioniert nicht, denn ein Zitat behält die Zahlen und lässt den Vorbehalt weg.
- Die drei Maschinen lagen bei der Zahl gleichauf, auf die es ankommt, und eine Maschine wich stärker von sich selbst ab, als die drei voneinander abwichen.
- Auf der seriellen Leerlauf-Latenz eines Zweigs zeigte sich ein kleiner, gleichbleibender Unterschied. Er ist im internen Bericht erfasst und wird bewusst nicht behauptet, aus drei dort genannten Gründen: Er ist eher ein etwa fester als ein anteiliger Aufwand, was für ein Warten und nicht für Arbeit spricht; er verschwindet unter Last vollständig, also genau dort, wo er zählen würde; und mit einer Maschine pro Betriebssystem lassen sich die Kernel-Version und dieser bestimmte physische Host nicht voneinander trennen.
- Die Perzentil-Zeilen unter Last von zwei Zweigen wurden vollständig verworfen.
Zeilen wurden verworfen, und dass sie verworfen wurden, ist wichtig
Die Perzentile unter Last des Ubuntu 26.04-Zweigs sind rechnerisch unmöglich. Zwanzig Worker über 30 Sekunden sind 600 Worker-Sekunden, 1,616 abgeschlossene Anfragen haben also einen arithmetischen Mittelwert von 371 ms. Dieser Zweig meldete sowohl seinen p50 als auch seinen p99 unterhalb dieses Mittelwerts — ein p99, der schneller ist als die durchschnittliche Anfrage. Beide Durchläufe zeigen es, es ist also systematisch für diese Maschine und keine Ausreißerprobe.
Für bare Münze genommen würden diese Zeilen diese Maschine unter Last dramatisch besser aussehen lassen. Ist sie nicht — ihre Zahl abgeschlossener Anfragen liegt innerhalb von 3.5 % der anderen. Die beiden Perzentilwerte selbst werden auf dieser Seite nicht gedruckt: Der interne Bericht schließt die Latenzwerte unter Last von Ubuntu 26.04 als Gruppe aus. Die Rechnung oben reicht, um zu zeigen, warum sie verworfen wurden, und das Verwerfen ist der Punkt.
Der Testrahmen trägt jetzt eine Gegenprüfung auf Basis von Little's Law, sodass eine verdorbene Probe sich selbst meldet, statt zur Schlagzeile zu werden.
Die Datenbank, auf dem echten 515 MB großen Datenbestand
Lesen Sie den Vorbehalt vor den Zahlen. Jeder Unterschied zwischen Maschinen in dieser Tabelle liegt innerhalb der eigenen Schwankung von Ubuntu 24.04 zwischen Durchläufen von 85–125 ms bei denselben drei Abfragen. Die Spalten sind keine Rangliste; sie sind drei Proben einer Zahl. Der eigentliche Befund ist die letzte Zeile.
| Abfrage | Ubuntu 24.04 | Ubuntu 26.04 | Debian 13 |
|---|---|---|---|
| Alle Bestellungen zählen | 120 ms | 96 ms | 106 ms |
| Alle Bestellpositionen zählen | 102 ms | 102 ms | 110 ms |
| Bestellungen mit Bestellpositionen verknüpft, 50 Zeilen | 85 ms | 80 ms | 81 ms |
| Trefferrate des Buffer-Pools | 99.991 % | 99.989 % | 99.987 % |
Die letzte Zeile ist der Befund: Eine 515 MB große Datenbank in einem 1,024 MB großen Buffer-Pool bedeutet, dass etwa 99.99 % der Lesezugriffe aus dem Arbeitsspeicher beantwortet werden und diese Last die Festplatte nicht mehr liest, sobald sie warm ist.
Wie lange die Installation gedauert hat
| Betriebssystem | Unbeaufsichtigte Installation | Probleme |
|---|---|---|
| Ubuntu 24.04 | 303 s | keine |
| Ubuntu 26.04 | 281 s | keine |
| Debian 13 | 273 s | git fehlt im minimalen Image, was das Klonen komplett scheitern ließ — hier gefunden, hier behoben |
303 s sind fünf Minuten und drei Sekunden, deshalb sagt diese Seite „etwa fünf Minuten“ und nicht „unter fünf Minuten“.
Warum April 2031 den Ausschlag gab
Bei gleicher Geschwindigkeit ist der entscheidende Faktor, wie lange jedes System weiter Sicherheitsupdates bekommt. Ein Betriebssystem, dessen Support ausläuft, ist das eine Ereignis, das einen vollständigen Neuaufbau des Servers erzwingt — und den Server neu aufzubauen ist das Einzige, was SixPanel für seinen Besitzer nicht erledigen kann.
| Betriebssystem | Kostenloser Sicherheitssupport bis | Restlaufzeit ab August 2026 |
|---|---|---|
| Ubuntu 26.04 LTS | April 2031 | 4 Jahre 8 Monate |
| Ubuntu 24.04 LTS | Mai 2029 | 2 Jahre 8 Monate |
| Debian 13 | August 2028, danach Community-LTS | etwa 1 Jahr 10 Monate |
| Debian 12 — nur Container-Laufzeitumgebung, nicht empfohlen | endete im Juli 2026 | abgelaufen |
MariaDB 10.11 selbst läuft etwa im Februar 2028 aus. In der Container-Laufzeitumgebung ist das eine Image-Festlegung und eine eigene Entscheidung; in der nativen betrifft es nur Ubuntu 24.04, denn 26.04 und Debian 13 nehmen 11.8 aus ihren eigenen Archiven. So oder so ist es der Grund, warum das Host-Betriebssystem das sein sollte, das am seltensten ersetzt werden muss.
Wenn Ihr Hoster Ubuntu 26.04 noch nicht anbietet, nehmen Sie Ubuntu 24.04. Es wird voll unterstützt und Sie verlieren nichts, was Sie messen könnten.
Was gesagt werden darf, und diese Seite sagt es
- SixPanel betreibt den vollständigen 6amMart-Stack auf Ubuntu 26.04, Ubuntu 24.04 und Debian 13 — den drei gemessenen — überprüft mit echten Produktivdaten.
- Jedes unterstützte Release bringt eine funktionierende Datenbank in seinem eigenen Archiv mit — MariaDB 11.8 auf Ubuntu 26.04 und Debian 13, 10.11 auf Ubuntu 24.04 — und am selben Shop gemessen ist 11.8 gegen 10.11 ein Gleichstand. Die Container-Laufzeitumgebung legt 10.11 in ihrem Image fest, wenn Sie genau diese Version möchten.
- Ubuntu 26.04 LTS wird empfohlen und bekommt bis April 2031 Sicherheitsupdates.
- Ein Server mit 2 Kernen / 4 GB bediente etwa 53 Anfragen pro Sekunde am Such-Endpunkt, bei 20 gleichzeitigen Nutzern, über 30 Sekunden, auf einem Katalog in Live-Größe mit 66,701 Bestellungen, wobei die Datenbank 99.99 % der Lesezugriffe aus dem Arbeitsspeicher beantwortete.
- Eine frische Installation läuft unbeaufsichtigt in etwa fünf Minuten durch (273–303 s gemessen; die langsamste der drei, 303 s, ist der Wert, gegen den der Text geschrieben ist).
Was die Messungen nicht hergeben, und diese Seite sagt es nicht
- Dass eines dieser Betriebssysteme schneller wäre als ein anderes. Die gemessenen Unterschiede sind kleiner als das Rauschen einer einzelnen Maschine.
- Irgendeine Angabe „um X Prozent schneller“, abgeleitet aus den internen Latenztabellen. Der Abstand zwischen den Maschinen beträgt 3.5 % gegenüber 8.6 % Eigenabweichung — genau deshalb erscheint überhaupt keine Latenztabelle pro Zelle.
- Die Latenzwerte unter Last von Ubuntu 26.04. Sie sind rechnerisch unmöglich und wurden ausgeschlossen.
- Irgendetwas über die Festplattengeschwindigkeit. Diese Spalte spiegelt wider, auf welcher physischen Maschine jeder Server gelandet ist, und nicht das Betriebssystem — und sie brachte ohnehin nichts, weil die Datenbank 99.99 % der Lesezugriffe aus dem Arbeitsspeicher beantwortet und die Festplatte nicht mehr anfasst, sobald sie warm ist.
- Irgendeine allgemeine Angabe „6amMart ist so schnell“. 53 Anfragen pro Sekunde beschreiben einen Endpunkt, auf diesen Daten, auf 2 Kernen, bei 20 gleichzeitigen Nutzern über 30 Sekunden.
- Irgendetwas über Server mit 8 GB oder mehr. In dieser Runde wurden nur Maschinen mit 4 GB gemessen.
- Irgendetwas über die Geschwindigkeit von Debian 12. Die native Laufzeitumgebung lehnt es namentlich ab, und es wurde nie gemessen.
Was die Runde kaputt gemacht hat und wir behoben haben
Drei echte Defekte kamen nur deshalb ans Licht, weil die Messung auf echten Servern mit echten Daten lief. Das sind alle drei, die die Quelle verzeichnet — die Liste ist vollständig, keine Auswahl.
- 1Der Installer scheiterte auf Debian 13. Das minimale Image liefert kein git mit, das Klonen scheiterte also komplett. Behoben.
- 2Der Testrahmen maß in den API-Zeilen gar nichts. Seine Anfrage-Header wurden auseinandergerissen, jede API-Zeile druckte also null Proben — stillschweigend, auf allen drei Maschinen. Behoben, und ein Durchlauf, der keine Proben sammelt, sagt das jetzt laut, statt ein stilles Ergebnis zu drucken.
- 3Zwei Skripte waren sich über das PHP-Speicherlimit uneinig, während ein Kommentar behauptete, die Formeln stimmten exakt überein. Korrigiert.
Dieser Abschnitt bleibt auf der Seite. Er ist der Beleg dafür, dass die Messung echt war.
Was Sie brauchen
Was Sie brauchen und was eine frische Installation tatsächlich kostet
| Anforderung | Detail |
|---|---|
| Betriebssystem | Ubuntu 26.04 (empfohlen), Ubuntu 24.04 oder Debian 13 — genau drei. Nichts sonst: ältere Releases, darunter Debian 12, und jede andere Distribution werden namentlich abgelehnt, bevor irgendetwas heruntergeladen wird. Der kostenlose Sicherheitssupport von Debian 12 endete im Juli 2026; die Container-Laufzeitumgebung installiert weiterhin darauf, aber ein neuer Shop sollte dort nicht starten. |
| Prozessortyp | arm64 (auch aarch64) oder x86_64. |
| CPU-Kerne | 2 Kerne sind die bequeme Größe für einen Shop. Autotune unterstützt 1 Kern bis 16 Kerne. |
| RAM | 2 GB sind das praktische Minimum. Der Installer verweigert unter etwa 1,2 GB und warnt unter 2 GB. 4 GB sind die bequeme Größe für einen Shop. |
| Festplatte | Keine der Sperren des Installers. Die drei gemessenen Maschinen hatten je 79 GB. Das Panel verweigert einen Upload, der weniger frei ließe als den kleineren Wert aus 2 GB und 10 % der Festplatte. Für eine native 6amMart-Installation (ohne Container) verlangt SixPreflight 20 GB frei und bevorzugt 40 GB. |
| Zustand des Servers | Frisch. Kein aaPanel, CloudPanel, cPanel oder Plesk. Nichts, das bereits auf Port 80 oder 443 lauscht. |
| Bei Ihrem Anbieter offene Ports | Genau drei: Ihr Panel-Port (eine zufällige hohe Nummer, bei der Installation gewählt), 80 und 443. Nichts sonst, niemals. |
| Zugang | Der Root-Zugang zum Server. Der Installer weigert sich, als jemand anderes zu laufen. |
| Ihr Code | Ihr 6amMart-Code in einem privaten git-Repository. SixPanel installiert aus git, nicht aus einer ZIP-Datei. |
| Ihr Telefon | Eine Authenticator-App. Die Zwei-Faktor-Anmeldung ist für das Konto des Besitzers Pflicht und kann nicht abgeschaltet werden. |
| Eine Domain | Und die Möglichkeit, ihre DNS-Einträge zu bearbeiten. |
| Ein zweiter Shop | Rund 2 GB mehr RAM und 1–2 zusätzliche Kerne pro weiterem Shop. Planen Sie mit dem oberen Ende dieser Spanne — 2 Kerne — das ist die vorsichtige Seite. |
| Was es kostet | Nichts. SixPanel ist kostenlos und auf CodeCanyon veröffentlicht, und die erste Installation und Einrichtung ist ebenfalls kostenlos. Es gibt keinen Lizenzserver, keinen Schlüssel zu erneuern und keinen Kaufcode im Installationsbefehl. |
Was SixPanel installiert: nginx, PHP-FPM, MariaDB, Redis und einen Node.js-Panel-Dienst, alles von systemd überwacht und alles aus dem eigenen Distributionsarchiv des Releases — PHP 8.5 mit MariaDB 11.8 auf Ubuntu 26.04, 8.4 mit 11.8 auf Debian 13, 8.3 mit 10.11 auf Ubuntu 24.04. Die Docker-Laufzeitumgebung installiert denselben Stack als Container, festgelegt auf PHP 8.4 und MariaDB 10.11. Sprachen der Panel-Oberfläche: 8 — Englisch, Spanisch, Arabisch, Portugiesisch, Französisch, Deutsch, Indonesisch, Bengalisch.
Was eine frische Installation tatsächlich kostet — der ehrliche Zeitplan
„Fünf Minuten“ ist der Installationsbefehl, nicht die Aufgabe. Der Installationsbefehl dauert etwa fünf Minuten. Vom gemieteten Server zum laufenden Shop zu kommen dauert etwa eine Stunde.
| Schritt | Zeit |
|---|---|
| Ihren Code in ein privates git-Repository legen (einmalig, auf Ihrem eigenen Rechner) | etwa 20 Minuten, wenn Sie git noch nie benutzt haben |
| Den Server aktualisieren und drei kleine Werkzeuge hinzufügen | ein bis zwei Minuten |
| Den Installationsbefehl ausführen — prüft das System, installiert Docker, verifiziert die Signatur, lädt die Dateien herunter und prüft sie, erzeugt Passwörter, wählt einen zufälligen Panel-Port, bemisst alles für die Maschine, baut dann und startet | 273–303 Sekunden, gemessen über drei Betriebssysteme — etwa fünf Minuten |
| Die drei Ports im Dashboard Ihres Hosters öffnen | ein paar Minuten |
| Erste Anmeldung, und Zwei-Faktor auf Ihrem Telefon einrichten | ein paar Minuten |
| Die Domain zeigen lassen und das kostenlose Zertifikat holen | unter einer Minute, sobald sich DNS verbreitet hat — legen Sie den DNS-Eintrag früh an |
| Ihren 6amMart-Code aus git installieren | ein paar Minuten |
| Gesamt für einen ersten Server | Planen Sie eine Stunde ein. Wahrscheinlich sind Sie früher fertig. |
Was der Installer am Ende ausgibt und was Sie sofort sichern müssen: die vollständige Panel-URL, den Benutzernamen und das Passwort. Das Passwort wird einmal angezeigt und nur als Hash gespeichert — es lässt sich nicht wieder auslesen.
Der mit Abstand häufigste Fehlschlag ist nicht die Installation. Es ist der Panel-Port, der beim Hoster nicht geöffnet ist.
Sicherheit
Sicherheit — nur, was sich zeigen lässt
Jeder Punkt hier lässt sich im Produkt überprüfen. Nichts hier ist eine Behauptung allgemeiner Sicherheit. Die Lücken in diesem Bereich stehen in der Liste der ehrlichen Grenzen unten, sie sind nicht versteckt.
Überhaupt zum Panel kommen
- Das Panel antwortet nur unter einer geheimen Adresse. Alles andere gibt eine leere „nicht gefunden“-Seite zurück, ein Portscanner kann das Panel also nicht von einem geschlossenen Port unterscheiden. Der Panel-Port selbst ist eine zufällige hohe Nummer, bei der Installation gewählt, auf jedem Server anders.
- Die geheime Adresse ist ein Tor vor der Anmeldung, kein Ersatz dafür — Benutzername, Passwort und Zwei-Faktor-Code laufen dahinter alle weiterhin.
- Ein falscher Zugangscode wird in konstanter Zeit verglichen und mit derselben leeren „nicht gefunden“-Seite beantwortet wie alles andere, nach einer festen Verzögerung von 200 ms. Er zählt auf eine Sperre pro Adresse. Die Verzögerung ist bei 32 gleichzeitigen Fehlversuchen gedeckelt; jenseits dieser Grenze kommt das „nicht gefunden“ sofort zurück. Ein falscher Code kostet also bis zu dieser Grenze so viel wie alles andere, nicht immer — 20 falsche Codes in 15 Minuten sperren die Adresse so oder so für 30 Minuten.
- Auf einer frischen Installation wird der Anmeldename erzeugt — admin plus vier zufällige Zeichen, zum Beispiel admin7f3q — ein Roboter, der eine Anmeldeseite findet, hat also keinen Namen, auf den er zielen kann. Eine Installation, die bereits einen Passwort-Hash mitbrachte, behält den einfachen Namen admin.
- Optionale Sperre auf die Panel-Domain. Wenn eine Panel-Domain gesetzt ist, bekommt selbst eine direkte Anfrage an die IP-Adresse des Servers dieselbe leere „nicht gefunden“-Seite. Der Weg zurück hinein führt über SSH.
Anmelden
- Passwort-Hashing (bcrypt), ein signiertes Sitzungs-Cookie und Zwei-Faktor-Codes, die für das Konto des Besitzers nicht abgeschaltet werden können.
- Eine Sperre, die einen Neustart übersteht: 20 fehlgeschlagene Passwörter in 15 Minuten sperren diese Adresse für 30 Minuten. Fünf falsche Zwei-Faktor-Codes bewirken dasselbe.
- Eine optionale IP-Allowlist für das Anmeldeformular — und das Speichern einer Liste, die Ihre eigene Adresse nicht enthält, wird verweigert, Sie können sich also nicht selbst aussperren.
Was das Panel zu tun verweigert
- Standardmäßig verboten auf jeder Route, dazu eine Prüfung auf seitenübergreifende Anfragen bei jeder Änderung. Der Deploy-Webhook ist die einzige Ausnahme und weist sich stattdessen mit einer Signatur über den rohen Anfrage-Body aus. Doppelte Zustellungen und Zustellungen, die älter als fünf Minuten sind, werden ignoriert, und jede Ablehnung wird ins Aktivitätsprotokoll geschrieben.
- Der Dateimanager kann nicht auf den Stack zugreifen. Er ist auf zwei Ordner begrenzt – Ihr Admin-Code und Ihr Storefront-Code – mit sowohl einer Präfix-Prüfung als auch einer Real-Path-Prüfung. Die Docker-Dateien, der Daten-Ordner, der Panel's eigener Ordner und die Stack-Einstellungsdatei sind von dieser API unerreichbar. Dies wird als eine Sicherheits-Grenze angegeben, nicht als Designpräferenz.
- Vertrauensentscheidungen nutzen den echten Netzwerk-Gegenpart, nie einen Header, den ein Client schreiben kann.
- Groß-/Kleinschreibung wird beim Routing vor der ersten Middleware festgelegt, was eine echte Umgehung geschlossen hat, bei der ein anders geschriebener Pfad an einer Authentifizierungsprüfung mit Beachtung der Groß-/Kleinschreibung vorbeirutschte.
Geheimnisse
- Die Zustandsdatei des Panels ist nur für den Eigentümer lesbar (0600) und liegt in einem nur für den Eigentümer zugänglichen Ordner. Die Einstellungsdatei des Stacks ist 0600. Der Socket für die Kommandozeile ist ein Unix-Socket nur für den Eigentümer — per Dateirecht nur für root, nie über das Netzwerk erreichbar.
- Das First-Boot-Passwort wird gehasht, dann aus der Stack-Einstellungsdatei gelöscht und aus der Prozess-Umgebung entfernt, sodass es nicht aus dem Container zurück gelesen werden kann.
- Eine Installation über den Assistenten ließ früher die Einstellungsdatei der Anwendung für alle lesbar zurück und sprach mit einem ungeschützten Cache. Das ist behoben — jede Installation, jedes Update, jedes Rollback und jede Übernahme setzt die Infrastrukturschlüssel jetzt neu und sperrt die Datei wieder auf 0600.
- SSH-Passwörter, die für eine Übernahme benutzt werden, tauchen nie in der Prozessliste auf. Sie werden über die Umgebung übergeben und aus jeder Logzeile entfernt.
- Das Support-Paket wird vor dem Schreiben gefiltert — Einstellungen auf Schlüsselnamen reduziert, die Zustandsdatei des Panels gar nicht erst gesammelt, der geheime Zugangscode und passwortartige Werte maskiert.
Einen Shop aus den Daten eines anderen Shops heraushalten
- Jedes Projekt läuft als eigener Unix-Benutzer, mit einem Anwendungsordner mit 0700 und einer Einstellungsdatei mit 0600. Die Barriere ist der Kernel, der einen anderen Benutzer abweist — keine Prüfung innerhalb von PHP, um die ein PHP-Fehler herumgehen kann.
- Jedes Projekt bekommt außerdem seinen eigenen Datenbankbenutzer mit Rechten, die auf sein eigenes Schema begrenzt sind, seinen eigenen PHP-Worker-Pool auf seinem eigenen Socket und seine eigene Cache-Instanz mit eigenem Passwort und eigener Speicherobergrenze.
- Das wurde geprüft, indem es angegriffen wurde, nicht behauptet. Jeder projektübergreifende Lesezugriff wurde tatsächlich aus dem PHP eines Projekts heraus versucht, auf diesem Panel und auf aaPanel. Alle schlugen auf beiden fehl — aber dort, wo sich die beiden überschneiden, trennen sie sich: Eine private Datei, die eine andere Site in das gemeinsame temporäre Verzeichnis geschrieben hatte, war auf aaPanel lesbar und wurde hier abgewiesen.
- PHP ist zusätzlich durch einen Kernel-Mount-Namespace eingeschlossen. Er hat das gemeinsame temporäre Verzeichnis geschlossen (57 sichtbare Einträge herunter auf 0), den eigenen Code des Panels, die Site-Konfiguration jedes Projekts — was jede Domain auf der Maschine bedeutet — und die sichtbare Prozessliste (138 herunter auf 6). Gemessene Kosten: keine. 217 Dateisystem-Lookups pro Anfrage davor, 217 danach.
- Zwei weitere Vorschläge wurden durch Messung verworfen statt ausgeliefert: Die Konfiguration des Webservers zu verbergen schloss nichts und machte das Check-up-Werkzeug kaputt, das sie liest, und das Verzeichnis des Panels pauschal zu sperren hätte das Datenbank-Administrationswerkzeug mit heruntergerissen.
- Das Problem des einen gemeinsamen Caches, das dies ersetzt hat, war echt, und es ist im Testabschnitt weiter unten vollständig beschrieben statt weggelassen.
Releases — und der eine Update-Weg, der nicht verifiziert ist
- Release-Artefakte sind signiert, und der Signaturschlüssel liegt offline. Das Self-Update unter Einstellungen im Panel prüft die Signatur gegen einen auf Ihrem Server hinterlegten Schlüssel, weist eine Build-Nummer ab, die gleich oder kleiner als die installierte ist, und prüft den Hash der Datei.
- Der Installationsbefehl wird geladen und vor der Ausführung gegen einen veröffentlichten Fingerprint geprüft. Passt die heruntergeladene Datei nicht, bricht der Befehl ab, und es wird nichts installiert.
- Jeder Update-Weg ist jetzt signaturgeprüft — das Self-Update unter Einstellungen im Panel, der Installationsbefehl und das Selbst-Update der Kommandozeile. Der dritte hatte früher keine der beiden Prüfungen; jetzt hat er sie.
- Der Installer selbst wird überprüft, nicht nur das Release, das er anwendet. Ihr Server liest einen veröffentlichten Eintrag mit dem Fingerprint des Installers, prüft die Datei dagegen und weigert sich, irgendetwas auszuführen, das nicht dazu passt — ein ersetzter oder vorgeschalteter Update-Host kann Ihrem Server also keinen veränderten Installer unterschieben.
- Ein neuer Signaturschlüssel wird nur dann übernommen, wenn der bereits auf Ihrem Server hinterlegte Schlüssel ihn selbst signiert hat — nie, weil der Update-Dienst es sagt, und nie, weil der neue Schlüssel das Release signiert, mit dem er ankam. Beides kann ein kompromittierter Host erzeugen; die Signatur des alten Schlüssels über einen Schlüssel, den er nie gesehen hat, kann er nicht erzeugen. Genau das verhindert, dass jemand Ihren Server umschlüsselt.
Ein gemessener Angriff, eingegrenzt und neu gemessen
Das ist der Sicherheitsnachweis auf dieser Seite, weil er auf beiden Seiten Zahlen hat.
All das wurde auf einer Testmaschine mit zwei Projekten und 8 GB gemessen, mit Redis auf 476 MB begrenzt. Das ist eine andere Maschine als die 4 GB-Maschinen in der Betriebssystem-Runde oben — in jener Runde wurden nur 4 GB-Maschinen gemessen, und beide Aussagen stimmen. Die Durchläufe nach der Korrektur wurden mit dem Listen-Budget auf 64 MB gezwungen, was die Einstellung ist, die die kleinste unterstützte Maschine bekommt, und nicht die 245 MB, die eine 8 GB-Maschine normalerweise bekäme.
Vor der Korrektur
| Messung | Wert |
|---|---|
| Redis-Speicherobergrenze auf dieser Maschine | 476 MB |
| Ein Eintrag der Artikelsuche bei größter Seitengröße (limit=200) | 917,704 Bytes |
| Geschriebene Kopien pro Eintrag | 2 — ein aktiver Schlüssel und ein Zwilling in voller Größe mit veralteten Daten |
| 20 Suchen mit einem Buchstaben bei dieser Seitengröße | +34.2 MB in 4.8 Sekunden — gemessen, also etwa 1.71 MB pro Begriff |
| Anfragen, die nötig sind, um den ganzen Cache-Server zu füllen | 476 ÷ 1.71 ⇒ etwa 278, rund 67 Sekunden über eine Verbindung |
| Sitzung eines angemeldeten Käufers | verdrängt — stillschweigend abgemeldet |
Ein Hinweis zur Rechnung, denn diese Seite kann sich oben nicht zur Tugend machen, unmögliche Zahlen zu entlarven, und dann eine Tabelle drucken, die an ihrer eigenen Multiplikation scheitert. Der interne Bericht nennt Kosten von 1.79 MB pro Begriff und einen Füllwert von etwa 279 Anfragen. Keines folgt aus dem anderen: 917,704 × 2 = 1,835,408 Bytes = 1.835 MB, nicht 1.79 MB, und 476 ÷ 1.79 = 265.9, nicht 279. Die Zeile, die alles aufgehen lässt, ist die gemessene — 20 Suchen kosten 34.2 MB, also genau 1.71 MB je Suche, und 476 ÷ 1.71 = 278.36, abgeschnitten auf 278; nichts hier ist aufgerundet. Das passt auch zur genannten Zeit: 20 Anfragen dauerten 4.8 s, 278 dauern also 66.7 s ≈ die 67 Sekunden, die die Quelle meldet. Diese Seite druckt die Kette, die eine Leserin nachprüfen kann, und lässt 1.79 MB und 279 weg, statt sie zu wiederholen.
Nach der Korrektur — die drei Fluten, die die Belegdatei auflistet, einschließlich der, die nichts speichert
Die Belegdatei beschreibt „sechs gleichzeitige nicht authentifizierte Fluten“ über einer Tabelle mit drei Zeilen und bringt die beiden nie zusammen. Ob das sechs Flut-Prozesse mit drei aufgelisteten Ergebnissen bedeutet oder drei von sechs berichteten Durchläufen, sagt die Quelle nicht — deshalb sagt diese Seite „die drei, die die Quelle berichtet“ und behauptet keine Vollständigkeit.
| Flut | Gespeicherte Einträge | Listen-Bytes in Redis | Verdrängungen | Sitzung |
|---|---|---|---|---|
| 200 Anfragen bei größter Seitengröße (limit=200) | 0 | 0 | 0 | am Leben |
| 500 Anfragen bei einer Seitengröße von 50 Zeilen | 206 | 51.5 MB | 0 | am Leben |
| 2,000 Anfragen bei einer Seitengröße von 50 Zeilen | 207 | 51.8 MB | 0 | am Leben |
Über diese Fluten hinweg lag Redis insgesamt bei höchstens 53.6 MB seiner 476 MB. Diese Zahl gilt für die gesamte Instanz, nicht für die Listen-Familie: Die Tabelle oben deckelt die Listen-Bytes bei 51.8 MB, 53.6 MB können also nicht der Listen-Cache sein.
Auf der kleinsten unterstützten Maschine ist die Listen-Familie auf 64 MB einer 128 MB großen Redis-Instanz begrenzt. Bei rund 1 KB pro Sitzung bleibt damit Platz in der Größenordnung von 60,000 angemeldeten Käufern — Platz, der auch alles andere aufnimmt, was Redis auf dieser Maschine tut, behandeln Sie ihn also als Reserve und nicht als Platzzahl.
Was das Panel ist, klar gesagt
Drei Tatsachen, auf denen die Dokumentation des Produkts selbst besteht.
- Das Panel ist Root-äquivalent auf dem Host, von Konstruktion. Es mounted die Docker-Socket und bindet das Stack-Verzeichnis read-write. Die gelöschten Fähigkeiten des Containers begrenzen den Blast-Radius – das ist eine engere Sache als Containment.
- Die geheime Zugangsadresse ist ein Tor. Die Anmeldung läuft dahinter, und jede Anmeldung verlangt ein Passwort und einen Zwei-Faktor-Code.
- Es gibt genau ein Admin-Konto und keine Rollen. Geteilt wird über temporäre Zugänge und einen schreibgeschützten Demo-Zugang.
Wie wir testen
Zwei unabhängige Runden sagten „nicht bereit“. Hier ist, was sie gefunden haben.
Die meisten Softwareseiten sagen Ihnen, was ein Produkt tut. Diese sagt Ihnen auch, was vor dem Release daran falsch war, denn wie eine Sache getestet wird, ist der einzige ehrliche Beleg dafür, wie gut sie funktioniert.
- Routen durchlaufen, 283 Seitenaufrufe über fünf Bildschirmgrößen in Hell und Dunkel
52
Routen durchlaufen, 283 Seitenaufrufe über fünf Bildschirmgrößen in Hell und Dunkel
- Oberflächentext-Schlüssel geprüft, in jeder der 7 Sprachen
2.740
Oberflächentext-Schlüssel geprüft, in jeder der 7 Sprachen
- Panel-Workflows durchgängig durchgespielt, auf beiden 6amMart-Codebasen
34
Panel-Workflows durchgängig durchgespielt, auf beiden 6amMart-Codebasen
- Unabhängige Runden, deren Urteil „nicht bereit“ lautete
2
Unabhängige Runden, deren Urteil „nicht bereit“ lautete
Ein Muster zog sich durch jeden ernsten Befund
Jeder schlimmste Defekt war eine grüne Oberfläche über einer kaputten Sache. Eine Seite, die „Erfolg“ sagt, eine Versionsnummer, die „aktualisiert“ sagt, eine Zustandsprüfung, die „gesund“ sagt — jede als Aussage wahr und als Tatsache falsch. Deshalb prüfen die untenstehenden Prüfungen jetzt das Ergebnis statt den Exit-Code.
Was die Runden gefunden haben und was damit geschehen ist
Das sind unsere eigenen, sie waren ernst, und sie sind behoben. Öffnen Sie einen beliebigen davon für die Details.
Backups liefen, meldeten Erfolg und enthielten keine DatenbankBehoben
Die Ausschlussregel des Backup-Werkzeugs filterte den gesamten Durchlauf: Das Arbeitsverzeichnis auszuschließen strich damit auch die Datenbank-Dump-Dateien, die derselbe Durchlauf ausdrücklich benannt hatte. Das Werkzeug legte das leere Verzeichnis ab und beendete sich erfolgreich.
Sechs Snapshots — einer davon als Datenbank-Backup markiert — enthielten 10.888 Dateien und keinen einzigen Datenbank-Dump, während die Backups-Seite durchgehend Erfolg und eine Repository-Größe meldete.
Es blieb verborgen, weil die Prüfschwelle bei 21 Tagen gegen einen wöchentlichen Zeitplan lag. Beides war falsch, und beides sind jetzt Gates statt Einstellungen.
Behoben, und eine Wiederherstellung wurde danach bewiesen statt angenommen: Ein frisches Backup enthält einen 39 MB großen Datenbank-Dump, der 192 Tabellen und alle 66.701 Bestellungen wiederherstellt.
Der Kunden-Storefront lauschte auf einem öffentlichen Port, außerhalb jedes SchutzesBehoben
Er war an jede Netzwerkschnittstelle auf einem einfachen, unverschlüsselten Port gebunden und umging damit den Webserver und folglich das Zertifikat, beide Ratenbegrenzer, den Cache und jeden Sicherheits-Header. Es war eine Annahme, die aus dem Container-Produkt übernommen wurde und bei einer nativen Installation nichts hinter sich hatte.
Der Test stellte außerdem fest, dass der Hosting-Anbieter standardmäßig keine Firewall setzt — auf einer Standardinstallation war das also nicht abgemildert, sondern real.
Behoben, aus dem öffentlichen Internet überprüft und nach einem Neustart erneut überprüft.
Deploy, Rollback und Aktivierung aktualisierten den Code, und die Site lieferte weiter die alte Version ausBehoben
SixPanel hält PHPs Cache für kompilierten Code festgepinnt — eine bewusste, gemessene Geschwindigkeitsentscheidung —, was bedeutet, dass Code, der sich ohne Reload ändert, nie ausgeführt wird. Nur einer der vier Pfade, die Code schreiben, führte diesen Reload aus.
Ein Deploy holte also neuen Code, führte die Datenbank-Migrationen aus, baute die Caches neu auf und startete die Worker neu, während die Website unbegrenzt weiter die alte Version auslieferte. Rollback tat überhaupt nichts.
Vorgeführt statt behauptet, durch den echten Webserver an einer bereits gecachten Datei: Vor der Änderung lieferte er Version eins aus; nach der Änderung ohne Reload lieferte er weiterhin Version eins aus, während auf der Festplatte Version zwei lag; nach dem Reload lieferte er Version zwei aus.
An allen vier Stellen behoben. Die Lehre bleibt: Eine Leistungseinstellung, die von Disziplin an anderer Stelle abhängt, bekommt sie irgendwann nicht — der Reload ist deshalb jetzt Teil derselben Funktion, die den Code schreibt.
Ein Shop konnte die Zahlungs- und E-Mail-Geheimnisse eines anderen Shops aus dem gemeinsamen Cache lesenBehoben
Der Cache war ein einziger gemeinsamer Dienst hinter einem Passwort, das die Einstellungsdatei jedes Projekts enthält. Ausgehend vom eigenen Benutzer eines Projekts las eine Sonde das gecachte Mail-Passwort eines anderen Projekts, dessen Push-Benachrichtigungs-Zugangsdaten, Maps-Schlüssel, SMS-Gateway-Schlüssel, Anti-Bot-Geheimnis und die geheimen Schlüssel zweier Zahlungs-Gateways — und Schreiben war ebenfalls erlaubt, was die gecachte Mail-Konfiguration des Opfers veränderbar machte.
Die Behebung ist eine Cache-Instanz pro Projekt, auf einem eigenen Socket, in einem eigenen Verzeichnis, mit eigenem Passwort und eigener Speichergrenze. Die Grenze ist das Dateisystem; das Passwort ist das zweite Schloss.
Bewiesen, indem der Angriff gegen sie zurückgewendet wurde: Die Sonde ging vom Gelingen zum Abgewiesenwerden in beide Richtungen über — abgewiesen, obwohl sie das eigene Passwort des Ziels hielt — und wurde gegen eine absichtlich kaputte Berechtigung erneut geprüft, um zu bestätigen, dass der Test selbst noch funktioniert.
Gemessene Kosten: 3,2 MB Speicher pro Projekt. Die Anzahl der PHP-Worker ist bei 18 von 20 Kombinationen aus Server und Projekt unverändert, und der Socket ist tatsächlich schneller als das Netzwerk-Loopback, das er ersetzt hat. Das Verschieben der Live-Daten dauerte 13,9 Millisekunden und meldete niemanden ab.
Updates landeten auf der Festplatte, ohne wirksam zu werden — dreimal in einer RundeBehoben
Ein Server nahm ein Update an, meldete die neue Version und lieferte weiter mit der Konfiguration aus, die am Tag seiner Installation geschrieben worden war. Vier verschiedene Pfade können Zustand auf einen Server bringen, und sie lieferten nicht denselben Satz.
Eine vollständige Prüfung dieser vier Pfade fand rund fünfzehn Kategorien von Zustand, den eine frische Installation erzeugte und ein aktualisierender Server nie erhielt — die gesamte Dimensionierungsleiter, die Datenbankkonfiguration, den Standard-PHP-Pool, eine von jeder Site eingebundene Datei, den Alarmdienst und seine Fehler-Hooks, und mehr.
Ein Fall war in zwei Schichten gleichzeitig unsichtbar: Jeder Server auf dem veröffentlichten Kanal scheiterte bei jedem Update an demselben Schritt, dauerhaft, und darunter meldete sich die eigene Versionsprüfung des Kommandozeilenwerkzeugs als aktuell, obwohl sie drei Releases zurücklag.
Behoben und jetzt durch eine Prüfung erzwungen, die bei jedem Build läuft: Jede Funktion, die Zustand schreibt, muss erklären, ob ein Update ihn ausliefert und warum. Gegen 14 absichtliche Sabotagen überprüft, alle 14 erkannt.
Dann durchgängig bewiesen: Ein vom veröffentlichten Kanal aktualisierter Server und ein frisch installierter Server erzeugten 1.447 von 1.447 Konfigurationszeilen, Byte für Byte identisch.
Auf unverändertem CodeCanyon-6amMart war die Installation fertig und das Admin-Panel unbenutzbarBehoben
Das 6amMart des Herstellers sperrt sein Admin-Panel nach dem Login hinter einen Aktivierungsschritt mit dem Purchase Code. SixPanel fragte den Code nie ab, erwähnte ihn nie und meldete das Deployment als abgeschlossen.
Es blieb lange unsichtbar, weil in unserer eigenen optimierten Kopie von 6amMart diese Prüfung abgeschaltet ist — die gesamte Testhistorie des Produkts war also gegen eine Codebasis gelaufen, in der das Gate nicht existiert.
Der Assistent erfasst jetzt den Purchase Code und schließt die Aktivierung der Anwendung selbst ab. Dabei wurde eine Falle geschlossen: Die Anwendung überspringt den Lizenzserver vollständig, wenn die Anfrage von der Maschine selbst kommt — was eine Anfrage von der Kommandozeile tut —, sodass jeder erfundene Code akzeptiert worden wäre, ohne dass ein Paket den Server verlassen hätte.
Zwei damit zusammenhängende Dinge wurden mit behoben. Der Storefront wird jetzt aus dem Zip installiert, das ein CodeCanyon-Käufer tatsächlich hat, statt ein git-Repository zu verlangen. Und Hersteller-Projekte werden nicht mehr im Entwicklungsmodus ausgeliefert, der die Antwort des Login-Captchas selbst in die Seite druckte.
Die Update-Signatur schützte das Release, aber nicht den Installer, der es anwendeteBehoben
Zwölf gegnerische Fälle bestehen jetzt gegen das veröffentlichte Artefakt, und dieselbe Testumgebung erzeugt zwölf Fehlschläge gegen den vorherigen Installer — zwei davon der Installer eines Fremden, der erfolgreich durchläuft und den Schlüssel eines Fremden auf dem Server hinterlässt.
Weiter zurückzugehen förderte etwas zutage, das man deutlich sagen sollte: Eine Signatur bezeugt, was gebaut wurde, nicht, womit gebaut wurde. Der Build holte sich seine eigenen Werkzeuge in der Version, die gerade die neueste war, sodass ein Abhängigkeitsbaum bei jedem Build neu aufgelöst und im signierten Artefakt mit ausgeliefert wurde. Beide Build-Werkzeuge sind jetzt unter einer eingecheckten Lockfile auf exakte Versionen festgelegt.
Ein weiterer Beinahe-Treffer aus derselben Runde: Ein Zertifikatsbefehl hatte eine Option bekommen, die die installierte Version nicht hat — jede Erneuerung wäre stillschweigend fehlgeschlagen, bis die Zertifikate abgelaufen wären. Er überstand die Durchsicht, weil dieses Werkzeug nach seiner Version zu fragen erfolgreich endet, ganz gleich, welcher andere Unsinn auf der Zeile steht.
Vierundzwanzig Stellen, an denen das Panel dem Betreiber etwas sagte, das nicht ganz stimmteBehoben
„Insgesamt gesund“ auf einem Server, den das Betriebssystem selbst als degradiert bezeichnete — nichts im Zustands-Code hatte es je gefragt. Auf dem Release-Server war ein geplanter Dienst einen Tag lang alle 60 Sekunden fehlgeschlagen und hatte seinen Fehler-Hook 1.440-mal ausgelöst, während in der Überschrift „gesund“ stand.
Selbstheilung, die eine Prüfung, die nicht laufen konnte, als Beobachtung von Gesundheit behandelte. Eine 135-fache Abweichung zwischen zwei Fehlerzählern. Eine Festplattenbelegung, die 18,4 % des belegten Platzes erfasste und das als Gesamtbild darstellte — jetzt 92,7 %.
Ein unfertiger Einrichtungsassistent, der den Versions-Endpunkt überhaupt nie anfragte, und eine mobile Navigation, die auf null Breite zusammenfiel, sobald der Update-Hinweis angezeigt wurde.
Alle 24 geschlossen. Zwei der letzten sechs gemeldeten Defekte stellten sich als nicht real heraus, und beide wurden mitsamt den Belegen verworfen, statt fürs Erscheinungsbild behoben zu werden.
Jeder installierte Server führte Dateien aus, die einem Benutzer gehörten, den es auf ihm nicht gibtBehoben
Benutzer und Gruppe der Build-Maschine waren in das Artefakt eingebacken — 459 Dateien auf einem Server, darunter einer, der nur jemals den veröffentlichten Installationsbefehl bekommen hatte.
So wie es war, nicht ausnutzbar, aber es bedeutete, dass das System Code ausführte, der ihm nicht gehörte — und das ist kein Zustand, den man auf sich beruhen lässt.
Vom Update selbst korrigiert: aus 459 Dateien mit falschem Eigentümer wurden null.
Was standgehalten hat
Dieselben Runden bestätigten auch die Dinge, die funktionieren sollten, und die sind es wert, mit ihren Zahlen genannt zu werden statt mit Adjektiven.
- Vollständiger Neustart
- Nach 79 Sekunden wieder über SSH erreichbar, null fehlgeschlagene Dienste, jeder Dienst in Byte-identischem Zustand zu dem Snapshot, der vor dem Neustart aufgenommen wurde, beide Websockets verbunden, kein manueller Schritt.
- Das Panel hart abschießen
- Nach etwa 4 Sekunden wieder da.
- Ein gewöhnliches Update
- Null Sekunden Ausfallzeit, 91 von 91 Anfragen wurden durchgehend normal beantwortet.
- Wiederherstellung aus dem Backup
- 192 Tabellen und 66.701 Bestellungen, aus einem echten geplanten Backup statt aus einem, das für den Test gemacht wurde.
Noch offen, und hier genannt statt weggelassen
- Ein Datenbankzähler steht auf dem nativen Server schlecht — temporäre Tabellen werden bei 59,8 % der Abfragen auf die Festplatte geschrieben. Das ist ein Problem der Abfrageform und keines der Dimensionierung, und es ist seit der letzten Runde neu.
- Das Container-Produkt braucht ein Release, das die Backup-Behebung und die oben beschriebene DNS-Arbeit mitbringt.
- Ein veralteter fehlgeschlagener Hintergrund-Job auf dem Testserver ist der alleinige Grund, warum sein eigenes Check-up 88 statt 97 erreichte — die Punktzahl wird gedeckelt, sobald irgendeine Zeile schlecht ist, und die zugrunde liegenden Rohwerte unterscheiden sich über etwa hundert Prüfungen hinweg um 0,03.
Nichts davon ist für Serversoftware ungewöhnlich. Ungewöhnlich ist, es zu veröffentlichen. Wenn die Marketingseite eines Panels keine solche Liste hat, heißt das nicht, dass es nichts zu finden gab.
Ehrliche Grenzen
Ehrliche Grenzen
Jede einzelne davon stimmt heute.
- 1
Es nimmt den ganzen Server.
Keine anderen Websites, kein anderes Control-Panel, nichts sonst auf den Ports 80 und 443.
- 2
Ein Admin-Konto. Keine Rollen, keine Teamkonten.
Temporäre Zugänge und ein schreibgeschützter Demo-Zugang sind die Mittel zum Teilen.
- 3
Das Panel ist auf der Maschine root-gleichwertig.
Jeder, der sich anmelden kann, kann alles auf diesem Server ausführen. Neustart, Betriebssystem-Update und Self-Update funktionieren, indem sie einen privilegierten Container starten, der in das Host-Dateisystem hineingreift – so sind sie gebaut.
- 4
Die Wiederherstellung ist noch keine Schaltfläche „auf einen beliebigen Server umziehen“.
Ein Backup-Lauf deckt jedes Projekt ab, aber die Wiederherstellung zielt derzeit auf das Standardprojekt. Beim Wiederherstellen auf einer anderen Maschine bleiben die Passwörter und Pfade der alten Maschine bestehen, und die Anwendung kann sich erst verbinden, wenn Sie Update drücken. Der Restore-Job führt außerdem keine Datenbankmigrationen aus, ein älteres Backup unter neuerem Code bleibt also hinter dem Schema zurück. Für beides gibt es einen funktionierenden manuellen Schritt; automatisch ist heute keines von beiden. Der Wiederherstellungsweg selbst wurde in der Runde vom 15. August im Code geprüft und nicht ausgeführt.
- 5
Ein Code-Rollback macht Datenbankmigrationen nicht rückgängig.
Wenn eine Migration gelaufen ist, braucht das Zurückrollen des Codes ein Zurückspielen aus dem Backup.
- 6
Das Panel übernimmt ein erneuertes Zertifikat beim Neustart.
Die tägliche Erneuerung lädt nginx neu; das Panel liest sein eigenes Zertifikat einmal beim Start.
- 7
Das Umziehen eines Shops von einem alten Server wurde im Code geprüft, nicht ausgeführt.
Das war die Runde vom 15. August. Behandeln Sie es als unterstützt, nicht als auf Ihrer Art von Server bewiesen.
- 8
Der Self-Healing-Watchdog sieht nur Dienste, die eine Zustandsprüfung deklarieren.
Auf der Container-Laufzeitumgebung deklarieren die optionalen Websocket- und Storefront-Container noch keine. Davon getrennt, und durch Testen statt durch Lesen gefunden: Die Selbstheilung meldete einmal eine erfolgreiche Reparatur, während ein Hintergrund-Worker seit 14 Minuten hing und 250 Jobs dahinter eingefroren waren. Alles, was sie wirklich beobachten kann, meldet sie jetzt als Beobachtung; von allem, was sie nicht kann, sagt sie jetzt, dass sie es nicht kann.
- 9
Der eigene Code des Panels ist auf Ihrem Server nicht lesbar.
Sein Backend wird als V8-Bytecode ausgeliefert und die lesbaren Quellen sind aus dem Build entfernt; die Browser-Dateien sind minimiert und verschleiert. Das ist Abschreckung, kein Schutz — wer entschlossen ist, kann immer noch herausfinden, was es tut. Ihr 6amMart-Code und Ihre Daten bleiben davon unberührt.
- 10
Das Self-Update der sixpanel-Kommandozeile hat keine Signaturprüfung und keine Hash-Prüfung.
Bei einer paketierten Installation lädt es den Installer über das Netz und führt ihn als root aus, und seine eigene Fortschrittszeile behauptet das Gegenteil. Das Selbst-Update in den Einstellungen des Panels und der Installationsbefehl sind geprüft; dieser dritte Weg nicht. Bis das behoben ist, aktualisieren Sie über das Panel.
- 11
Das Aktivitätsprotokoll hat ein Loch, und die Regeln für zusätzliche Bestätigung sind uneinheitlich.
Das Löschen einer geplanten Aufgabe schreibt keinen Protokolleintrag, während Anlegen, Bearbeiten und manuelles Ausführen das alle tun — das Löschen einer Root-Aufgabe auf Panel-Ebene hinterlässt also keine Spur. Getrennt davon: Eine geplante Aufgabe auf Panel-Ebene verlangt, dass Sie Ihr Passwort erneut eingeben, aber Neustart, Betriebssystem-Update und Self-Update des Panels — alle root auf dem Host — verlangen nur eine gültige Sitzung.
- 12
Drei Panel-Einstellungen sind tote Konfiguration.
Das Panel's API-Rate-Limit, sein Heavy-Path-Rate-Limit und seine Upload-Größen-Kappe werden von der Code gelesen, aber nicht an den Panel-Container übergeben, also ändert sich in der Stack-Einstellungsdatei nichts. Die Dokumentation sagt, niemals einen Administrator darauf hinzuweisen.
- 13
Kein Kubernetes.
Es gibt keinen Kubernetes-Treiber im Panel.
- 14
PHPs JIT-Compiler ist in der einen Laufzeitumgebung an und in der anderen aus.
SixPanel fährt PHPs tracing-JIT. Gegen den Modus, den aaPanel ausliefert, wurde er bei einer Anfrage auf 9 von 9 Endpunkten und bei vier gleichzeitig auf 9 von 9 als schneller gemessen; ob JIT ganz abzuschalten auf dieser Laufzeitumgebung noch schneller wäre, ist nicht getestet. Auf der Container-Laufzeitumgebung ist JIT aus, denn dort wurde er auf 11 von 12 Endpunkten als langsamer gemessen und lag beim zwölften gleichauf. Dieselbe Einstellung, zwei Stacks, entgegengesetzte Antworten — beides ist das, was die Messung gesagt hat. Brotli und HTTP/3 am Origin sind auf beiden absichtlich aus: Cloudflare erledigt diese Schicht.
- 15
Die Hintergrund-Warteschlange nutzt die Datenbank, nicht Redis.
Redis war beim Durchsatz der Warteschlange 1.76× schneller und wurde trotzdem abgelehnt, weil eine Redis-Warteschlange unter Speicherdruck stillschweigend verdrängt werden kann — 50 wartende Jobs gingen auf 0, ohne Protokolleintrag und ohne Fehlermeldung. Nichts, was für Bestellungen kritisch ist, geht überhaupt in die Warteschlange.
- 16
Die Ratenbegrenzung ist ein Flutschutz, kein DDoS-Schutz.
Grenzen pro Adresse können nicht genau sein, wenn eine ganze Stadt sich eine Mobilfunk-IP teilt. Cloudflare ist dafür die echte Schicht.
SixPanel und 6amMart
SixPanel ist der Server. Der optimierte Code ist 6amMart selbst.
SixPanel macht eine 6amMart-Installation schnell einzurichten, sicher zu aktualisieren und günstig zu betreiben.
Die eigenen Bildschirme von 6amMart schneller zu machen ist getrennte Arbeit, und sie kommt mit dem Installationsservice statt als Aufpreis — gemessen mit 10× bis 22× schneller auf jedem Bildschirm, den Kunden sehen, auf einem laufenden Server. Diese Bildschirme gingen von 0.5–8.19 s auf 45–370 ms.
Die beiden Zahlensätze messen verschiedene Dinge und werden nie in einer Tabelle vermischt. Die von SixPanel sind Serverzahlen — dieselbe Anwendung, von verschiedenen Stacks ausgeliefert. Die des optimierten Codes sind Anwendungszahlen — derselbe Stack, der verschiedenen Code ausführt. Das Langsamste, was in dieser Runde überhaupt gemessen wurde, war weder das eine noch das andere: ein 6amMart-Admin-Report mit 20,9 Sekunden, den keine Servereinstellung bewegt hat.
Der optimierte Code ist nichts, was Sie separat kaufen. Es gibt keine zweite Lizenz, keinen zweiten Preis und keinen zweiten Release-Strang — es ist die Art, wie der bestehende 6amMart-Installationsservice geliefert wird, zur selben Installation für $300. Wenn der Hersteller von 6amMart ein neues Release veröffentlicht, gilt die veröffentlichte Katalogregel unverändert: Update oder Upgrade auf eine neuere Script-Version kostet 50 % des Installationspreises. Jede Installation wird auf dem neuesten 6amMart-Release ausgeliefert.
FAQ
Fragen, die Leute tatsächlich stellen
Zwölf Fragen, beantwortet mit den gleichen Zahlen wie der Rest der Seite.
Was ist SixPanel?
Ein Hosting-Panel und Docker-Stack für einen Job: eine 6amMart-Shop auf Ihrem eigenen Server zu betreiben. Es installiert den Web-Server, die Datenbank, PHP, den Cache, den Background-Worker und das HTTPS-Zertifikat, und gibt Ihnen dann eine Web-Seite zum Ausführen all davon.
Enthält SixPanel das 6amMart-Script?
Nein. 6amMart kaufen Sie bei CodeCanyon. SixPanel installiert den Code, der Ihnen bereits gehört, aus Ihrem eigenen privaten git-Repository. SixPanel selbst ist kostenlos und separat auf CodeCanyon veröffentlicht, und sein Installationsbefehl ist öffentlich — derselbe für alle.
Welches Betriebssystem soll ich installieren?
Ubuntu 26.04 LTS, in beiden Laufzeitumgebungen. Die native unterstützt genau drei Releases — Ubuntu 26.04, Ubuntu 24.04 und Debian 13 — und nimmt PHP, MariaDB, nginx und Redis aus dem, das Sie wählen. Geschwindigkeit ist nicht der Grund: über sechs gemessene Achsen ergab kein Versionswechsel einen berichtbaren Unterschied. Sicherheitsupdates sind der Grund: 26.04 wird bis April 2031 mit Patches versorgt, gegenüber Mai 2029 für 24.04 und August 2028 für Debian 13. Debian 12 wird von der nativen Laufzeitumgebung namentlich abgelehnt; die Container-Laufzeitumgebung installiert weiterhin darauf, aber sein Sicherheitssupport endete im Juli 2026, starten Sie dort also keinen neuen Shop.
Warum geht es bei der Empfehlung um die Support-Laufzeit und nicht um Geschwindigkeit?
Weil Geschwindigkeit nichts entschieden hat. Sechs Achsen wurden auf identischer Hardware gemessen — Betriebssystem, PHP, MariaDB, nginx, Redis und Kernel — und kein Versionswechsel ergab einen berichtbaren Unterschied. Zwei bytegleiche Maschinen wichen in 20 von 20 Zeilen um 11,6 % voneinander ab, was größer ist als jeder gefundene Effekt. Was sich unterscheidet, ist, wie lange jedes Release weiter Sicherheitspatches bekommt, und ein Betriebssystem, dessen Support ausläuft, ist das eine Ereignis, das einen vollständigen Neuaufbau des Servers erzwingt. Ubuntu 26.04 LTS hat von den drei die längste Laufzeit, bis April 2031.
Wie klein darf der Server sein?
Zwei Prozessorkerne und 4 GB RAM betreiben einen ganzen Shop — das ist die Größe, auf der wir gemessen haben. Der Installer verweigert unter etwa 1.2 GB und warnt unter 2 GB. Für einen zweiten oder dritten Shop planen Sie je rund 2 GB mehr RAM und 1–2 zusätzliche Kerne.
Wie schnell ist es?
Gegen aaPanel auf identischer Hardware gemessen — 2 Kerne, 4 GB, derselbe Shop mit 66.701 Bestellungen — antwortete SixPanel bei einer Anfrage 1,76× schneller und bei vier gleichzeitig eintreffenden 1,82× schneller, über die Endpunkte, die auf beiden Maschinen PHP erreichen. aaPanel wurde vorher vollständig abgestimmt. Die vollständige Tabelle, die Methode und der weiterhin unerklärte Teil stehen alle oben.
Wie lange dauert die Installation?
Der Installationsbefehl gemessen 273 bis 303 Sekunden über drei Betriebssysteme – etwa fünf Minuten, unbeaufsichtigt. Von einem vermieteten Server zu einem live-Shop zu kommen, einschl. DNS, das Zertifikat und Installation Ihres Codes, dauert etwa eine Stunde auf dem ersten Server.
Kann ich meine anderen Websites auf demselben Server hosten?
Nein. Der Installer verweigert einen Server, auf dem bereits aaPanel, CloudPanel, cPanel oder Plesk läuft oder auf dem etwas die Ports 80 oder 443 belegt. SixPanel verwaltet den Webserver, die Zertifikate und den Firewall-Plan für die ganze Maschine, und zwei Systeme, die das auf einer Maschine tun, machen sich gegenseitig kaputt. Weitere 6amMart-Shops auf demselben Server zu betreiben, wird unterstützt.
Kann ich meinem Entwickler Zugang geben, ohne ihm mein Passwort zu geben?
Ja. Legen Sie einen temporären Zugang mit eigenem Namen und eigenem Passwort an, der nach 1 Stunde, 8 Stunden, 24 Stunden oder 7 Tagen abläuft. Er kann die Website betreiben. Er kann nicht ändern, wer hereinkommt, und Ihre Geheimnisse nicht sehen. Es gibt außerdem einen schreibgeschützten Demo-Zugang, um jemandem das Panel zu zeigen.
Fasst ein Update von SixPanel meine Daten oder meinen Code an?
Nein. Ein Update von SixPanel ersetzt den eigenen Code von SixPanel. Ihre Einstellungen, Ihre Daten — Datenbank, Uploads, Zertifikate, lokale Backups — und Ihr Anwendungscode bleiben genau so, wie sie sind. Eines ist es wert zu wissen, weil wir es auf die harte Tour gelernt haben: Ein Update, das Dateien auf die Festplatte legt, ist nicht dasselbe wie ein Update, das wirksam wird. Jeder Pfad, der Zustand schreibt, muss jetzt erklären, ob ein Update ihn ausliefert, bei jedem Build läuft eine Prüfung, und für einen frisch installierten und einen aktualisierten Server wurde nachgewiesen, dass sie 1.447 von 1.447 identische Konfigurationszeilen erzeugen.
Woher weiß ich, dass die Backups tatsächlich funktionieren?
Das Panel beweist es, und der Grund, warum es das beweist, ist, dass es einmal schiefgegangen ist. Backups liefen, meldeten Erfolg und enthielten vier Tage lang überhaupt keine Datenbank, weil die Ausschlussregel des Werkzeugs die Dump-Dateien strich, die derselbe Durchlauf benannt hatte. Das ist behoben, und es ist jetzt ein Gate statt einer Einstellung: Eine Wiederherstellung wird in eine Wegwerf-Datenbank geladen, gezählt und gelöscht — 192 Tabellen und 66.701 Bestellungen, aus einem echten geplanten Backup. Zwei ehrliche Vorbehalte bleiben: Eine Wiederherstellung auf einem anderen Server braucht danach einen manuellen Schritt, und die Wiederherstellung zielt derzeit auf das Standardprojekt.
Ist SixPanel Open Source?
Nein. Das Backend des Panels wird als V8-Bytecode ausgeliefert, die lesbaren Quellen sind entfernt, und die Browser-Dateien sind minimiert. Wir nennen das Abschreckung, nicht Sicherheit — wer entschlossen ist, kann immer noch herausfinden, was der Code tut. Ihr 6amMart-Code und Ihre Daten gehören Ihnen, und nichts hier verschleiert sie. Wenn lesbarer Quellcode auf Ihrem eigenen Server eine Anforderung ist, ist ein allgemeines offenes Panel die bessere Wahl für Sie.
Was ist der Unterschied zwischen SixPanel und SixPanel Docker?
Dasselbe Panel, dieselben Befehle und dasselbe Handbuch — nur die Art, wie die Software darunter installiert wird, unterscheidet sich. SixPanel installiert nginx, PHP, MariaDB und Redis direkt aus dem eigenen Distributionsarchiv des Releases und lässt systemd sie überwachen. SixPanel Docker betreibt denselben Stack als Container, festgelegt auf PHP 8.4 und MariaDB 10.11, was der Host auch betreibt. Die native ist auf jedem gemessenen Endpunkt schneller und isoliert Projekte im Kernel statt innerhalb von PHP, sie ist daher die Empfehlung, und dort geht die neue Entwicklung hin. Nehmen Sie die Container-Variante, wenn Sie den Stack in Containern isoliert haben möchten oder wenn Sie MariaDB 10.11 auf einem Release brauchen, dessen Archiv es nicht mitbringt.
Ihre Seite listet Defekte in Ihrem eigenen Produkt auf. Warum?
Weil das der einzige ehrliche Beleg dafür ist, dass das Testen echt ist. Zwei unabhängige durchgängige Runden kamen zum Urteil „nicht bereit“, bevor das hier als fertig bezeichnet wurde, und sie fanden Backups, die Erfolg meldeten und keine Datenbank enthielten, einen Storefront, der außerhalb jedes Schutzes lauschte, und Deploys, die den Code aktualisierten, während die Site weiter die alte Version auslieferte. Alles ist behoben, jeweils mit der Prüfung, die es jetzt behoben hält. Wenn die Marketingseite eines Panels keine solche Liste führt, heißt das nicht, dass es nichts zu finden gab.
Beginnen Sie mit der kostenlosen Prüfung, dann entscheiden Sie
SixPreflight sagt Ihnen, ob der Server, den Sie haben, für 6amMart bereit ist, und was genau zu ändern ist. Wenn wir das Ganze lieber übernehmen sollen, sprechen Sie mit uns.
Sehen Sie, was sich in jeder Version geändert hat