SixPanel : le panneau d'hébergement conçu pour une seule tâche — faire tourner 6amMart
SixPanel est un panneau d'hébergement conçu pour une seule tâche : faire tourner une boutique 6amMart sur votre propre serveur. Une commande installe nginx, la base de données, PHP, le cache, le worker d'arrière-plan, l'ordonnanceur, le serveur websocket et HTTPS. Vous pilotez ensuite le serveur depuis une page web.
Tout tourne sur votre serveur. Votre base de données, vos images, les données de vos clients.
- d'installation sans surveillance, mesurée sur trois systèmes d'exploitation
273–303 s
d'installation sans surveillance, mesurée sur trois systèmes d'exploitation
- font tourner une boutique entière
2 cœurs / 4 GB
font tourner une boutique entière
- vérifications de santé, chacune avec un bouton de correction
~20
vérifications de santé, chacune avec un bouton de correction
- langues d'interface du panneau
8
langues d'interface du panneau
Vous lisez cette page avec un assistant IA ?
Obtenir SixPanel
SixPanel s'installe avec une seule commande. Rien à créer, aucune clé à saisir, aucun code à coller — c'est la même commande pour tout le monde. C'est gratuit.
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashCe qui protège une commande exécutée en root, ce n'est pas l'adresse — c'est la signature de la version. L'installateur porte notre clé de signature et refuse automatiquement tout fichier qui n'y correspond pas. La page d'installation l'explique.
Essayez avant de télécharger
Accès en lecture seule
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.
Obtenir SixPanel
Free- Mises à jour incluses — chaque version arrive sur CodeCanyon sans frais supplémentaires, et le panneau peut aussi se mettre à jour tout seul. Pas de serveur de licence, aucune clé à renouveler.
- La première installation est offerte — envoyez votre code d'achat et les informations du serveur par WhatsApp ou e-mail.
Rien à activer — cela tourne sur votre propre serveur, sans appel vers l'extérieur, et continue de fonctionner même si ce site est hors ligne.
Ce que c'est, et ce que ça remplace
Le script est à vous. Il faut quand même quelqu'un pour faire tourner le serveur.
Vous avez acheté le script 6amMart sur CodeCanyon. C'est un dossier de fichiers. Avant qu'il puisse prendre une commande, quelqu'un doit installer un serveur web, une base de données, PHP, un cache, un worker de tâches de fond et un certificat HTTPS — puis maintenir tout cela en état de marche.
SixPanel est la partie qui s'en charge. Vous louez un serveur neuf, lancez une commande, et vous récupérez un panneau de contrôle web. Depuis ce panneau, vous connectez votre domaine, obtenez du HTTPS gratuit, installez votre code 6amMart depuis git, le mettez à jour, le sauvegardez, et voyez ce qui est cassé quand quelque chose casse.
Tout tourne sur votre serveur. Votre base de données, vos images, les données de vos clients.
Trois façons de le piloter
Le panneau
Dans un navigateur. C'est là que vous faites presque tout.
La commande sixpanel
Sur le serveur, pour quand le panneau ne veut pas s'ouvrir.
L'installateur
Que vous lancez une seule fois.
Avec versus sans
Chaque ligne est le même travail, fait des deux façons. À gauche, ce que faire tourner 6amMart exige de vous sans SixPanel ; à droite, ce que cela devient avec lui.
Mettre le serveur en route
Sans lui
Construire un serveur à la main — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, un superviseur de processus — et garder tout cela en vie
Avec SixPanel
Une commande d'installation. Docker Compose est le superviseur, avec redémarrage après plantage, redémarrage après reboot, plafonds mémoire, rotation des journaux et contrôles de santé, tous déclarés au même endroit.
Dimensionner la base de données et PHP
Sans lui
Deviner les réglages de la base de données et de PHP, ou payer quelqu'un pour les régler
Avec SixPanel
L'autoréglage lit la machine réelle et écrit les dimensions : workers PHP-FPM, buffer pool InnoDB, mémoire Redis, tables temporaires, tampons de tri et de jointure, journal redo, et chaque plafond mémoire de conteneur. Il couvre de 1 cœur / 2 GB jusqu'à 16 cœurs / 32 GB.
Livrer un changement sur la boutique
Sans lui
Payer un développeur pour chaque déploiement
Avec SixPanel
Vous poussez sur git, la boutique se met à jour. Historique de déploiement et retour arrière, avec les 30 derniers déploiements conservés.
Savoir que la sauvegarde fonctionne
Sans lui
Espérer que la sauvegarde fonctionne
Avec SixPanel
Les sauvegardes suivent une planification avec rétention, et une fois par semaine le panneau charge la sauvegarde la plus récente dans une base jetable, compte ce qu'elle contient, puis la supprime.
Quand la boutique tombe
Sans lui
Lire une trace d'erreur pour comprendre pourquoi la boutique est hors ligne
Avec SixPanel
Une page Santé d'une vingtaine de vérifications, chacune avec une phrase simple sur la conséquence et exactement un bouton de correction.
Ce que cela coûte
Sans lui
Construire et maintenir cette pile vous-même, c’est le coût, que vous le payiez en heures ou en factures.
Avec SixPanel
Rien. SixPanel est gratuit sur CodeCanyon, la première installation et configuration est gratuite, et la commande d’installation est la même commande publique pour tout le monde — aucune clé à saisir, aucun code à coller. Les mises à jour arrivent par CodeCanyon, et le panneau peut aussi se mettre à jour lui-même.
Ce que ça ne remplace pas
Il ne vous vend pas le script 6amMart.
Vous l'achetez sur CodeCanyon, et SixPanel installe le code que vous possédez déjà.
Ce n'est pas de l'hébergement mutualisé.
Pas de compte cPanel, pas d'autres sites web sur la machine. SixPanel attend le serveur entier.
Il ne fait pas tourner votre commerce.
Les prix, les produits, les livreurs et les commandes vivent dans le panneau admin de 6amMart.
Ce n'est ni un CDN ni un service anti-DDoS.
Cloudflare est la vraie couche de bordure, et la documentation le dit.
Deux façons de l'exécuter
Un panneau, deux environnements d'exécution — et l'un des deux est recommandé
Les deux sont le même produit, avec le même panneau, les mêmes commandes et le même manuel. Ils ne diffèrent que par la façon dont le logiciel sous-jacent est installé, et cette différence est mesurable.
- Recommandé
SixPanel
S'exécute directement sur le serveur
nginx, PHP-FPM, MariaDB et Redis installés depuis l'archive de distribution de la version elle-même et supervisés par systemd. Rien n'est conteneurisé : chaque saut passe donc par un socket unix, et la base de données est réglée pour la machine plutôt que pour un conteneur. C'est le plus rapide des deux, et c'est là que va tout le travail neuf.
Commande d'installation
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- Système d'exploitation
- Ubuntu 26.04 LTS (recommandé), Ubuntu 24.04 LTS ou Debian 13
- PHP
- 8.5 sur Ubuntu 26.04, 8.4 sur Debian 13, 8.3 sur Ubuntu 24.04 — toujours le paquet de la version elle-même
- Base de données
- MariaDB 11.8 sur Ubuntu 26.04 et Debian 13, 10.11 sur Ubuntu 24.04 — depuis la même archive
- Supervisé par
- systemd
SixPanel Docker
S'exécute dans des conteneurs
La même pile sous forme de services Docker Compose. Son avantage est que les versions de PHP et de la base de données ne dépendent pas du tout de l'hôte : les images sont figées sur PHP 8.4 et MariaDB 10.11, quelle que soit la version sur laquelle vous les faites tourner. Elle s'installe toujours, et les serveurs qui la font déjà tourner continuent de recevoir des mises à jour.
Commande d'installation
curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash- Système d'exploitation
- Ubuntu 24.04 / 26.04 LTS, Debian 13 — et Debian 12, qui s'installe mais n'est pas recommandé
- PHP
- 8.4, dans le conteneur
- Base de données
- MariaDB 10.11, dans le conteneur
- Supervisé par
- Docker Compose
Lequel choisir ?
Choisissez SixPanel, sauf si quelque chose de précis impose l'autre. Il est plus rapide sur tous les points de terminaison mesurés, il isole les projets au niveau du noyau plutôt qu'à l'intérieur de PHP, et c'est l'environnement qui continue de s'améliorer.
Choisissez SixPanel Docker si vous voulez toute la pile isolée dans des conteneurs, ou s'il vous faut précisément MariaDB 10.11 sur une version dont l'archive ne la contient pas — les images sont figées sur PHP 8.4 et MariaDB 10.11 indépendamment de l'hôte. Il s'installe aussi toujours sur Debian 12, mais n'y démarrez pas une nouvelle boutique : le support de sécurité de Debian 12 s'est arrêté en juillet 2026, et le noyau, la glibc, Docker et OpenSSH viennent toujours de l'archive de l'hôte.
Pour être direct : le développement neuf va vers l'environnement natif. SixPanel Docker est maintenu, pas étendu. Si vous installez aujourd'hui et que le choix du système d'exploitation est libre, prenez le natif.
Mesuré, pas affirmé
Trois serveurs, la même boutique, une seule différence
Chaque chiffre de performance de cette page provient d'une même campagne de mesures, sur de vrais serveurs faisant tourner les données d'une vraie boutique. Le montage, la méthode et les scripts sont publiés, tout comme la part qui reste inexpliquée.
1.76×
plus rapide qu'un aaPanel entièrement réglé
1.82× lorsque quatre requêtes arrivent en même temps. Mesuré sur les endpoints qui atteignent PHP sur les deux serveurs.
Comment cela a été mesuré
- Trois serveurs
- AMD EPYC 7713, 2 vCPU, 4 GB, Ubuntu 24.04 — identiques, à l'exception du panneau testé
- La même application
- Le même code 6amMart sur les trois, vérifié octet par octet : fichier de verrouillage des dépendances identique, empreinte identique sur l'application, les routes, les modules et la configuration
- La même boutique
- 66,701 commandes · 3,865 articles · 85 boutiques · 17,534 clients — un vrai jeu de données, copié ligne par ligne
- La méthode
- Chaque machine se mesure elle-même via la boucle locale, avec son vrai nom d'hôte et son vrai certificat. 40 échantillons par cellule après une chauffe écartée, et chaque chiffre publié est une médiane de passes appariées alternées.
- Rien n'est écarté en silence
- Zéro réponse bloquée par la limitation de débit et zéro erreur dans chaque ligne publiée. Une requête bloquée ou en échec répond très vite : une campagne qui les dissimule annonce donc un meilleur chiffre que la réalité.
Tous les endpoints, les quatre configurations
Millisecondes médianes — une requête / quatre en même temps. Plus bas est meilleur.
| Endpoint | SixPanel | SixPanel Docker | aaPanel, d'origine | aaPanel, réglé |
|---|---|---|---|---|
/api/v1/categoriesForcé jusqu'à PHP sur les trois — la ligne la plus proprement comparable | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allLa liste des boutiques que chaque client voit en premier | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchLa lecture la plus lourde de l'application | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularDes jointures sur tout le catalogue | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listAuthentifié et non cachable — l'appel le plus lent sur chaque machine | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)SixPanel redirige en 430 octets ; aaPanel affiche 352 KBTravail différent | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeSixPanel calcule la page ; celle d'aaPanel est un succès de cache proxyTravail différent | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeTemps jusqu'à l'acceptation de la connexion | 2.35.8 | 4.211.6 | 2.66.3 | —— |
Le vert indique la configuration la plus rapide de la ligne.
Deux lignes sont signalées parce que les serveurs n'y font pas le même travail. Les chiffres sont réels ; ce n'est simplement pas une course équitable, et ils sont montrés plutôt que retirés.
Ensuite le concurrent a été entièrement réglé, et l'écart ne s'est pas refermé
Battre un concurrent sur ses réglages par défaut ne prouve rien. La machine aaPanel a donc été réglée comme l'aurait réglée un administrateur compétent, et tous les chiffres ont été repris.
- opcache PHP porté de 128 MB à 256 MB, avec la validation des horodatages désactivée
- Buffer pool de la base porté de 256 MB à 1152 MB — quatre fois et demie plus grand
- Fichier de journal de la base porté de 128 MB à 320 MB, et cache de requêtes désactivé
- Workers PHP corrigés d'un 50 surengagé à un 14 dimensionné
- Cache de chemins quadruplé et tampons du serveur web doublés
Son PHP 8.4 et son compilateur JIT ont été délibérément laissés activés. Ce sont ses avantages, et les lui retirer aurait truqué le test.
Face à la machine d'origine, SixPanel était 1.65× / 1.80× plus rapide. Face à la machine entièrement réglée, il est à 1.76× / 1.82×. L'écart s'est légèrement déplacé dans l'autre sens.
La batterie de tests sur la base de données n'a pas bougé du tout. Un buffer pool quatre fois et demie plus grand n'a rien changé, parce que ces rapports sont un travail limité par le processeur, portant sur des lignes déjà présentes en mémoire. Les compteurs internes se sont bien améliorés — taux de succès du cache de 99.856% à 99.930%, tables temporaires écrites sur disque de 47.3% à 22.1% — et les temps de réponse n'ont pas suivi.
D'où vient réellement l'écart
Une affirmation de rapidité ne vaut pas grand-chose sans cause. La différence a donc été décomposée sur les cinq endpoints qui atteignent PHP sur les deux machines, une variable à la fois.
| Configuration | Une requête | Quatre en même temps |
|---|---|---|
| Les deux machines telles qu'elles sont livrées | 1.99× | 1.91× |
| Après désactivation de la restriction de répertoires d'aaPanel | 1.32× | 1.29× |
| Après avoir aussi corrigé son mode de compilateur JIT | ≈1.25× | ≈1.21× |
L'écart, attribué
- Une restriction de répertoires PHP60%
- Le mauvais mode de compilateur JIT8%
- La version de PHP0%
- Toujours inexpliqué32%
Environ un tiers de la différence n'est pas expliqué, et il est publié comme inexpliqué plutôt que porté à notre crédit. La principale piste non testée est qu'aaPanel compile son propre PHP alors qu'Ubuntu fournit un paquet. Ni cette piste ni la différence de réglages restante ne peuvent être isolées sur une seule machine : ni l'une ni l'autre n'est donc revendiquée.
La forme compte plus que le rapport
Ce surcoût est un coût fixe par requête : il domine donc le travail court et disparaît sur le travail long. Le même rapport d'administration de 20.9 secondes ne sépare les deux machines que de 1.17×. Si votre boutique est surtout faite de rapports lourds, la différence sera faible. Si elle est surtout faite d'appels d'API depuis l'application mobile — ce qu'est essentiellement une boutique de livraison de repas — c'est toute la différence.
Le raisonnement, en entier
La plus grosse cause à elle seule était un unique réglage PHP, et il coûtait de 16 à 26 ms sur chaque requête≈60% de l'écart
aaPanel restreint les répertoires auxquels PHP a le droit de toucher. C'est une vraie fonction de sécurité : elle méritait donc une vraie mesure plutôt que d'être balayée comme du superflu.
Trois paires alternées, le bras « désactivé » écrivant un fichier de configuration vide pour que le balayage par répertoire ait bien lieu dans les deux bras — sinon la comparaison mesurerait le balayage plutôt que le réglage.
Chaque endpoint a bougé de 17% à 46%. Un fichier statique, qui n'atteint jamais PHP, n'a pas bougé du tout — c'est le témoin, et c'est lui qui fait du reste un résultat plutôt qu'une coïncidence. La dispersion d'un bras à l'autre sur ces machines est de 1% à 13%.
Le mécanisme a ensuite été compté de trois façons distinctes : 5,862 accès au système de fichiers par requête avec la restriction activée, 214 sans elle, et 217 sur SixPanel. Avec la restriction, 400 résolutions de chemin ajoutent zéro entrée au cache de chemins de PHP ; sans elle, elles en ajoutent 509. Le cache est tout simplement désactivé, ce qui explique pourquoi le réglage de taille de cache pourtant ajusté d'aaPanel ne lui a rien rapporté.
Confirmé sur une deuxième machine, dans l'autre sens : activer la même restriction sur SixPanel a reproduit de 17 à 23 ms de temps supplémentaire par requête.
Bon à savoir si vous administrez un serveur : ce réglage se trouvait dans un fichier propre au répertoire que quatre autres emplacements n'affichaient pas. Relire la valeur depuis le processus qui sert réellement les requêtes est la seule vérification fiable.
| Endpoint | Restriction activée | Restriction désactivée | Écart |
|---|---|---|---|
/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 assetTémoin — n'atteint jamais PHP | 0.4 | 0.4 | 0% |
aaPanel utilise le mauvais mode de compilateur JIT pour cette application≈8% de l'écart
Le réglage JIT de PHP est un nombre à quatre chiffres, pas un interrupteur, et les deux modes nommés sont différents : « function » vaut 1205 et « tracing » vaut 1254. Un script de réglage qui vérifie seulement si le JIT est activé laissera tranquillement le mauvais mode en place et déclarera le travail terminé.
aaPanel livre 1205. SixPanel livre tracing. Trois paires alternées placent tracing devant sur 9 endpoints sur 9 à une requête, et 9 sur 9 à quatre en même temps — moyenne géométrique de 5.1% et 6.2%.
Prise isolément, chacune de ces différences reste dans le bruit de ces machines. Dix-huit sur dix-huit qui penchent du même côté, non.
Pour 6amMart en particulier, tracing est le bon mode : le JIT function vise les boucles numériques serrées, que ne fait pas tourner une requête Laravel.
Avoir une version de PHP de retard ne coûte rien — mesuré, pas supposé0% de l'écart
SixPanel installe le PHP que l'archive de la version apporte elle-même — 8.5 sur Ubuntu 26.04, 8.4 sur Debian 13, 8.3 sur Ubuntu 24.04 — parce que rester sur les paquets de la distribution signifie que les mises à jour de sécurité arrivent automatiquement, sans aucun dépôt tiers dans le chemin qui sert les requêtes. L'objection évidente est qu'un PHP plus récent est plus rapide.
La machine aaPanel a les deux versions installées : elle pouvait donc répondre proprement. Le pool 8.3 a d'abord reçu tout le réglage du 8.4 — il était resté sur les valeurs par défaut, ce qui aurait faussé le résultat — et les réglages ont été vérifiés depuis le processus en cours d'exécution plutôt que depuis un fichier.
Trois paires alternées : la moyenne géométrique de 8.3 contre 8.4 est de 0.9994. 8.3 était devant sur 3 lignes sur 7, et chaque différence était plus petite que la dispersion d'une passe à l'autre d'au moins un des deux bras. Le rapport d'administration lent va dans le même sens.
La règle qui garde SixPanel sur les paquets de la distribution est donc gratuite : elle ne coûte aucune vitesse. Il n'y a pas non plus de plafond à contourner : le composer.json de 6amMart déclare une borne en dessous de 8.5, mais c'est une déclaration et non une mesure, et faire tourner le code sur 8.5.4 a produit un export de tableur identique au bit près et un Laravel qui démarre, aussi bien sur l'arbre CodeCanyon brut que sur notre propre fork.
Ce qui a été vérifié et écarté comme causeSix pistes
Chacune de ces pistes est une explication plausible que quelqu'un pourrait avancer. Chacune a été mesurée et écartée.
- Le serveur web
- Chaque endpoint a été chronométré sur le réseau, puis de nouveau à l'intérieur d'un seul processus PHP, sur les deux machines. La différence est de 0 à 7 ms sur aaPanel et de 3.5 à 5 ms sur SixPanel, en majorité la négociation de chiffrement. Celle d'aaPanel n'est pas plus grande, alors même qu'il écrit une ligne de journal d'accès par requête.
- La base de données
- Temps de requête pratiquement identiques sur les trois configurations. Jeux de données à environ 1% près sur chaque table, et configurations concordantes après réglage, à l'exception du niveau de correctif.
- La façon dont PHP atteint la base de données
- Les deux passent par le socket local, vérifié depuis le processus en cours d'exécution plutôt que depuis un fichier de configuration.
- La couche de cache
- Compté plutôt que lu dans un fichier de configuration : 17.1 commandes de cache par requête sur aaPanel, 18.1 sur SixPanel. Aucun des deux ne bascule silencieusement sur le disque.
- Le cache de code compilé de PHP
- Zéro dépassement de mémoire, zéro collision de hachage et zéro redémarrage manuel sur les deux. SixPanel à un taux de succès de 99.86% avec 0% de gaspillage.
- Le matériel
- Identique jusqu'au modèle de processeur et à l'ensemble des contre-mesures de sécurité activées.
Ce qu'il y a de plus lent dans 6amMart n'est pas le serveur, et aucun panneau ne peut le corrigerCode de l'application
Les 297 pages d'administration ont toutes été chronométrées sur le vrai jeu de données de 66,701 commandes. 290 d'entre elles répondent en moins de 300 ms. Le panneau n'est pas globalement lent.
Sept pages concentrent tout le problème. La pire, le rapport de transactions par jour, prend 20.86 secondes, dont 12.43 secondes passées à l'intérieur du pilote de base de données — et une seule requête s'exécute 122 fois à 87.6 ms chacune, soit 10.7 secondes à elle seule.
Le problème est présent sur chaque serveur testé et n'a été modifié par aucun des réglages essayés, y compris la passe de réglage complète d'aaPanel : 20,925 ms avant, 20,470 ms après.
C'est le code de 6amMart lui-même : aucun panneau de contrôle ne peut le corriger, et aucun ne devrait prétendre le faire. Il est documenté en entier au niveau de l'application elle-même, et c'est exactement le genre de chose que notre service d'installation 6amMart existe pour traiter.
Tout ce que nous publions
Tous les rapports, au même endroit
Aucun chiffre de cette page n’est isolé — chacun vient d’un rapport publié avec sa méthode, ses réserves, et les résultats qui ne nous flattent pas. Lisez-les avant d’acheter ; ils sont là pour ça.
SixPanel vs aaPanel
1.76× plus rapide sur une requête, 1.82× sur quatre arrivant ensemble — face à un aaPanel entièrement optimisé, avec la cause décomposée et 32% de l’écart honnêtement étiqueté comme inexpliqué.
SixPanel vs SixPanel Docker vs aaPanel
Trois panels sur un matériel identique et une boutique identique à l’octet près — la méthode complète derrière les chiffres mis en avant.
SixPanel vs CloudPanel
Un match honnête : CloudPanel est un bon logiciel généraliste. La question est de savoir quel problème vous résolvez.
SixPanel vs un serveur nu
Ce que le panel ajoute au serveur monté à la main par lequel la plupart des propriétaires commencent — et ce que cela coûte sur un an.
Quel système d’exploitation
Ubuntu 26.04 contre Ubuntu 24.04 contre Debian 13, mesurés : la vitesse est à égalité, les fenêtres de support non.
Quel moteur de base de données
Cinq moteurs face à une vraie boutique. MariaDB 11.8 et 10.11 sont à égalité à l'échelle de l'application ; les deux MySQL ne peuvent pas la faire tourner sans modification.
6amMart optimisé — les résultats mesurés
Le bandeau vedette 22× plus rapide, l’audit des 297 pages d’administration, un rapport de 17.5 secondes ramené à 0.7 — avec les deux pages laissées lentes à dessein, publiées à côté des victoires.
Le test d’échelle
66,701 commandes réelles, 113,231 lignes de commande — le jeu de données où les défauts silencieux ont fait surface.
Défauts corrigés
Ceux qui coûtent de l’argent sans jamais afficher d’erreur — coupons, horloges, stock, paiements en double.
Ce qui reste ouvert
La page qui donne leur valeur aux quatre autres : ce que nous n’avons pas résolu, énoncé sans détour.
Le changelog
Chaque version, y compris les erreurs et ce qu’elles nous ont appris.
Ce que vous obtenez vraiment
Regroupé comme un acheteur pense au travail à faire
Deux points portent une réserve explicite. Le transfert depuis un ancien serveur et la restauration sur la même machine ont été vérifiés par relecture du code lors de la série du 15 août, sans être exécutés. Ils sont signalés ci-dessous. Tout le reste ici a été exercé ou est une surface livrée et inspectable — mais la forme honnête de la phrase est « c'est livré », pas « cela a été prouvé sur votre type de serveur ».
Le mettre en route
D'un serveur loué à une connexion au panneau, sans pile construite à la main.
- Une seule commande. La commande d'installation est téléchargée, comparée à une empreinte publiée, et seulement ensuite exécutée. Si les empreintes ne correspondent pas, la commande s'arrête et rien n'est installé.
- Elle refuse un serveur sur lequel elle ne peut pas tourner, en le nommant, avant de télécharger quoi que ce soit : mauvais système d'exploitation, mauvais type de processeur, trop peu de mémoire, un autre panneau de contrôle présent, ou quelque chose qui utilise déjà le port 80 ou 443.
- Un assistant de configuration à la première connexion : bases → mot de passe → domaine → SSL → application → sauvegardes.
- Autoréglage à l'installation, et à la demande ensuite. Il dimensionne la base de données, le cache et les workers PHP d'après la machine réelle.
- Fait tourner une boutique entière sur 2 cœurs et 4 GB.
- Vérifié par relecture, non exécuté: Ou déplacez une boutique existante. SixPanel peut récupérer une installation en production depuis un ancien serveur via SSH — le fichier de configuration, les fichiers envoyés, et un export de base transféré directement. Non exercé lors de la série du 15 août, vérifié par relecture seulement. Testez-le sur un serveur de rechange avant d'en dépendre, et gardez l'ancienne machine jusque-là.
Pourquoi c’est important : le premier jour est celui où la plupart des boutiques perdent une semaine — celui-ci se termine sur une page qui fonctionne.
Votre domaine et HTTPS
De vrais certificats, renouvelés pour vous, et Cloudflare géré correctement.
- Certificats Let's Encrypt gratuits, renouvelés automatiquement par une tâche quotidienne.
- Plusieurs domaines par boutique, par cible (admin, boutique, websocket), chacun avec ses propres indicateurs principal, SSL et Cloudflare.
- Compatible Cloudflare. Il tente d'abord un vrai certificat Let's Encrypt à travers le proxy Cloudflare, ce qui fonctionne avec Full (strict). Si ce n'est pas possible, il se rabat sur un certificat d'origine auto-signé de 10 ans, qui nécessite Full. Il embarque les plages d'adresses de Cloudflare pour que vos journaux montrent l'adresse réelle du visiteur, pas celle de Cloudflare.
- Un jeton Cloudflare, et le panneau gère pour vous un ensemble d'options Cloudflare. Il affiche le souhaité face au réel pour chaque élément, et une synchronisation en envoi ou en réception. Vos propres règles survivent à une écriture.
- Une page pare-feu qui affiche les règles exactes pour votre serveur, ainsi que les deux listes de plages Cloudflare et les commandes pour les vérifier. Le panneau ne touche jamais lui-même au pare-feu de votre hébergeur.
Pourquoi c’est important : les pannes HTTPS sont le tueur silencieux classique — un certificat qui expire un samedi emporte la boutique avec lui.
Livrer des changements de code
Deux types de mise à jour qui ne sont jamais confondus l'un avec l'autre.
- Pousser pour déployer. Un webhook signé depuis votre hébergeur git lance le déploiement.
- Déploiements → Mise à jour fait évoluer votre code 6amMart. Paramètres → auto-mise à jour fait évoluer SixPanel. Ni l'un ni l'autre ne touche à votre fichier de configuration, à votre dossier data/ ou à votre base de données.
- Historique et retour arrière, avec les 30 derniers déploiements conservés.
- Un garde d'arborescence propre. Si vous avez modifié des fichiers sur le serveur, la mise à jour refuse et nomme les fichiers au lieu d'écraser votre travail.
Pourquoi c’est important : les minutes les plus risquées d’une boutique sont celles qui suivent « déployer » — ici, elles deviennent ennuyeuses.
Ne rien perdre
Planifiées, incrémentales, et prouvées une fois par semaine au lieu d'être supposées.
- Sauvegardes incrémentales (restic), planifiées, avec rétention.
- Quatre destinations : le même serveur, S3, SFTP, ou Google Drive.
- Un test de restauration automatique hebdomadaire dans une base jetable — vos données en production ne sont jamais touchées, et le résultat apparaît à la fois sur la page Sauvegardes et sur la page Santé.
- Une sauvegarde contient la base de données de chaque projet, les fichiers envoyés et le fichier de configuration de l'application. Elle ne contient pas votre code — celui-ci revient depuis git.
- Un seul mot de passe de sauvegarde partagé, généré une fois et conservé dans l'état du panneau. Perdez-le et plus aucune sauvegarde ne pourra jamais être ouverte.
- Vérifié par relecture, non exécuté: La restauration a été vérifiée par relecture, non exécutée, lors de la série du 15 août. Voyez aussi les deux limites de restauration plus bas — elles sont la raison pour laquelle cela compte.
Pourquoi c’est important : une sauvegarde jamais ouverte est un espoir, pas une sauvegarde. Le test de restauration hebdomadaire fait toute la différence.
Le faire tourner au quotidien, sans être administrateur système
Le panneau nomme le problème et vous donne le bouton.
- Page Santé : environ 20 vérifications, triées en « à traiter », « en bon état » et « information », chacune avec une phrase de conséquence et un bouton de correction. Chaque vérification est plafonnée à 2 secondes et la page entière à 10 secondes, donc une vérification bloquée ne peut pas bloquer la page.
- Trois sources ne s'accordent pas sur ce nombre. Le manuel livré dit « plus de vingt », l'inventaire du code compte environ 20 vérifications, et une ancienne spécification de page dit environ quinze. Cette page affiche environ 20 — le plus bas des deux chiffres appuyés sur le produit livré.
- Un chien de garde qui redémarre les conteneurs cassés. Docker ne redémarre pas un conteneur qui tourne mais ne fonctionne pas, parce que unless-stopped ne se déclenche jamais sur un contrôle de santé en échec. La boucle propre à SixPanel, si, et les contrôles de santé testent le travail plutôt que la simple présence du processus.
- Un moteur de tâches. Une longue tâche à la fois, les autres attendent. Le journal défile en direct dans le navigateur. Les 20 dernières tâches sont conservées, 2,000 lignes chacune.
- Un éditeur de fichier de configuration pour votre application, qui conserve vos commentaires, votre ordre et vos lignes sans rapport, donne à chaque clé le bon type de champ, et marque en lecture seule les clés qui appartiennent à la pile.
- Un gestionnaire de fichiers clôturé à exactement deux dossiers : votre code admin et votre code de boutique.
- phpMyAdmin à la demande — démarré et arrêté depuis la page Base de données, jamais laissé en marche.
- La capture des requêtes lentes, que vous pouvez activer et vider depuis la page Base de données.
- Une commande sixpanel sur le serveur, avec une page de manuel, un aide-mémoire, un menu numéroté, un correcteur « vouliez-vous dire » et la complétion dans le shell.
- Le manuel client complet dans le panneau, derrière la même connexion — 24 pages de tâches.
- Un paquet de diagnostic en une commande. Il rassemble les versions, les résultats de santé, l'état des services, l'utilisation disque et les 500 dernières lignes de chaque journal. Avant écriture, votre fichier de configuration est réduit aux seuls noms de clés, le fichier d'état du panneau n'est pas collecté du tout, et le code secret de votre lien de panneau ainsi que les valeurs qui ressemblent à des mots de passe sont masqués.
Pourquoi c’est important : le panel que vous ouvrez réellement chaque jour devrait répondre à « tout va bien ? » d’un coup d’œil, pas en une heure.
Laisser entrer d'autres personnes
Un accès limité dans le temps plutôt que de donner votre mot de passe.
- Des identifiants temporaires pour un développeur : leur propre nom et mot de passe, expirant après 1 heure, 8 heures, 24 heures ou 7 jours, jusqu'à 20 actifs en même temps. Le mot de passe est affiché une seule fois. Ils peuvent faire tourner le site. Ils ne peuvent pas changer qui a accès, et ne peuvent pas lire vos secrets.
- Un identifiant de démonstration en lecture seule pour montrer le panneau à quelqu'un. Sessions de deux heures, toute écriture refusée, valeurs sensibles masquées.
- Un journal d'activité, et une liste des sessions actives que vous pouvez révoquer une par une ou toutes d'un coup.
- Vérifié par relecture, non exécuté: Le journal d'activité ne couvre pas tout. La création, la modification et le lancement manuel d'une tâche planifiée sont tous enregistrés, mais la suppression n'écrit aucune trace d'audit.
Pourquoi c’est important : la plupart des intrusions dans un panel n’ont rien d’astucieux — c’est un mot de passe deviné sur une page de connexion visible. Celle-ci n’est pas visible.
Plusieurs boutiques sur un serveur
Séparées par construction, pas par convention.
- Chaque projet a ses propres conteneurs, sa propre base de données et son propre utilisateur de base, son propre dossier d'application, son propre vhost, et sa propre base de cache Redis — donc vider le cache d'une boutique ne peut jamais vider celui d'une autre.
- Deux projets ne peuvent pas finir par partager une base de données : le nom est dérivé d'un identifiant court validé et unique.
- Prévoyez environ 2 GB de RAM en plus et 1–2 cœurs en plus par boutique supplémentaire — budgétez 2 cœurs, le haut de cette fourchette, puisque le sous-dimensionnement est l'erreur coûteuse.
Pourquoi c’est important : la deuxième boutique d’une agence ne devrait pas pouvoir lire les données de la première, même en théorie — ici, c’est le noyau qui l’impose, et nous l’avons attaqué pour le vérifier.
Une vitesse déjà configurée
Un micro-cache de cinq secondes dans le conteneur nginx de votre propre serveur, taillé sur les schémas de requêtes propres à 6amMart.
- Un micro-cache FastCGI de cinq secondes dans nginx, sur une liste fixe d'endpoints publics du catalogue. Si 100 requêtes arrivent sur l'endpoint de configuration dans une même fenêtre de cinq secondes, le cache les transforme en un seul démarrage PHP au lieu de 100 — c'est de l'arithmétique tirée de la fenêtre de cache, pas un résultat de débit mesuré. Le stockage est plafonné à 64 MB dans le conteneur nginx, avec éviction après 60 secondes d'inactivité.
- Pourquoi cela compte ici en particulier : la boutique est rendue sur le serveur, donc chaque page vue par un acheteur devient plusieurs appels API vers la même machine, et chaque démarrage à froid de l'app mobile encore 15–20 appels API.
- Il ne sert jamais une réponse personnelle ou authentifiée. Tout en-tête Authorization le contourne. Tout cookie, quel qu'il soit, le contourne. nginx refuse de stocker toute réponse portant un Set-Cookie. Une liste d'exclusion séparée couvre l'admin, le panneau vendeur, la connexion, le paiement, le panier, les commandes et les rappels de paiement.
- La zone, le module et la langue font partie de la clé de cache, donc les boutiques d'une ville ne peuvent jamais être servies à une autre ville.
- Il garde la boutique en ligne quand PHP ne l'est pas. Si le pool PHP se bloque, nginx sert la copie légèrement périmée et la rafraîchit en arrière-plan — une boutique qui marche au lieu d'un mur d'erreurs 502.
- Tout le reste suit aussi le matériel : la base de données, le cache de code compilé de PHP, la mémoire du cache et les tampons du serveur web sont tous dimensionnés par l'autoréglage d'après la machine réelle.
- Des paliers de débit de requêtes taillés pour les réseaux réels. Limites serrées sur la connexion, l'OTP et la réinitialisation de mot de passe ; plus larges pour la navigation ordinaire ; distinctes pour la recherche et pour les écritures de panier et de commande. La documentation appelle cela par son nom — un bouclier contre les rafales de requêtes, pas une protection DDoS — parce que des limites par adresse ne peuvent pas être précises quand toute une ville partage une seule adresse IP d'opérateur.
- « Bordure » sur ce site veut dire Cloudflare, qui est la vraie couche de bordure. Ce cache n'est pas cela, et n'est pas appelé ainsi.
Pourquoi c’est important : la vitesse est la seule chose qu’un client ressent à chaque visite — et la raison pour laquelle ces chiffres sont publiés avec leur méthode.
Éléments optionnels
Activez-les quand la boutique en a besoin.
- Suivi de commande en direct par websockets (Reverb).
- Le site web client Next.js optionnel, avec ses fichiers statiques servis comme immuables.
- Vendre uniquement via les apps mobiles, sans site web, est une configuration prise en charge.
Pourquoi c’est important : les outils dont on a rarement besoin ne devraient rien coûter au repos — ceux-ci démarrent à la demande puis s’effacent.
Bilan de la boutique (SixPreflight, inclus)
Il vérifie les réglages à l'intérieur de votre boutique, par opposition au serveur dont SixPanel s'occupe.
- SixPreflight est intégré et monté dans le panneau comme page Bilan de la boutique. Il porte environ 134 vérifications, un score pondéré et une note en lettre.
- Pourquoi 134 et pas un nombre plus grand : trois sources internes donnent trois réponses. Un comptage direct des clés de vérification uniques dans le code donne 163 ; le document de remise technique note 134–136 et demande de retenir le plus bas des deux ; une ancienne spécification de page dit environ 100. Cette page affiche ~134, le chiffre le plus bas qu'une source actuelle défend.
- Quand il tourne dans SixPanel, il change de comportement exprès : les blocs de configuration à copier-coller disparaissent pour les couches que le panneau gère, et les réglages qui relèvent du panneau admin de votre boutique sont notés séparément du serveur.
Pourquoi c’est important : le serveur peut être parfait pendant qu’un mauvais réglage dans la boutique coûte discrètement des commandes — une seconde paire d’yeux lit ces réglages-là.
Ce qui tourne tout seul
L’automatisation, cartographiée
« Automatisé » est un mot facile à imprimer. Voici chaque tâche que le panel exécute sans vous — ce qui la déclenche, et ce que vous feriez autrement à la main, à minuit.
- Une fois, au départ
Le serveur entier, en une commande
Un simple copier-coller sur un serveur Ubuntu vierge installe le serveur web, la base de données, PHP, le cache, le worker de queue, le scheduler, le serveur websocket et le panel lui-même — chacun dimensionné pour la machine qui le reçoit. Vous saisissez un domaine ; tout le reste est mis en place, configuré et démarré.
- Avant chaque expiration
Un HTTPS qui se renouvelle tout seul
Les certificats s’émettent automatiquement — via DNS quand Cloudflare gère le domaine, donc ils fonctionnent avant même que la machine soit joignable depuis Internet — et chaque renouvellement recharge le serveur web par un hook propre à chaque certificat : un certificat cassé ne peut jamais bloquer les autres.
- Selon votre planning
Des sauvegardes qui tournent vraiment
Des sauvegardes incrémentales au rythme que vous fixez, vers le même serveur, S3, SFTP ou Google Drive, avec la rétention appliquée après chaque exécution. La base de données, les fichiers uploadés et les réglages de chaque projet — le code, lui, revient depuis git.
- Chaque semaine
Un test de restauration, pas un message de succès
Une fois par semaine, le panel restaure la sauvegarde la plus récente dans une base jetable et compte les lignes. Une sauvegarde qui ne peut pas réellement s’ouvrir fait passer la page Santé au rouge — parce qu’un message de succès n’est pas une preuve.
- Toutes les quelques minutes
L’auto-réparation des pannes silencieuses
Le watchdog redémarre un service qui tourne mais ne fonctionne plus — le cas qu’un superviseur ordinaire rate complètement, puisque rien n’a planté. Chaque redémarrage qu’il effectue apparaît dans le journal d’activité, avec sa raison.
- Install et mise à jour
Un réglage à la taille de la machine
Le buffer pool de la base, la mémoire du cache, la taille des tables temporaires et les workers PHP sont calculés à partir de la mémoire et des cœurs réels de la machine — une seule échelle de dimensionnement, mesurée sur 36 gabarits de serveurs, appliquée à l’identique par l’installateur et par le panel.
- Chaque nuit
L’entretien de la base de données
Un passage nocturne purge les lignes expirées que l’application elle-même ne supprime jamais, et le dimanche les tables sont optimisées — seulement quand l’espace disque le permet, et avec chaque résultat inspecté plutôt que supposé.
- À chaque déploiement
Des index mesurés, maintenus en place
Un lot d’index de base de données — chacun mesuré sur une vraie boutique de 66,701 commandes avant d’être admis — est vérifié et réappliqué après chaque changement de code. Vérifié par ce que chaque index couvre, pas par son nom : un index renommé ne peut pas le tromper.
- À chaque git push
Du push au déploiement, de bout en bout
Poussez sur votre dépôt et la boutique se met à jour toute seule : pull, dépendances, migrations de base de données, cache de configuration reconstruit uniquement là où c’est mesuré comme sûr pour votre code exact, PHP rechargé sans perdre une requête. Un bouton de rollback conserve la version précédente.
- En continu
Des contrôles de santé qui nomment le correctif
Plus de trente contrôles tournent chacun à leur rythme — services, disque, certificats, DNS, Cloudflare, les fichiers du panel comparés à la release qui les a livrés. Une ligne en échec nomme le correctif exact, pas seulement le problème.
- Quand il faut agir
Des e-mails qui respectent votre boîte
Au plus un e-mail par problème toutes les six heures, avec un verdict coloré lisible depuis l’aperçu de la boîte de réception — et un « résolu » vert quand le problème disparaît, pour que le silence n’ait jamais à être interprété.
- Quand vous le décidez
Mises à jour en un bouton, à signature vérifiée
Un bouton récupère la release, vérifie sa signature contre la clé épinglée sur votre serveur — un hôte de téléchargement remplacé ne peut pas imposer une nouvelle clé à votre machine — l’applique, puis redémarre les services dans un ordre mesuré qui garde la boutique en ligne.
Le motif derrière tout cela : le panel fait le travail, note ce qu’il a fait, et vérifie son propre résultat — et ce qu’il ne peut pas vérifier, il le signale au lieu de l’affirmer.
Sous le capot
Une ingénierie avancée qui tourne toute seule
Rien de tout cela n’est une case dans une liste de fonctionnalités. Chaque élément est une vraie mécanique au comportement mesuré, aux règles de sécurité strictes, avec un rapport que vous pouvez lire.
Superviseur auto-réparateur
Une boucle de 60 secondes répare ce qui casse vraiment les boutiques en production : une file bloquée, un certificat expiré, un mode maintenance oublié. Encadré par des règles strictes — il ne démarre jamais ce que vous avez arrêté et n’agit jamais pendant un déploiement ou une sauvegarde.
Sauvegardes incrémentales et chiffrées
Bâti sur restic : chaque exécution ne stocke que le nouveau ou le modifié depuis la précédente, dédupliqué et chiffré — les sauvegardes quotidiennes restent rapides et légères et chaque snapshot se restaure intégralement. Destinations : disque local, S3, SFTP, Google Drive.
Des sauvegardes prouvées, pas supposées
Un job de sauvegarde au vert n’est pas une preuve. Une vérification planifiée ouvre le snapshot le plus récent et vérifie que le dump de votre base y est réellement — la réponse honnête à « puis-je restaurer ? » vient de l’artefact, pas du code de sortie.
Réglé sur votre serveur, automatiquement
Une échelle de dimensionnement mesurée calcule le buffer pool de la base, la mémoire Redis et le nombre de workers PHP à partir de la RAM et du CPU de votre machine — à l’installation, puis à chaque redimensionnement. L’installateur et le panneau partagent une définition unique, tenue par un gate de build.
Un micro-cache prouvé sûr
Les endpoints chauds de l’API répondent depuis le cache nginx — de 16,9 ms à 0,6 ms, mesuré — mais seuls entrent les endpoints prouvés indépendants de l’appelant : un gate statique lit les handlers de l’app et une sonde vive à trois bras confirme qu’aucun client ne peut jamais voir les données d’un autre.
Chaque projet totalement isolé
Chaque boutique a son propre utilisateur unix, son propre pool PHP-FPM et sa propre instance Redis protégée par mot de passe ; ses workers tournent dans un sandbox systemd, système en lecture seule, sans escalade de privilèges. Un projet compromis ne peut pas en lire un autre.
Mises à jour signées cryptographiquement
Chaque version embarque un manifeste signé ed25519 avec date d’expiration. Le panneau refuse tout ce qui est non signé, périmé ou signé avec la mauvaise clé — et une clé renouvelée doit faire ses preuves contre la version avant d’être approuvée.
Il lit votre application avant d’agir
Le panneau n’affirme rien à l’aveugle. La mise en cache de la configuration se décide en lisant le code de votre propre 6amMart : une build qui lit ses réglages à l’exécution ne casse jamais en silence. Le code CodeCanyon intact et la build optimisée reçoivent tous deux la bonne réponse.
Auto-réparation, sauvegardes incrémentales, mises à jour signées — vous ne configurez rien de tout cela. C’est simplement ainsi que le panneau est construit.
Pourquoi ça paraît simple
La simplicité est une décision de conception, pas une couche de peinture
Rien de tout cela n’est un mode simplifié qui cache les vrais réglages. Ce sont les vrais réglages, arrangés pour que l’étape suivante soit toujours évidente.
Un copier-coller, aucun prérequis
Pas de Docker à apprendre, pas de fichiers compose, pas de folklore SSH. La stack, ce sont les paquets d’Ubuntu supervisés par systemd, et une seule commande met tout en place.
Un assistant qui propose ses propres réponses
Six étapes — bases, mot de passe, domaine, HTTPS, application, sauvegardes. Chaque étape propose la réponse raisonnable ; l’essentiel de l’installation consiste à confirmer, pas à décider.
Saisissez un domaine, obtenez tout le plan
À partir d’un seul domaine, le panel planifie les hôtes du tableau de bord, de la vitrine et du websocket, les enregistrements DNS à créer, et lesquels doivent passer par le proxy Cloudflare. Les noms qui casseraient silencieusement le HTTPS sont refusés, avec en retour l’orthographe qui fonctionne.
Les problèmes arrivent avec leur correctif
Pas de simple « échec ». Une ligne rouge vous indique le réglage, le fichier ou le bouton exact qui la résout — la différence entre une tâche à faire et un mystère.
Chaque action est un job que vous pouvez suivre
Installations, déploiements, sauvegardes et correctifs s’exécutent comme des jobs avec des logs en direct. Les boutons affichent un spinner pendant qu’ils travaillent, et un job refuse d’annoncer un succès tant que sa propre re-vérification n’est pas passée.
Le manuel vit dans le panel
Chaque lien d’aide mène à la page qui parle exactement de ce que vous regardez. Le même manuel est livré avec le téléchargement et publié sur ce site.
Une ligne de commande pour les mauvais jours
Une commande sixpanel sur le serveur reflète le panel — avec sa page man et sa complétion shell — pour le jour où le navigateur n’est pas une option.
Il parle votre langue
Huit langues. Arrivez depuis ce site et le panel s’ouvre dans la langue que vous étiez en train de lire ; suivez un lien dans l’autre sens et le site fait de même.
Les trois choses que personne d'autre ne fait
Trois affirmations, chacune avec la raison pour laquelle elle est vraie plutôt qu'un adjectif
Nous nous sommes comparés à un concurrent entièrement réglé, et nous avons publié d'où vient l'avantage
N'importe qui peut publier un banc d'essai qu'il a gagné. Le test qui vaut la peine d'être mené est celui où l'autre camp est correctement configuré — la machine aaPanel a donc d'abord été réglée : cache de code compilé doublé, buffer pool de la base quatre fois et demie plus grand, workers corrigés d'un 50 surengagé à un 14 dimensionné. Son PHP 8.4 et son compilateur JIT ont été délibérément laissés activés, parce que ce sont ses avantages.
L'écart ne s'est pas refermé. 1.65× / 1.80× face à la machine telle qu'elle est livrée ; 1.76× / 1.82× face à la machine réglée. Il s'est légèrement déplacé dans l'autre sens.
La différence a ensuite été décomposée une variable à la fois. Environ 60% vient d'une seule restriction de répertoires PHP, environ 8% du mauvais mode de compilateur JIT, et la version de PHP ne vaut exactement rien. Environ 32% reste inexpliqué, et c'est publié comme inexpliqué plutôt que porté à notre crédit.
Pourquoi cela compte : Un rapport sans cause derrière lui est un chiffre marketing. Celui-ci a une cause mesurée pour deux tiers de lui-même, et un aveu pour le reste.
Nous avons mesuré trois systèmes d'exploitation, obtenu une égalité, et publié l'égalité
Trois serveurs du même hébergeur, commandés ensemble, identiques sauf le système d'exploitation. Mêmes conteneurs, mêmes réglages, mêmes données — la base d'une vraie boutique avec 66,701 commandes.
Ils sont à égalité. L'écart entre les trois machines (3.5 %) était plus petit que l'écart d'une machine avec elle-même sur deux séries de sa propre configuration (8.6 %).
La recommandation s'est donc décidée sur la durée pendant laquelle chaque système continue de recevoir des mises à jour de sécurité, pas sur la vitesse. Et le rapport a écarté ses propres lignes les plus flatteuses parce qu'elles étaient arithmétiquement impossibles.
Pourquoi cela compte : La volonté de publier un résultat négatif est la preuve que la méthode est réelle. N'importe qui peut publier un test qu'il a gagné.
Cache et limites taillés sur les schémas de requêtes propres à 6amMart
Le micro-cache nginx est à la portée de tout le monde. Ce qui est propre à ce produit, c'est tout ce qui l'entoure, et rien de tout cela ne peut être écrit par quelqu'un qui ne connaît pas cette application :
- La liste d'autorisation précisant exactement quels endpoints publics peuvent être mis en cache, comparée sur l'URI brute, avec refus par défaut.
- La zone, le module et la langue dans la clé de cache, parce que 6amMart sert des boutiques différentes à des villes différentes depuis la même URL.
- Cinq règles de contournement qui rendent impossible la mise en cache d'une réponse personnalisée.
- Des paliers de débit de requêtes qui séparent la connexion et l'OTP de la navigation, de la recherche, des écritures de panier.
- Des délais d'expiration volontairement alignés entre eux — PHP 120 s, lecture nginx 120 s, arrêt du worker 130 s — parce que 6amMart exécute des exports Excel, des imports en masse et de lourds rapports de boutique à l'intérieur de la requête web plutôt qu'en tâche de fond.
Pourquoi cela compte : Une rafale de recherches non authentifiées pouvait auparavant remplir le serveur de cache et commencer à évincer des sessions, déconnectant silencieusement des acheteurs connectés. Il fallait environ 278 requêtes, à peu près 67 secondes sur une seule connexion, sur une machine de test à deux projets de 8 GB. Cela a été mesuré, borné, puis mesuré de nouveau sur la même machine — sur les trois rafales que le fichier de preuves tabule, zéro éviction, session vivante à chaque fois.
SixPanel comparé
SixPanel comparé à aaPanel, CloudPanel, et au fait de tout faire à la main
C'est une comparaison pour une seule tâche : faire tourner une boutique 6amMart. Ce n'est pas une comparaison de ces panneaux en général, et il serait malhonnête de la présenter comme telle.
Exactement ce que nous avons sur les deux concurrents, énoncé précisément
Le tableau a 13 lignes et deux colonnes concurrentes, soit 26 cases concurrentes. Trois de ces 26 disent autre chose que « non testé par nous », et les voici une par une :
- Une case rapporte quelque chose que nous avons vu faire le produit d'un concurrent. aaPanel remet silencieusement la racine du site à sa valeur d'origine dès qu'un réglage du site est enregistré — constaté sur une installation en production. C'est la ligne Racine du site, colonne aaPanel.
- Deux cellules reposent sur le comportement d'un tiers que nous avons vérifié, non sur un test des panneaux. Ni l'archive d'Ubuntu 26.04 ni celle de Debian 13 ne contient MariaDB 10.11, et les deux panneaux installent la base de données depuis les paquets de l'hôte — sur ces versions, ils ne peuvent donc pas fournir cette version-là. L'environnement natif de SixPanel prend 11.8 dans la même archive à la place, et SixPanel Docker embarque 10.11 dans son image. C'est la ligne MariaDB 10.11, dans les deux colonnes concurrentes.
- Les 23 cases concurrentes restantes disent toutes « non testé par nous ». C'est la formulation littérale, dans chacune d'elles — compté, pas supposé.
- Les 24 cellules concurrentes restantes disent toutes « non testé par nous ». C'est la formulation littérale, dans chacune d'elles — comptées, pas supposées.
Nous n'affirmons rien sur l'ancienneté de l'un ou l'autre concurrent. Aucune source de cet ensemble n'établit l'âge de l'un ou l'autre produit, donc aucune affirmation de ce type n'apparaît. Ce que la ligne Antériorité peut honnêtement dire, c'est seulement ce que nous savons de notre propre ancienneté.
Nous n'avons jamais comparé les performances de SixPanel à celles d'un autre panneau, et cette page ne fait aucune comparaison de vitesse entre eux.
| Pour la tâche de faire tourner 6amMart | SixPanel | aaPanel | CloudPanel | Serveur nu, à la main |
|---|---|---|---|---|
| Ce pour quoi c'est conçu | Une seule application — 6amMart | Hébergement web polyvalent — non testé par nous ; lisez la liste de fonctionnalités de l'éditeur | Hébergement web polyvalent — non testé par nous ; lisez la liste de fonctionnalités de l'éditeur | Ce que vous construisez |
| Vitesse, même matériel et même boutique | Mesuré : 1.76× plus rapide qu'un aaPanel entièrement réglé sur une requête, 1.82× avec quatre à la fois, sur les endpoints qui atteignent PHP des deux côtés | La comparaison ci-dessus. Nous l'avons installé, réglé, et avons laissé en place son PHP 8.4 et son JIT | Non testé par nous — aucune affirmation de vitesse n'est faite à son sujet | Ce que votre ingénieur obtient |
| MariaDB 10.11 sur Ubuntu 26.04 / Debian 13 | Avec l'environnement Docker, oui — l'image est figée sur 10.11 quel que soit l'hôte. L'environnement natif prend MariaDB 11.8 dans les archives de ces versions à la place, et mesurée contre 10.11 sur la même boutique, c'est une égalité. | Non disponible. Aucune des deux versions ne contient 10.11 dans son archive, et ce panneau installe depuis les paquets de l'hôte | Non disponible — même raison | Seulement si vous utilisez vous-même des conteneurs |
| Autres sites web, e-mail, DNS, FTP sur la même machine | Non. L'installateur refuse un serveur qui fait déjà tourner aaPanel, CloudPanel, cPanel ou Plesk, ou qui a quelque chose sur les ports 80/443 | Ils gagnent ici. C'est à cela que servent les panneaux généralistes — non testé par nous ; vérifiez chez l'éditeur | Ils gagnent ici — non testé par nous ; vérifiez chez l'éditeur | Possible, et entièrement votre problème |
| Utilisateurs, rôles, équipes | Non. Un seul compte administrateur. Plus des identifiants temporaires et un identifiant de démonstration en lecture seule | Ils gagnent ici. Non testé par nous ; vérifiez chez l'éditeur | Ils gagnent ici. Non testé par nous ; vérifiez chez l'éditeur | Ce que vous configurez |
| Réglé pour cette application dès le départ | L'autoréglage écrit les workers PHP, le pool de tampons de la base de données, la mémoire du cache, les tables temporaires, les tampons et le journal redo d'après la machine réelle, de 1 cœur / 2 GB → 16 cœurs / 32 GB — et les deux endroits qui le calculent sont confrontés l'un à l'autre à chaque build | Le micro-cache nginx est disponible partout — encore faut-il que quelqu'un écrive les règles propres à 6amMart. Non testé par nous | Pareil. Non testé par nous | Ce que vous savez |
| Micro-cache taillé pour 6amMart | Intégré : liste d'autorisation, zone/module/langue dans la clé, 5 contournements, service de copie périmée quand PHP se bloque | Le micro-cache nginx est disponible partout — encore faut-il que quelqu'un écrive les règles propres à 6amMart. Non testé par nous | Pareil. Non testé par nous | Pareil |
| Sauvegardes | restic, planifiées, rétention, quatre destinations, test de restauration automatique hebdomadaire | Non testé par nous — comparez spécifiquement le test de restauration automatique | Non testé par nous — pareil | Ce que vous scriptez |
| HTTPS gratuit | Oui, avec renouvellement automatique et émission compatible Cloudflare | Non testé par nous ; vérifiez chez l'éditeur | Non testé par nous ; vérifiez chez l'éditeur | certbot, par vous |
| Déploiements | Push git ; historique et retour arrière avec les 30 derniers déploiements conservés ; refuse d'écraser vos modifications | Constaté sur une installation en production : aaPanel remet silencieusement la racine du site à sa valeur d'origine dès qu'un réglage du site est enregistré | Non testé par nous | Ce que vous scriptez |
| La racine du site reste où vous l'avez mise | Oui | Constaté sur une installation en production : aaPanel remet silencieusement la racine du site à sa valeur d'origine dès qu'un réglage du site est enregistré | Non testé par nous | À vous de bien faire |
| Antériorité | SixPanel en est à sa version actuelle, et il est récent. Nous ne pouvons pas vous montrer des années que nous n'avons pas eues | Non testé par nous ; vérifiez depuis combien de temps l'éditeur livre son produit | Non testé par nous ; vérifiez depuis combien de temps l'éditeur livre son produit | Linux a plus de 30 ans |
| Code lisible sur votre serveur | Ils gagnent peut-être ici. Le backend du panneau est livré en bytecode V8, sources lisibles retirées. Nous appelons cela de la dissuasion, pas de la sécurité | Non testé par nous ; vérifiez quel support l'éditeur propose | Non testé par nous ; vérifiez quel support l'éditeur propose | Tout est lisible |
| Qui répare quand ça casse | La page Santé nomme la correction ; paquet de diagnostic en une commande | Non testé par nous ; vérifiez quel support l'éditeur propose | Non testé par nous ; vérifiez quel support l'éditeur propose | Vous |
Il n’y a pas de ligne de prix parce qu’il n’y a pas de prix. SixPanel est gratuit, publié sur CodeCanyon, et la commande d’installation est la même commande publique pour tout le monde — aucune clé à saisir, aucun code à coller, aucune inscription. La première installation et configuration est gratuite aussi. Les mises à jour arrivent par CodeCanyon, et le panneau peut également se mettre à jour lui-même.
Quand aaPanel ou CloudPanel est le meilleur choix
Cinq cas réels. Si l'un d'eux vous correspond, achetez le panneau généraliste et n'achetez pas celui-ci :
- 1Vous voulez plus d'un site web sur ce serveur. SixPanel prend la machine entière et refuse de la partager.
- 2Vous avez besoin d'hébergement e-mail, DNS ou FTP sur la même machine. SixPanel ne fait pas cela du tout.
- 3Vous avez besoin de plusieurs comptes personnels avec des permissions différentes. SixPanel a un seul compte administrateur et aucun rôle.
- 4Vous faites tourner autre chose que 6amMart. Chaque avantage de cette page vient de la connaissance approfondie d'une seule application.
- 5Un long historique en production est votre premier critère. SixPanel est récent. C'est une raison légitime d'attendre.
Et une pour le faire à la main : si vous avez un administrateur système, un serveur construit à la main n'est pas moins bon. Un ingénieur compétent sait régler MariaDB, écrire des règles de cache et scripter des sauvegardes. Ce que SixPanel supprime, c'est le besoin d'avoir cette personne, et le besoin de penser à tout revérifier.
Système d'exploitation
Quel système d'exploitation installer, et pourquoi la raison est la durée de support et non la vitesse
Les deux environnements d'exécution recommandent Ubuntu 26.04 LTS. Ubuntu 24.04 LTS et Debian 13 sont les deux autres versions prises en charge.
Pas parce qu'il est plus rapide. Six axes ont été mesurés sur du matériel identique — le système d'exploitation, PHP, MariaDB, nginx, Redis et le noyau — et aucun changement de version n'a produit d'écart digne d'être rapporté. Deux machines identiques au bit près ont divergé de 11,6 % l'une de l'autre sur 20 lignes sur 20 : le plancher de bruit est donc plus grand que tout effet trouvé.
L'environnement natif prend PHP, MariaDB, nginx et Redis dans l'archive de distribution de la version elle-même, et les trois versions prises en charge apportent un ensemble qui fonctionne : Ubuntu 26.04 donne PHP 8.5 et MariaDB 11.8, Debian 13 donne 8.4 et 11.8, Ubuntu 24.04 donne 8.3 et 10.11. La vitesse étant à égalité, le seul axe qui reste est la durée pendant laquelle les mises à jour de sécurité continuent d'arriver — et 26.04 est corrigé jusqu'en avril 2031.
SixPreflight recommande Ubuntu 26.04 LTS, pour la même raison que l'environnement natif.
| Choix | SixPanel | SixPreflight (sans conteneurs) |
|---|---|---|
| Recommandé | Ubuntu 26.04 LTS, dans les deux environnements | Ubuntu 26.04 LTS |
| Également pris en charge | Les deux environnements : Ubuntu 24.04 LTS et Debian 13. L'environnement Docker s'installe en plus sur Debian 12, que le natif refuse nommément | Ubuntu 24.04 LTS, Debian 13 |
| Pourquoi | La vitesse est à égalité sur les trois : ce qui décide est donc la durée de support restante — 26.04 est corrigé jusqu'en avril 2031. L'environnement natif prend PHP et MariaDB dans la version que vous choisissez. | La même raison : la base de données vient du système d'exploitation, chaque version prise en charge apporte une version qui fonctionne, et ce qu'il reste à trancher est la durée de support. |
Pris en charge n'est pas la même chose que mesuré. L'environnement natif prend en charge trois versions, et les trois ont été mesurées — Ubuntu 24.04, Ubuntu 26.04 et Debian 13. Debian 12 est refusé nommément : son support de sécurité gratuit s'est arrêté en juillet 2026. L'environnement Docker s'y installe toujours, et vous ne devriez pourtant pas y démarrer une nouvelle boutique, car le noyau, la glibc, Docker et OpenSSH viennent de l'archive de l'hôte, quoi qu'il tourne dans un conteneur.
Pourquoi tout pointe désormais dans la même direction
Une série antérieure sur les moteurs de base de données avait placé MariaDB 10.11 en tête, et cela a divisé la recommandation pendant un temps, parce que seul Ubuntu 24.04 l'apportait. Remesurée sur des machines identiques avec la même boutique de 66 701 commandes, cette division a disparu.
MariaDB 11.8 contre 10.11 sur l'application entière, c'est une égalité. Les lignes qui suggéraient le contraire ont été écartées, parce que le banc de mesure chronométrait une poignée de main chiffrée et non la base de données.
Le seul endroit où 11.8 paraissait plus lente n'effectue aucun travail.
C'était SELECT 1 — une instruction qui ne fait aucun travail, mesurée à 12 ms sur un bras contre 29 ms et 37 ms sur les deux autres. Un plancher qui varie du triple n'est pas de l'exécution de requête : MariaDB 11.8 négocie TLS sur le socket unix et 10.11 non, donc la sonde chronométrait une poignée de main. Mesuré directement, 24 ms par appel client sur 11.8 contre 6 ms avec TLS désactivé et 10 ms sur 10.11. Une boutique ne le paie jamais — mysqlnd ne négocie pas TLS sur un socket, de 0.12 à 0.21 ms par connexion.
L'ancien chiffre « 11.x est 2,7× plus lente » ne portait jamais sur 11.8.
Il venait d'une seule requête de rapport sur le modèle de coûts de MariaDB 11.0, et il est retiré en tant qu'affirmation sur l'application entière. Plus rien ne plaide donc pour figer une version plus ancienne : l'environnement natif prend 11.8 dans les archives d'Ubuntu 26.04 et de Debian 13, et 10.11 dans celle d'Ubuntu 24.04.
Une seule réponse, et ce n'est pas une réponse de vitesse. Prenez la version qui continue d'être corrigée le plus longtemps.
Comment cela a été mesuré
- Mesuré le 15 août 2026, sur la version de la pile en cours à cette date. SixPanel a livré des versions depuis, et rien dans cette section n'a été refait sur la version actuelle. C'est la date qui fixe la mesure.
- Trois serveurs du même fournisseur, commandés ensemble, identiques sauf le système d'exploitation — c'est-à-dire toutes les versions que l'environnement natif prend en charge.
- Le même processeur sur les trois : 2 × AMD EPYC 7713, 2 cœurs. RAM 3,915 / 3,910 / 3,921 MB. Disque 79 GB chacun.
- Le logiciel était identique au bit près sur les trois — MariaDB 10.11, la même compilation de PHP, le même serveur web. Cette série a été exécutée sur l'environnement en conteneurs, et c'est ce qui l'a rendue possible : il immobilise la pile, de sorte que le système d'exploitation est la seule chose qui change.
- Des données réelles, pas un jeu de test. La base d'une vraie boutique en production : un export de 410 MB restauré en 515 MB, 66,701 commandes, plus 894 MB de fichiers réellement envoyés.
- Une installation SixPanel neuve sur chaque machine, par le parcours client normal. Aucun réglage à la main — l'autoréglage a choisi chaque valeur, et il a choisi les mêmes sur les trois.
- Chauffe, puis mesure. Échantillons de chauffe écartés ; c'est la deuxième série qui est rapportée.
- Des centiles, pas des moyennes.
Requêtes par seconde — l'endpoint de recherche, 20 personnes à la fois, 30 secondes
C'est le chiffre auquel se fier.
| Système d'exploitation | Requêtes terminées | Requêtes par seconde |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
Écart entre les trois : 3.5 %. La machine sous Ubuntu 26.04 a divergé d'elle-même de 8.6 % sur deux séries de sa configuration identique — 49.6, puis 53.9.
Note arithmétique, parce qu'une page qui fait une vertu de repérer les chiffres impossibles ne peut pas afficher des pourcentages qu'un lecteur ne peut pas retrouver à partir des comptages voisins. Le rapport interne affiche l'écart à 3.7 % et l'écart avec soi-même à 8.7 %. Les deux sont arrondis vers le haut, donc cette page affiche plutôt le recalcul tronqué : (1,616 − 1,561) ÷ 1,561 = 3.5234 % → 3.5 %, et (53.9 − 49.6) ÷ 49.6 = 8.6694 % → 8.6 %. Le constat ne change pas — l'écart entre les machines reste plus petit que l'écart d'une machine avec elle-même. La colonne par seconde ci-dessus reprend l'arrondi à 1 décimale de la source : 1,616 ÷ 30 = 53.8666 et 1,595 ÷ 30 = 53.1666 se tronquent en 53.8 et 53.1, et seul 52.0 est déjà tronqué. La colonne est laissée telle que la source l'affiche pour que les deux fichiers puissent être posés côte à côte ; les pourcentages sont ceux de cette page, et ce sont eux qui sont cités.
Lisez tout ce bloc comme « environ 53 requêtes par seconde sur 2 cœurs, sur l'endpoint de recherche, à 20 utilisateurs simultanés, sur 30 secondes » — et rien de plus. Chacune de ces réserves voyage avec le chiffre partout où il est repris sur cette page.
Latence au repos — enregistrée, et délibérément non publiée
La latence en série a été mesurée sur chaque configuration : accueil de la boutique, connexion admin et les endpoints de l'API, une requête à la fois sur une machine au repos.
Ces chiffres cellule par cellule ne sont pas sur cette page, et voici pourquoi. Le rapport interne interdit tout chiffre du type « X % plus rapide » tiré de ces tableaux. Un tableau à trois colonnes de valeurs en millisecondes, c'est ce chiffre à une soustraction près : tout lecteur muni d'une calculatrice, et tout résumeur IA qui n'en a pas, produira la comparaison que le rapport écarte. Publier le tableau en ajoutant « mais ne comparez pas ces valeurs » ne fonctionne pas, parce qu'une citation garde les chiffres et laisse tomber la réserve.
- Les trois machines sont à égalité sur le chiffre qui compte, et une machine s'est contredite elle-même plus que les trois ne divergeaient entre elles.
- Une différence faible et constante est bien apparue sur la latence en série au repos d'une configuration. Elle est enregistrée dans le rapport interne et délibérément non revendiquée, pour trois raisons qui y sont exposées : c'est un coût à peu près fixe plutôt que proportionnel, ce qui est la signature d'une attente et non d'un travail ; elle disparaît complètement sous charge, c'est-à-dire exactement là où elle compterait ; et avec une seule machine par système d'exploitation, la version du noyau et la machine physique concernée ne peuvent pas être séparées.
- Les lignes de centiles sous charge de deux configurations ont été entièrement écartées.
Des lignes ont été écartées, et c'est important qu'elles l'aient été
Les centiles sous charge de la configuration Ubuntu 26.04 sont arithmétiquement impossibles. Vingt workers pendant 30 secondes font 600 secondes-worker, donc 1,616 requêtes terminées ont une moyenne arithmétique de 371 ms. Cette configuration rapportait à la fois son p50 et son p99 en dessous de cette moyenne — un p99 plus rapide que la requête moyenne. Ses deux séries le montrent, c'est donc systématique sur cette machine, pas un échantillon isolé.
Prises au pied de la lettre, ces lignes feraient paraître cette machine nettement meilleure sous charge. Elle ne l'est pas — son nombre de requêtes terminées est à moins de 3.5 % des autres. Les deux valeurs de centiles elles-mêmes ne sont pas publiées sur cette page : le rapport interne écarte les chiffres de latence sous charge d'Ubuntu 26.04 en bloc. L'arithmétique ci-dessus suffit à montrer pourquoi ils ont été écartés, et c'est le fait de les écarter qui compte.
Le banc d'essai porte désormais un contrôle croisé fondé sur la loi de Little, pour qu'un échantillon corrompu se signale au lieu de devenir un titre.
La base de données, sur le vrai jeu de données de 515 MB
Lisez la réserve avant les chiffres. Chaque différence entre machines dans ce tableau tombe à l'intérieur de la plage 85–125 ms qu'Ubuntu 24.04 obtient d'une série à l'autre sur les trois mêmes requêtes. Les colonnes ne sont pas un classement ; ce sont trois échantillons d'un même nombre. Le vrai constat est la dernière ligne.
| Requête | Ubuntu 24.04 | Ubuntu 26.04 | Debian 13 |
|---|---|---|---|
| Compter toutes les commandes | 120 ms | 96 ms | 106 ms |
| Compter toutes les lignes de commande | 102 ms | 102 ms | 110 ms |
| Commandes jointes aux lignes de commande, 50 lignes | 85 ms | 80 ms | 81 ms |
| Taux de succès du buffer pool | 99.991 % | 99.989 % | 99.987 % |
La dernière ligne est le constat : une base de 515 MB dans un buffer pool de 1,024 MB signifie qu'environ 99.99 % des lectures sont servies depuis la mémoire, et que cette charge de travail cesse de lire le disque une fois chaude.
Combien de temps l'installation a pris
| Système d'exploitation | Installation sans surveillance | Problèmes |
|---|---|---|
| Ubuntu 24.04 | 303 s | aucun |
| Ubuntu 26.04 | 281 s | aucun |
| Debian 13 | 273 s | git est absent de l'image minimale, ce qui cassait le clone net — trouvé ici, corrigé ici |
303 s font cinq minutes et trois secondes, et c'est pourquoi cette page dit « environ cinq minutes » et non « moins de cinq minutes ».
Pourquoi avril 2031 a tranché
La vitesse étant à égalité, le critère décisif est la durée pendant laquelle chaque système continue de recevoir des mises à jour de sécurité. Un système d'exploitation en fin de support est le seul événement qui oblige à reconstruire entièrement le serveur — et reconstruire le serveur est la seule chose que SixPanel ne peut pas faire à la place de son propriétaire.
| Système d'exploitation | Support de sécurité gratuit jusqu'à | Durée restante depuis août 2026 |
|---|---|---|
| Ubuntu 26.04 LTS | avril 2031 | 4 ans 8 mois |
| Ubuntu 24.04 LTS | Mai 2029 | 2 ans 8 mois |
| Debian 13 | Août 2028, puis LTS communautaire | environ 1 an 10 mois |
| Debian 12 — environnement en conteneurs uniquement, non recommandé | terminé en juillet 2026 | dépassé |
MariaDB 10.11 elle-même arrive en fin de vie vers février 2028. Dans l'environnement en conteneurs, c'est un figeage d'image et une décision distincte ; dans l'environnement natif, cela ne concerne qu'Ubuntu 24.04, puisque 26.04 et Debian 13 prennent 11.8 dans leurs propres archives. Dans les deux cas, c'est exactement pourquoi le système d'exploitation de l'hôte devrait être celui qu'on a le moins souvent besoin de remplacer.
Si votre hébergeur ne propose pas encore Ubuntu 26.04, prenez Ubuntu 24.04. Elle est pleinement prise en charge et vous ne perdez rien de mesurable.
Ce qu'on peut dire sans risque, et que cette page dit
- SixPanel fait tourner la pile 6amMart complète sur Ubuntu 26.04, Ubuntu 24.04 et Debian 13 — les trois qui ont été mesurées — vérifié sur des données de production réelles.
- Chaque version prise en charge apporte dans sa propre archive une base de données qui fonctionne — MariaDB 11.8 sur Ubuntu 26.04 et Debian 13, 10.11 sur Ubuntu 24.04 — et mesurées sur la même boutique, 11.8 contre 10.11 c'est une égalité. L'environnement en conteneurs fige 10.11 dans son image si vous voulez précisément cette version.
- Ubuntu 26.04 LTS est recommandée, et reçoit des mises à jour de sécurité jusqu'en avril 2031.
- Un serveur 2 cœurs / 4 GB a servi environ 53 requêtes par seconde sur l'endpoint de recherche, à 20 utilisateurs simultanés, sur 30 secondes, avec un catalogue à taille réelle de 66,701 commandes, la base répondant à 99.99 % des lectures depuis la mémoire.
- Une installation neuve se termine sans surveillance en environ cinq minutes (273–303 s mesurées ; la plus lente des trois, 303 s, est le chiffre sur lequel le texte est écrit).
Ce que les mesures ne soutiennent pas, et que cette page ne dit pas
- Que l'un de ces systèmes d'exploitation est plus rapide qu'un autre. Les différences mesurées sont plus petites que le bruit d'une seule machine.
- Tout chiffre en « pourcentage plus rapide » tiré des tableaux internes de latence. L'écart entre machines est de 3.5 % contre 8.6 % d'écart avec soi-même — et c'est pourquoi aucun tableau de latence cellule par cellule n'apparaît.
- Les chiffres de latence sous charge d'Ubuntu 26.04. Ils sont arithmétiquement impossibles et ont été exclus.
- Quoi que ce soit sur la vitesse du disque. Cette colonne reflète la machine physique sur laquelle chaque serveur a atterri, pas le système d'exploitation — et elle n'a rien apporté dans un sens ni dans l'autre, puisque la base répond à 99.99 % des lectures depuis la mémoire et cesse de toucher le disque une fois chaude.
- Tout chiffre général du type « 6amMart va à cette vitesse ». 53 requêtes par seconde décrit un endpoint, sur ces données, sur 2 cœurs, à 20 utilisateurs simultanés pendant 30 secondes.
- Quoi que ce soit sur des serveurs de 8 GB ou plus. Seules des machines de 4 GB ont été mesurées dans cette série.
- Quoi que ce soit sur la vitesse de Debian 12. L'environnement natif le refuse nommément, et il n'a jamais été mesuré.
Ce que la série a cassé, et que nous avons corrigé
Trois vrais défauts ne sont apparus que parce que la mesure a été faite sur de vrais serveurs avec de vraies données. Ce sont bien les trois que la source enregistre — la liste est complète, ce n'est pas une sélection.
- 1L'installateur échouait sur Debian 13. L'image minimale ne livre pas git, donc le clone cassait net. Corrigé.
- 2Le banc d'essai ne mesurait rien sur les lignes de l'API. Ses en-têtes de requête étaient découpés, donc chaque ligne d'API affichait zéro échantillon — silencieusement, sur les trois machines. Corrigé, et une série qui ne collecte aucun échantillon le dit maintenant clairement au lieu d'afficher un résultat silencieux.
- 3Deux scripts ne s'accordaient pas sur la limite de mémoire PHP, alors qu'un commentaire affirmait que les formules correspondaient exactement. Corrigé.
Cette section reste sur la page. C'est la preuve que la mesure était réelle.
Ce qu'il vous faut
Ce qu'il vous faut, et ce qu'une installation neuve demande vraiment
| Prérequis | Détail |
|---|---|
| Système d'exploitation | Ubuntu 26.04 (recommandé), Ubuntu 24.04 ou Debian 13 — exactement trois. Rien d'autre : les versions plus anciennes, y compris Debian 12, et toute autre distribution sont refusées nommément avant tout téléchargement. Le support de sécurité gratuit de Debian 12 s'est arrêté en juillet 2026 ; l'environnement en conteneurs s'y installe toujours, mais une nouvelle boutique ne devrait pas y démarrer. |
| Type de processeur | x86_64, ou arm64 (également écrit aarch64). |
| Cœurs de processeur | 2 cœurs est la taille confortable pour une boutique. L'autoréglage gère de 1 cœur jusqu'à 16 cœurs. |
| RAM | 2 GB est le minimum praticable. L'installateur refuse en dessous d'environ 1.2 GB et avertit en dessous de 2 GB. 4 GB est la taille confortable pour une boutique. |
| Disque | Ce n'est pas un des filtres de l'installateur. Les trois machines mesurées avaient chacune 79 GB. Le panneau refuse un envoi qui laisserait moins d'espace libre que le plus petit entre 2 GB et 10 % du disque. Pour une installation 6amMart native (sans conteneur), SixPreflight demande 20 GB libres et préfère 40 GB. |
| État du serveur | Neuf. Pas d'aaPanel, CloudPanel, cPanel ni Plesk. Rien qui écoute déjà sur les ports 80 ou 443. |
| Ports ouverts chez votre hébergeur | Exactement trois : le port de votre panneau (un nombre élevé tiré au hasard à l'installation), 80, et 443. Rien d'autre, jamais. |
| Accès | L'identifiant root du serveur. L'installateur refuse de tourner sous un autre compte. |
| Votre code | Votre code 6amMart dans un dépôt git privé. SixPanel installe depuis git, pas depuis une archive zip. |
| Votre téléphone | Une application d'authentification. La double authentification est obligatoire pour le compte du propriétaire et ne peut pas être désactivée. |
| Un domaine | Et la possibilité de modifier ses enregistrements DNS. |
| Une deuxième boutique | Environ 2 GB de RAM en plus et 1–2 cœurs en plus par boutique supplémentaire. Prévoyez le haut de cette fourchette — 2 cœurs — c'est le choix prudent. |
| Ce que ça coûte | Rien. SixPanel est gratuit et publié sur CodeCanyon, et la première installation et configuration est gratuite également. Il n’y a pas de serveur de licences, pas de clé à renouveler et pas de code d’achat dans la commande d’installation. |
Ce que SixPanel installe : nginx, PHP-FPM, MariaDB, Redis et un service de panneau Node.js, tous supervisés par systemd et tous depuis l'archive de distribution de la version elle-même — PHP 8.5 avec MariaDB 11.8 sur Ubuntu 26.04, 8.4 avec 11.8 sur Debian 13, 8.3 avec 10.11 sur Ubuntu 24.04. L'environnement Docker installe la même pile en conteneurs, figée sur PHP 8.4 et MariaDB 10.11. Langues de l'interface du panneau : 8 — anglais, espagnol, arabe, portugais, français, allemand, indonésien, bengali.
Ce qu'une installation neuve demande vraiment — le calendrier honnête
« Cinq minutes », c'est la commande d'installation, pas le travail. La commande d'installation prend environ cinq minutes. Passer d'un serveur loué à une boutique en ligne prend environ une heure.
| Étape | Temps |
|---|---|
| Mettre votre code dans un dépôt git privé (une fois, sur votre propre ordinateur) | environ 20 minutes si vous n'avez jamais utilisé git |
| Mettre le serveur à jour et ajouter trois petits outils | une minute ou deux |
| Lancer la commande d'installation — elle vérifie le système, installe Docker, vérifie la signature, télécharge et contrôle les fichiers, génère les mots de passe, tire au hasard un port de panneau, dimensionne tout pour la machine, puis construit et démarre | 273–303 secondes mesurées sur trois systèmes d'exploitation — environ cinq minutes |
| Ouvrir les trois ports dans le tableau de bord de votre hébergeur | quelques minutes |
| Première connexion, et mise en place de la double authentification sur votre téléphone | quelques minutes |
| Pointer le domaine et obtenir le certificat gratuit | moins d'une minute une fois le DNS propagé — créez l'enregistrement DNS tôt |
| Installer votre code 6amMart depuis git | quelques minutes |
| Total pour un premier serveur | Prévoyez une heure. Vous finirez probablement plus tôt. |
Ce que l'installateur affiche à la fin, et que vous devez enregistrer immédiatement : l'URL complète du panneau, le nom d'utilisateur et le mot de passe. Le mot de passe est affiché une seule fois et n'est stocké que sous forme d'empreinte — il ne peut pas être relu.
L'échec le plus courant n'est pas l'installation. C'est le port du panneau qui n'est pas ouvert chez l'hébergeur.
Sécurité
Sécurité — seulement ce qui peut être montré
Chaque point ici peut être vérifié dans le produit. Rien ici n'affirme une sécurité générale. Les manques dans ce domaine figurent dans la liste des limites honnêtes ci-dessous, ils ne sont pas cachés.
Atteindre le panneau, déjà
- Le panneau ne répond que sous une adresse secrète. Tout le reste renvoie une page « non trouvé » vide, si bien qu'un scanner de ports ne peut pas distinguer le panneau d'un port fermé. Le port du panneau lui-même est un nombre élevé tiré au hasard à l'installation, différent sur chaque serveur.
- L'adresse secrète est une barrière devant la connexion, pas un substitut : nom d'utilisateur, mot de passe et code de double authentification s'exécutent toujours derrière elle.
- Un code d'entrée erroné est comparé en temps constant, et reçoit le même « non trouvé » vide que n'importe quoi d'autre, après un délai fixe de 200 ms. Le délai est plafonné à 32 échecs en cours ; au-delà de ce plafond, le « non trouvé » revient immédiatement. Un code erroné coûte donc la même chose que n'importe quoi d'autre jusqu'à ce plafond, pas toujours — 20 codes erronés en 15 minutes bloquent l'adresse pendant 30 minutes dans les deux cas.
- Sur une installation neuve, le nom de connexion est généré — admin plus quatre caractères aléatoires, par exemple admin7f3q — pour qu'un robot qui trouve une page de connexion n'ait aucun nom à viser. Une installation qui portait déjà une empreinte de mot de passe garde le nom simple admin.
- Verrouillage optionnel sur le domaine du panneau. Quand un domaine de panneau est défini, même une requête directe vers l'adresse IP du serveur reçoit le même « non trouvé » vide. Le chemin de retour passe par SSH.
Se connecter
- Empreinte de mot de passe (bcrypt), un cookie de session signé, et des codes de double authentification qui ne peuvent pas être désactivés pour le compte du propriétaire.
- Un blocage qui survit à un redémarrage : 20 mots de passe erronés en 15 minutes bloquent cette adresse pendant 30 minutes. Cinq codes de double authentification erronés font de même.
- Une liste d'adresses IP autorisées optionnelle sur le formulaire de connexion — et enregistrer une liste qui ne contient pas votre propre adresse est refusé, donc vous ne pouvez pas vous enfermer dehors.
Ce que le panneau refuse de faire
- Refus par défaut sur chaque route, plus un contrôle de requête intersites sur chaque modification. Le webhook de déploiement est la seule exception et se justifie par une signature sur le corps brut de la requête. Les livraisons en double et celles de plus de cinq minutes sont ignorées, et chaque rejet est écrit dans le journal d'activité.
- Le gestionnaire de fichiers ne peut pas atteindre la pile. Il est clôturé à deux dossiers — votre code admin et votre code de boutique — avec à la fois un contrôle de préfixe et un contrôle de chemin réel. Les fichiers Docker, le dossier de données, le dossier propre au panneau et le fichier de configuration de la pile sont inatteignables depuis cette API. C'est énoncé comme une frontière de sécurité, pas comme une préférence de conception.
- Les décisions de confiance utilisent le vrai pair réseau, jamais un en-tête qu'un client peut écrire.
- Le routage sensible à la casse est défini avant le premier middleware, ce qui a fermé un vrai contournement où un chemin écrit avec une casse différente passait à côté d'un test d'authentification sensible à la casse.
Secrets
- Le fichier d'état du panneau est réservé au propriétaire (0600) dans un dossier lui aussi réservé au propriétaire. Le fichier de configuration de la pile est en 0600. Le socket de ligne de commande est un socket Unix réservé au propriétaire — accessible seulement à root par les permissions de fichier, jamais exposé sur le réseau.
- Le mot de passe du premier démarrage est transformé en empreinte, puis effacé du fichier de configuration de la pile et retiré de l'environnement du processus, pour qu'il ne puisse pas être relu depuis le conteneur.
- Une installation par assistant laissait auparavant le fichier de configuration de l'application lisible par tous, communiquant avec un cache non protégé. C'est corrigé — chaque installation, mise à jour, retour arrière et transfert réaffirme désormais les clés d'infrastructure et reverrouille le fichier en 0600.
- Les mots de passe SSH utilisés pour un transfert n'apparaissent jamais dans la liste des processus. Ils passent par l'environnement et sont nettoyés de chaque ligne de journal.
- Le paquet de diagnostic est filtré avant d'être écrit — configuration réduite aux noms de clés, fichier d'état du panneau pas collecté du tout, code d'entrée secret et valeurs ressemblant à des mots de passe masqués.
Empêcher une boutique d'accéder aux données d'une autre
- Chaque projet tourne sous son propre utilisateur unix, avec un dossier d'application en 0700 et un fichier de configuration en 0600. La barrière, c'est le noyau qui refuse un autre utilisateur — pas une vérification à l'intérieur de PHP, qu'un bug de PHP peut contourner.
- Chaque projet reçoit aussi son propre utilisateur de base de données, avec des droits limités à son propre schéma, son propre pool de workers PHP sur son propre socket, et sa propre instance de cache avec son propre mot de passe et son propre plafond mémoire.
- Cela a été testé en l'attaquant, pas affirmé. Chaque lecture d'un projet vers un autre a réellement été tentée depuis le PHP d'un projet, sur ce panneau et sur aaPanel. Toutes ont échoué des deux côtés — mais là où les deux se recoupent, ils divergent : un fichier privé qu'un autre site avait écrit dans le répertoire temporaire partagé était lisible sur aaPanel et refusé ici.
- PHP est en outre confiné par un espace de noms de montage du noyau. Cela a fermé le répertoire temporaire partagé (57 entrées visibles ramenées à 0), le code du panneau lui-même, la configuration de site de chaque projet — c'est-à-dire chaque domaine de la machine — et la liste des processus visibles (138 ramenés à 6). Coût mesuré : aucun. 217 accès au système de fichiers par requête avant, 217 après.
- Deux propositions supplémentaires ont été rejetées par la mesure plutôt que livrées : masquer la configuration du serveur web ne fermait rien et cassait l'outil de bilan, qui la lit, et bloquer en bloc le répertoire du panneau aurait emporté avec lui l'outil d'administration de la base de données.
- Le problème du cache unique partagé que cela remplace était réel, et il est décrit en entier dans la section sur les tests ci-dessous plutôt que passé sous silence.
Versions — et le seul chemin de mise à jour qui n'est pas vérifié
- Les artefacts de version sont signés, et la clé de signature est hors ligne. Paramètres → auto-mise à jour du panneau vérifie la signature avec une clé fixée sur votre serveur, refuse un numéro de build inférieur ou égal à celui installé, et vérifie l'empreinte du fichier.
- La commande d’installation est récupérée et vérifiée contre une empreinte publiée avant d’être exécutée. Si le fichier téléchargé ne correspond pas, la commande s’arrête et rien n’est installé.
- Donc : deux des trois chemins de mise à jour sont vérifiés par signature — l’auto-mise à jour dans Réglages → du panneau, et la commande d’installation.
- L'installateur lui-même est vérifié, pas seulement la version qu'il applique. Votre serveur lit un relevé publié de l'empreinte de l'installateur, compare le fichier à ce relevé, et refuse d'exécuter tout ce qui ne correspond pas — un hôte de mise à jour remplacé ou relayé ne peut donc pas remettre à votre serveur un installateur modifié.
- Une nouvelle clé de signature n'est adoptée que si la clé déjà fixée sur votre serveur l'a elle-même signée — jamais parce que le service de mise à jour l'affirme, et jamais parce que la nouvelle clé signe la version avec laquelle elle est arrivée. Ces deux preuves-là, un hôte compromis peut les produire ; la signature de l'ancienne clé sur une clé qu'elle n'a jamais vue, il ne le peut pas. C'est ce qui empêche quiconque de changer la clé de votre serveur.
Une attaque mesurée, bornée et re-mesurée
C'est la preuve de sécurité de cette page, parce qu'elle a des chiffres des deux côtés.
Tout cela a été mesuré sur une machine de test à deux projets de 8 GB avec Redis plafonné à 476 MB. C'est une machine différente de celles de 4 GB de la série sur les systèmes d'exploitation ci-dessus — seules des machines de 4 GB ont été mesurées dans cette série, et les deux affirmations sont vraies. Les séries après correction ont été faites avec le budget des listes forcé à 64 MB, qui est le réglage que reçoit la plus petite machine prise en charge, et non les 245 MB qu'une machine de 8 GB recevrait normalement.
Avant la correction
| Mesure | Valeur |
|---|---|
| Plafond mémoire Redis sur cette machine | 476 MB |
| Une entrée de recherche d'articles à la plus grande taille de page (limit=200) | 917,704 octets |
| Copies écrites par entrée | 2 — une clé vivante et un jumeau périmé de taille pleine |
| 20 recherches d'une lettre à cette taille de page | +34.2 MB en 4.8 secondes — mesuré, soit environ 1.71 MB par terme |
| Requêtes nécessaires pour remplir tout le serveur de cache | 476 ÷ 1.71 ⇒ environ 278, à peu près 67 secondes sur une seule connexion |
| Session d'un acheteur connecté | évincée — déconnecté silencieusement |
Note arithmétique, parce que cette page ne peut pas faire une vertu de repérer les chiffres impossibles plus haut puis afficher un tableau qui rate sa propre multiplication. Le rapport interne indique un coût par terme de 1.79 MB et un remplissage à environ 279 requêtes. Ni l'un ni l'autre ne découle de l'autre : 917,704 × 2 = 1,835,408 octets = 1.835 MB, pas 1.79 MB, et 476 ÷ 1.79 = 265.9, pas 279. La ligne qui réconcilie tout est celle qui a été mesurée — 20 recherches coûtent 34.2 MB, soit exactement 1.71 MB chacune, et 476 ÷ 1.71 = 278.36, tronqué à 278 ; rien ici n'est arrondi vers le haut. Cela colle aussi au temps indiqué : 20 requêtes ont pris 4.8 s, donc 278 en prennent 66.7 s ≈ les 67 secondes que rapporte la source. Cette page affiche la chaîne qu'un lecteur peut vérifier, et laisse tomber 1.79 MB et 279 plutôt que de les répéter.
Après la correction — les trois rafales que le fichier de preuves tabule, y compris celle qui ne stocke rien
Le fichier de preuves décrit « six rafales non authentifiées simultanées » au-dessus d'un tableau de trois lignes et ne réconcilie jamais les deux. Que cela veuille dire six processus de rafale produisant trois résultats tabulés, ou trois séries sur six rapportées, la source ne le dit pas — cette page dit donc « les trois que la source rapporte » et ne prétend à aucune exhaustivité.
| Rafale | Entrées stockées | Octets de listes dans Redis | Évictions | Session |
|---|---|---|---|---|
| 200 requêtes à la plus grande taille de page (limit=200) | 0 | 0 | 0 | vivante |
| 500 requêtes à une taille de page de 50 lignes | 206 | 51.5 MB | 0 | vivante |
| 2,000 requêtes à une taille de page de 50 lignes | 207 | 51.8 MB | 0 | vivante |
Sur ces rafales, Redis dans son ensemble a culminé à 53.6 MB de ses 476 MB. Ce chiffre concerne toute l'instance, pas la famille des listes : le tableau ci-dessus plafonne les octets de listes à 51.8 MB, donc 53.6 MB ne peut pas être le cache des listes.
Sur la plus petite machine prise en charge, la famille des listes est plafonnée à 64 MB d'une instance Redis de 128 MB. À environ 1 KB par session, cela laisse de la place pour de l'ordre de 60,000 acheteurs connectés — un espace qui contient aussi tout le reste de ce que Redis fait sur cette machine : traitez-le donc comme une marge, pas comme un nombre de places.
Ce qu'est le panneau, dit simplement
Trois faits sur lesquels la documentation du produit insiste elle-même.
- Le panneau est équivalent à root sur l'hôte, par construction. Il monte le socket Docker et monte le répertoire de la pile en lecture-écriture. Les capacités retirées au conteneur limitent le rayon d'impact — c'est plus étroit qu'un confinement.
- L'adresse d'entrée secrète est une barrière. La connexion s'exécute derrière elle, et chaque connexion demande un mot de passe et un code de double authentification.
- Il y a exactement un compte administrateur et il n'y a aucun rôle. Le partage se fait avec des identifiants temporaires et un identifiant de démonstration en lecture seule.
Comment nous testons
Deux campagnes indépendantes ont conclu « pas prêt ». Voici ce qu'elles ont trouvé.
La plupart des pages de logiciels vous disent ce qu'un produit fait. Celle-ci vous dit aussi ce qui n'allait pas avant la sortie, parce que la façon dont une chose est testée est la seule preuve honnête de la qualité de son fonctionnement.
- Routes parcourues, 283 chargements de page sur cinq tailles d'écran, en thème clair et sombre
52
Routes parcourues, 283 chargements de page sur cinq tailles d'écran, en thème clair et sombre
- Clés de texte d'interface vérifiées, dans chacune des 7 langues
2,740
Clés de texte d'interface vérifiées, dans chacune des 7 langues
- Parcours du panneau exécutés de bout en bout, sur les deux bases de code 6amMart
34
Parcours du panneau exécutés de bout en bout, sur les deux bases de code 6amMart
- Campagnes indépendantes dont le verdict a été « pas prêt »
2
Campagnes indépendantes dont le verdict a été « pas prêt »
Un même fil traversait chaque constat sérieux
Chacun des pires défauts était une surface verte posée sur quelque chose de cassé. Une page qui affiche « succès », un numéro de version qui dit « à jour », une vérification de santé qui dit « en bonne santé » — chacune vraie en tant qu'énoncé et fausse en tant que fait. C'est pourquoi les vérifications ci-dessous testent désormais le résultat plutôt que le code de sortie.
Ce que les campagnes ont trouvé, et ce qu'il en est advenu
Ce sont les nôtres, ils étaient sérieux, et ils sont corrigés. Ouvrez n'importe lequel pour le détail.
Les sauvegardes s'exécutaient, annonçaient un succès, et ne contenaient aucune base de donnéesCorrigé
La règle d'exclusion de l'outil de sauvegarde filtrait toute l'exécution : exclure le répertoire de travail annulait donc aussi les fichiers de dump de base de données que la même exécution avait explicitement nommés. L'outil enregistrait le répertoire vide et se terminait avec succès.
Six instantanés — dont l'un étiqueté comme sauvegarde de la base de données — contenaient 10,888 fichiers et pas un seul dump de base, pendant que la page Sauvegardes annonçait du début à la fin un succès et une taille de dépôt.
Cela est passé inaperçu parce que le seuil de vérification était de 21 jours face à une planification hebdomadaire. Les deux étaient faux, et les deux sont désormais des barrières plutôt que des réglages.
Corrigé, puis une restauration a été prouvée plutôt que supposée : une sauvegarde récente contient un dump de base de 39 MB qui restaure 192 tables et l'ensemble des 66,701 commandes.
La boutique côté client écoutait sur un port public, en dehors de toutes les protectionsCorrigé
Elle était attachée à toutes les interfaces réseau sur un port en clair, non chiffré, contournant le serveur web et donc le certificat, les deux limiteurs de débit, le cache et tous les en-têtes de sécurité. C'était une hypothèse héritée du produit conteneurisé, sans rien derrière elle sur une installation native.
Le test a aussi établi que l'hébergeur n'applique aucun pare-feu par défaut : sur une installation par défaut, le problème n'était donc pas théorique, il était sans la moindre atténuation.
Corrigé, vérifié depuis l'internet public, et vérifié de nouveau après un redémarrage.
Le déploiement, le retour arrière et l'activation mettaient le code à jour, et le site continuait de servir l'ancienne versionCorrigé
SixPanel garde le cache de code compilé de PHP figé — un choix de vitesse délibéré et mesuré — ce qui signifie qu'un code modifié sans rechargement n'est jamais exécuté. Un seul des quatre chemins qui écrivent du code effectuait ce rechargement.
Un déploiement récupérait donc le nouveau code, exécutait les migrations de base de données, reconstruisait les caches et redémarrait les workers pendant que le site servait indéfiniment l'ancienne version. Le retour arrière, lui, ne faisait absolument rien.
Démontré plutôt qu'argumenté, à travers le vrai serveur web et sur un fichier déjà en cache : avant la modification, il servait la version un ; après la modification et sans rechargement, il servait toujours la version un alors que le disque contenait la version deux ; après le rechargement, il servait la version deux.
Corrigé aux quatre endroits. La leçon retenue : un réglage de performance qui dépend de la discipline appliquée ailleurs finira par ne pas l'obtenir — le rechargement fait donc maintenant partie de la fonction même qui écrit le code.
Une boutique pouvait lire dans le cache partagé les secrets de paiement et de messagerie d'une autre boutiqueCorrigé
Le cache était un service unique et partagé, derrière un seul mot de passe que contient le fichier de configuration de chaque projet. En partant de l'utilisateur d'un seul projet, une sonde a lu le mot de passe de messagerie mis en cache d'un autre projet, ses identifiants de notifications push, ses clés de cartographie, sa clé de passerelle SMS, son secret anti-robot et les clés secrètes de deux passerelles de paiement — et l'écriture était également permise, ce qui rendait modifiable la configuration de messagerie en cache de la victime.
La correction consiste en une instance de cache par projet, sur son propre socket, dans son propre répertoire, avec son propre mot de passe et sa propre limite mémoire. La frontière, c'est le système de fichiers ; le mot de passe est le second verrou.
Prouvé en retournant l'attaque contre la correction : la sonde est passée du succès au refus dans les deux sens — refusée alors même qu'elle détenait le mot de passe de la cible — puis revérifiée contre une permission volontairement cassée, pour confirmer que le test lui-même fonctionne toujours.
Coût mesuré : 3.2 MB de mémoire par projet. Le nombre de workers PHP est inchangé sur 18 des 20 combinaisons de serveur et de projet, et le socket est en réalité plus rapide que la boucle réseau locale qu'il remplace. Le déplacement des données en production a pris 13.9 millisecondes et n'a déconnecté personne.
Les mises à jour arrivaient sur le disque sans prendre effet, trois fois dans une même campagneCorrigé
Un serveur prenait une mise à jour, annonçait la nouvelle version, et continuait de servir avec la configuration écrite le jour de son installation. Quatre chemins différents peuvent déposer de l'état sur un serveur, et ils ne livraient pas le même ensemble.
Un audit complet de ces quatre chemins a trouvé environ quinze catégories d'état qu'une installation neuve produisait et qu'un serveur en cours de mise à jour ne recevait jamais — toute l'échelle de dimensionnement, la configuration de la base de données, le pool PHP par défaut, un fichier inclus par chaque site, le service d'alertes et ses déclencheurs d'échec, et d'autres encore.
Un cas était invisible sur deux couches à la fois : chaque serveur du canal publié échouait à la même étape à chaque mise à jour, indéfiniment, et en dessous, la propre vérification de version de l'outil en ligne de commande se déclarait à jour alors qu'elle avait trois versions de retard.
Corrigé, et désormais imposé par une vérification qui s'exécute à chaque build : chaque fonction qui écrit de l'état doit déclarer si une mise à jour la livre, et pourquoi. Vérifié contre 14 sabotages délibérés, les 14 ont été détectés.
Puis prouvé de bout en bout : un serveur mis à jour depuis le canal publié et un serveur fraîchement installé ont produit 1,447 lignes de configuration sur 1,447 identiques octet pour octet.
Sur un 6amMart CodeCanyon intact, l'installation se terminait et le panneau d'administration était inutilisableCorrigé
Le 6amMart de l'éditeur verrouille son panneau d'administration derrière une étape d'activation par code d'achat, après la connexion. SixPanel ne demandait jamais ce code, ne le mentionnait jamais, et annonçait le déploiement comme terminé.
Cela est resté invisible longtemps parce que notre propre copie optimisée de 6amMart a cette vérification désactivée : tout l'historique de tests du produit avait donc tourné sur une base de code où la barrière n'existe pas.
L'assistant recueille désormais le code d'achat et mène à bien l'activation propre à l'application. Un piège a été refermé au passage : l'application contourne entièrement le serveur de licences quand la requête vient de la machine elle-même, ce qui est le cas d'une requête en ligne de commande — n'importe quel code inventé aurait donc été accepté sans qu'un seul paquet quitte le serveur.
Deux points liés ont été corrigés en même temps. La boutique s'installe maintenant depuis le zip qu'un acheteur CodeCanyon possède réellement, au lieu d'exiger un dépôt git. Et les projets de l'éditeur ne sont plus déployés en mode développement, lequel imprimait dans la page la réponse du captcha de connexion.
La signature de mise à jour protégeait la version, mais pas l'installateur qui l'appliquaitCorrigé
Douze scénarios adverses passent désormais contre l'artefact publié, et le même banc d'essai produit douze échecs contre l'installateur précédent — dont deux où l'installateur d'un inconnu réussissait et laissait la clé d'un inconnu épinglée sur le serveur.
En remontant plus loin, nous avons trouvé quelque chose qui mérite d'être dit franchement : une signature atteste de ce qui a été construit, pas de ce qui l'a construit. La machine de compilation récupérait ses propres outils dans la version la plus récente du moment, si bien qu'un arbre de dépendances était résolu à nouveau à chaque compilation et expédié à l'intérieur de l'artefact signé. Les deux outils de compilation sont maintenant figés à des versions exactes sous un fichier de verrouillage versionné.
Un incident évité de peu, issu de la même série : une commande de certificat avait gagné une option que la version installée ne connaît pas, ce qui aurait fait échouer silencieusement chaque renouvellement jusqu'à l'expiration des certificats. Elle a survécu à la relecture parce que demander sa version à cet outil réussit quelle que soit l'absurdité écrite sur le reste de la ligne.
Vingt-quatre endroits où le panneau disait au propriétaire quelque chose qui n'était pas tout à fait vraiCorrigé
« En bonne santé dans l'ensemble » sur un serveur que le système d'exploitation lui-même qualifiait de dégradé — rien dans le code de santé ne le lui avait jamais demandé. Sur le serveur de publication, un service planifié échouait toutes les 60 secondes depuis un jour, déclenchant son gestionnaire d'échec 1 440 fois, pendant que le titre affichait « en bonne santé ».
L'auto-réparation traitant une vérification qui n'avait pas pu s'exécuter comme une observation de bonne santé. Un écart de 135 fois entre deux comptages d'erreurs. Un relevé d'occupation disque qui rendait compte de 18,4 % de l'espace utilisé et le présentait comme le tableau complet — désormais 92,7 %.
Un assistant d'installation inachevé qui n'interrogeait jamais le point de terminaison de version, et une navigation mobile qui se réduisait à une largeur nulle dès que l'avis de mise à jour était affiché.
Les 24 sont clos. Deux des six derniers défauts signalés se sont révélés inexistants, et les deux ont été abandonnés avec les preuves plutôt que corrigés pour la forme.
Chaque serveur installé faisait tourner des fichiers appartenant à un utilisateur qui n'existe pas dessusCorrigé
L'utilisateur et le groupe de la machine de compilation étaient inscrits dans l'artefact — 459 fichiers sur un serveur, dont un qui n'avait jamais reçu que la ligne d'installation publiée.
Pas exploitable en l'état, mais cela voulait dire que le système exécutait du code qu'il ne possédait pas, ce qui n'est pas un état qu'on laisse traîner.
Corrigé par la mise à jour elle-même : 459 fichiers au mauvais propriétaire sont devenus zéro.
Ce qui a tenu
Les mêmes séries ont aussi confirmé ce qui était censé fonctionner, et cela mérite d'être énoncé avec ses chiffres plutôt qu'avec des adjectifs.
- Redémarrage complet
- De retour en SSH en 79 secondes, zéro service en échec, chaque service dans un état identique octet pour octet à l'instantané pris avant le redémarrage, les deux websockets connectés, aucune étape manuelle.
- Arrêt brutal du panneau
- De retour en 4 secondes environ.
- Une mise à jour ordinaire
- Zéro seconde d'indisponibilité, 91 requêtes sur 91 répondues normalement du début à la fin.
- Restauration depuis une sauvegarde
- 192 tables et 66 701 commandes, depuis une vraie sauvegarde planifiée et non une sauvegarde faite pour le test.
Encore ouvert, et écrit ici plutôt que laissé de côté
- Un compteur de base de données ressort mauvais sur le serveur natif — des tables temporaires écrites sur le disque pour 59,8 % des requêtes. C'est un problème de forme de requête et non de dimensionnement, et il est nouveau depuis la dernière série.
- Le produit conteneurisé a besoin d'une version pour emporter le correctif de sauvegarde et le travail sur le DNS décrits plus haut.
- Une tâche de fond en échec, restée là, est à elle seule la raison pour laquelle le contrôle du serveur de test a marqué 88 au lieu de 97 — la note plafonne dès qu'une ligne est mauvaise, et les scores bruts sous-jacents diffèrent de 0,03 sur une centaine de vérifications.
Rien de tout cela n'est inhabituel pour un logiciel serveur. Ce qui est inhabituel, c'est de le publier. Si la page marketing d'un panneau ne porte aucune liste de ce genre, cela ne veut pas dire qu'il n'y avait rien à trouver.
Limites honnêtes
Limites honnêtes
Chacune d'elles est vraie aujourd'hui.
- 1
Il prend le serveur entier.
Pas d'autres sites web, pas d'autre panneau de contrôle, rien d'autre sur les ports 80 et 443.
- 2
Un seul compte administrateur. Pas de rôles, pas de comptes d'équipe.
Les identifiants temporaires et un identifiant de démonstration en lecture seule sont les mécanismes de partage.
- 3
Le panneau est équivalent à root sur la machine.
Quiconque peut s'y connecter peut tout exécuter sur ce serveur. Le redémarrage, la mise à jour du système d'exploitation et l'auto-mise à jour fonctionnent en lançant un conteneur privilégié qui entre dans le système de fichiers de l'hôte — c'est ainsi qu'ils sont construits.
- 4
La restauration n'est pas encore un bouton « déplacer vers n'importe quel serveur ».
Une sauvegarde couvre tous les projets, mais la restauration vise actuellement le projet par défaut. Restaurer sur une autre machine laisse en place les mots de passe et les chemins de l'ancienne machine, et l'application ne peut pas se connecter tant que vous n'avez pas lancé la Mise à jour. La tâche de restauration n'exécute pas non plus les migrations de base de données, donc une sauvegarde ancienne sous du code plus récent reste en retard sur le schéma. Les deux ont une étape manuelle qui fonctionne ; aucune n'est automatique aujourd'hui. Le chemin de restauration lui-même a été vérifié par relecture et non exécuté lors de la série du 15 août.
- 5
Un retour arrière du code n'annule pas les migrations de base de données.
Si une migration a été exécutée, revenir en arrière sur le code nécessite une restauration de sauvegarde.
- 6
Le panneau prend en compte un certificat renouvelé au redémarrage.
Le renouvellement quotidien recharge nginx ; le panneau lit son propre certificat une seule fois au démarrage.
- 7
Déplacer une boutique depuis un ancien serveur a été vérifié par relecture, non exécuté.
C'était la série du 15 août. Considérez-le comme pris en charge, pas comme prouvé sur votre type de serveur.
- 8
Le chien de garde autoréparateur ne voit que les conteneurs qui déclarent un contrôle de santé.
Les conteneurs optionnels websocket et boutique n'en déclarent pas encore.
- 9
Le code du panneau lui-même n'est pas lisible sur votre serveur.
Son backend est livré en bytecode V8 et les sources lisibles sont retirées du build ; les fichiers navigateur sont minifiés et obfusqués. C'est de la dissuasion, pas une protection — quiconque est déterminé peut encore comprendre ce qu'il fait. Votre code 6amMart et vos données ne sont pas concernés.
- 10
L'auto-mise à jour de la ligne de commande sixpanel n'a ni contrôle de signature ni contrôle d'empreinte.
Sur une installation empaquetée, il télécharge l’installateur par le réseau et l’exécute en root, et sa propre ligne de progression affirme le contraire. L’auto-mise à jour dans Réglages → du panneau et la commande d’installation sont vérifiées ; ce troisième chemin ne l’est pas. En attendant le correctif, mettez à jour depuis le panneau.
- 11
Le journal d'activité a un trou, et les règles de ré-authentification sont inégales.
Supprimer une tâche planifiée n'écrit aucune trace d'audit, alors que la créer, la modifier et la lancer manuellement en écrivent une — donc supprimer une tâche root au niveau du panneau ne laisse aucune trace. Par ailleurs : une tâche planifiée au niveau du panneau exige de ressaisir votre mot de passe, mais le redémarrage, la mise à jour du système d'exploitation et l'auto-mise à jour du panneau — tous root sur l'hôte — n'exigent qu'une session valide.
- 12
Trois réglages du panneau sont de la configuration morte.
La limite de débit de l'API du panneau, sa limite de débit sur les chemins lourds et son plafond de taille d'envoi sont lus par le code mais ne sont pas transmis au conteneur du panneau : les définir dans le fichier de configuration de la pile ne change donc rien. La documentation dit de ne jamais orienter un administrateur vers eux.
- 13
Pas de Kubernetes.
Il n'y a pas de pilote Kubernetes dans le panneau.
- 14
Pas de Brotli ni de HTTP/3 à l'origine, et pas de compilation JIT dans PHP.
Les trois sont délibérés. Le JIT a mesuré plus lent sur cette charge de travail sur 11 endpoints sur 12 et à égalité sur le douzième — il n'a jamais gagné, il est donc désactivé. Brotli et HTTP/3 sont laissés à Cloudflare.
- 15
La file d'attente des tâches de fond utilise la base de données, pas Redis.
Redis a mesuré 1.76× plus rapide en débit de file d'attente et a quand même été écarté, parce que sous pression mémoire une file Redis peut être évincée silencieusement — 50 tâches en file sont passées à 0 sans rien de journalisé et sans erreur remontée. Rien de critique pour les commandes n'est mis en file.
- 16
La limitation de débit est un bouclier contre les rafales, pas une protection DDoS.
Des limites par adresse ne peuvent pas être précises quand toute une ville partage une seule adresse IP d'opérateur. Cloudflare est la vraie couche pour cela.
SixPanel et 6amMart
SixPanel est le serveur. Le code optimisé, c'est 6amMart lui-même.
SixPanel rend une installation 6amMart rapide à mettre en place, sûre à mettre à jour et peu coûteuse à faire tourner.
Rendre les écrans de 6amMart plus rapides est un travail distinct, et il vient avec le service d'installation plutôt qu'en supplément — mesuré 10× à 22× plus rapide sur chaque écran vu par les clients, sur un serveur en production. Ces écrans sont passés de 0.5–8.19 s à 45–370 ms.
Les deux ensembles de chiffres mesurent des choses différentes et ne sont jamais mélangés dans un même tableau : ceux de SixPanel ont été relevés sur d'autres machines, à un autre moment, sur une version antérieure de la pile.
Le code optimisé n'est pas quelque chose que vous achetez séparément. Il n'y a pas de deuxième licence, pas de deuxième prix et pas de deuxième cycle de versions — c'est la façon dont le service d'installation 6amMart existant est livré, à la même installation à $300. Quand l'éditeur de 6amMart publie une nouvelle version, la règle du catalogue s'applique sans changement : une mise à jour ou un passage à une version plus récente du script coûte 50 % du prix d'installation. Chaque installation est livrée sur la dernière version de 6amMart.
FAQ
Les questions que les gens posent vraiment
Douze questions, répondues avec les mêmes chiffres que le reste de la page.
Qu'est-ce que SixPanel ?
Un panneau d'hébergement et une pile Docker pour une seule tâche : faire tourner une boutique 6amMart sur votre propre serveur. Il installe le serveur web, la base de données, PHP, le cache, le worker de tâches de fond et le certificat HTTPS, puis vous donne une page web pour tout piloter.
SixPanel comprend-il le script 6amMart ?
Non. Vous achetez 6amMart sur CodeCanyon. SixPanel installe le code que vous possédez déjà, depuis votre propre dépôt git privé. SixPanel lui-même est gratuit et publié séparément sur CodeCanyon, et sa commande d’installation est publique — la même pour tout le monde.
Quel système d'exploitation dois-je installer ?
Ubuntu 26.04 LTS, dans l'un ou l'autre environnement. Le natif prend en charge exactement trois versions — Ubuntu 26.04, Ubuntu 24.04 et Debian 13 — et prend PHP, MariaDB, nginx et Redis dans celle que vous choisissez. La vitesse n'est pas la raison : sur six axes mesurés, aucun changement de version n'a produit d'écart digne d'être rapporté. Les mises à jour de sécurité, si : 26.04 est corrigé jusqu'en avril 2031, contre mai 2029 pour 24.04 et août 2028 pour Debian 13. Debian 12 est refusé nommément par l'environnement natif ; celui en conteneurs s'y installe toujours, mais son support de sécurité s'est arrêté en juillet 2026 : n'y démarrez pas une nouvelle boutique.
Pourquoi la recommandation porte-t-elle sur la durée de support et non sur la vitesse ?
Parce que la vitesse n'a rien tranché. Six axes ont été mesurés sur du matériel identique — le système d'exploitation, PHP, MariaDB, nginx, Redis et le noyau — et aucun changement de version n'a produit d'écart digne d'être rapporté. Deux machines identiques au bit près ont divergé de 11,6 % l'une de l'autre sur 20 lignes sur 20, ce qui est plus grand que tout effet trouvé. Ce qui diffère bel et bien, c'est la durée pendant laquelle chaque version continue de recevoir des correctifs de sécurité, et un système d'exploitation en fin de support est le seul événement qui oblige à reconstruire entièrement le serveur. Ubuntu 26.04 LTS a la plus longue durée restante des trois, jusqu'en avril 2031.
Quelle taille de serveur au minimum ?
Deux cœurs de processeur et 4 GB de RAM font tourner une boutique entière — c'est la taille sur laquelle nous avons mesuré. L'installateur refuse en dessous d'environ 1.2 GB et avertit en dessous de 2 GB. Pour une deuxième ou troisième boutique, prévoyez environ 2 GB de RAM en plus et 1–2 cœurs en plus chacune.
À quelle vitesse ça tourne ?
Mesuré face à aaPanel sur un matériel identique — 2 cœurs, 4 GB, la même boutique avec 66,701 commandes — SixPanel a répondu 1.76× plus vite sur une requête et 1.82× plus vite avec quatre arrivant à la fois, sur les endpoints qui atteignent PHP des deux côtés. aaPanel avait d'abord été entièrement réglé. Le tableau complet, la méthode et la part encore inexpliquée sont tous ci-dessus.
Combien de temps prend l'installation ?
La commande d'installation a mesuré 273 à 303 secondes sur trois systèmes d'exploitation — environ cinq minutes, sans surveillance. Passer d'un serveur loué à une boutique en ligne, DNS, certificat et installation de votre code compris, prend environ une heure sur le premier serveur.
Puis-je héberger mes autres sites web sur le même serveur ?
Non. L'installateur refuse un serveur qui fait déjà tourner aaPanel, CloudPanel, cPanel ou Plesk, ou qui a quelque chose sur les ports 80 ou 443. SixPanel gère le serveur web, les certificats et le plan de pare-feu de toute la machine, et deux systèmes qui font cela sur une même machine se cassent mutuellement. Faire tourner d'autres boutiques 6amMart sur le même serveur est pris en charge.
Puis-je donner l'accès à mon développeur sans lui donner mon mot de passe ?
Oui. Créez un identifiant temporaire avec son propre nom et mot de passe, expirant après 1 heure, 8 heures, 24 heures ou 7 jours. Il peut faire tourner le site. Il ne peut pas changer qui a accès et ne peut pas voir vos secrets. Il existe aussi un identifiant de démonstration en lecture seule pour montrer le panneau à quelqu'un.
Mettre SixPanel à jour touche-t-il mes données ou mon code ?
Non. Mettre SixPanel à jour remplace le code et les images de conteneur propres à SixPanel. Votre fichier de configuration, votre dossier data/ — base de données, fichiers envoyés, certificats, sauvegardes locales — et le code de votre application restent exactement tels quels. Mettez à jour depuis le panneau : le chemin de mise à jour du panneau vérifie une signature, et l'auto-mise à jour de la ligne de commande ne le fait pas actuellement.
Comment savoir si les sauvegardes fonctionnent vraiment ?
Le panneau le prouve. Une fois par semaine, il charge votre sauvegarde la plus récente dans une base jetable, compte ce qu'elle contient, puis supprime cette copie — vos données en production ne sont jamais touchées. Le résultat apparaît sur la page Sauvegardes et sur la page Santé. Deux réserves honnêtes : restaurer sur un autre serveur demande une étape manuelle ensuite, parce que les mots de passe et les chemins de l'ancienne machine reviennent avec la sauvegarde, et la restauration vise actuellement le projet par défaut.
SixPanel est-il open source ?
Non. Le backend du panneau est livré en bytecode V8 avec les sources lisibles retirées, et les fichiers navigateur sont minifiés. Nous appelons cela de la dissuasion, pas de la sécurité — quiconque est déterminé peut encore comprendre ce que fait le code. Votre code 6amMart et vos données sont à vous et rien ici ne les masque. Si du code lisible sur votre propre serveur est une exigence, un panneau généraliste ouvert est un meilleur choix pour vous.
Quelle est la différence entre SixPanel et SixPanel Docker ?
Le même panneau, les mêmes commandes et le même manuel — seule change la façon dont le logiciel en dessous est installé. SixPanel installe nginx, PHP, MariaDB et Redis directement depuis l'archive de distribution de la version elle-même et laisse systemd les superviser. SixPanel Docker fait tourner la même pile en conteneurs, figée sur PHP 8.4 et MariaDB 10.11 quel que soit l'hôte. Le natif est plus rapide sur tous les points de terminaison mesurés et isole les projets au niveau du noyau plutôt qu'à l'intérieur de PHP : c'est donc lui qui est recommandé, et c'est là que va le développement neuf. Choisissez celui en conteneurs si vous voulez la pile isolée dans des conteneurs, ou s'il vous faut MariaDB 10.11 sur une version dont l'archive ne la contient pas.
Votre page énumère des défauts de votre propre produit. Pourquoi ?
Parce que c'est la seule preuve honnête que les tests sont réels. Deux séries indépendantes de bout en bout ont rendu un verdict « pas prêt » avant que ceci soit déclaré terminé, et elles ont trouvé des sauvegardes qui annonçaient un succès sans aucune base de données à l'intérieur, une boutique à l'écoute en dehors de toutes les protections, et des déploiements qui mettaient le code à jour pendant que le site continuait de servir l'ancienne version. Tout est corrigé, chaque point avec la vérification qui l'empêche désormais de revenir. Si la page marketing d'un panneau ne porte aucune liste de ce genre, cela ne veut pas dire qu'il n'y avait rien à trouver.
Commencez par la vérification gratuite, puis décidez
SixPreflight vous dit si le serveur que vous avez est prêt pour 6amMart, et exactement quoi changer. Si vous préférez que nous gérions le tout, parlez-nous.
Voyez ce qui a changé dans chaque version