# The server panel built for one job — running 6amMart > Source: https://www.allsweb.com/sixpanel > Markdown for agents: https://www.allsweb.com/sixpanel.md > Publisher: AllsWeb (www.allsweb.com) SixPanel — A hosting panel that exists only to run 6amMart You rent a fresh server, run one command, and get back a web page that runs your shop. SixPanel installs the web server, the database, PHP, the cache, the background worker, the scheduler, the websocket server and HTTPS — all configured the way 6amMart actually needs them. Everything runs on your server. Your database, your images, your customers' data. ## At a glance - **Faster than a fully tuned aaPanel — same hardware, same shop, measured:** 1.76× - **Runs a whole shop:** 2 cores / 4 GB - **Published on CodeCanyon, first setup done for you:** Free - **Panel interface languages:** 8 - **Price:** Free - **Where to get it:** https://codecanyon.net/search/sixpanel - **Documentation:** https://www.allsweb.com/sixpanel/docs - **Install command:** `curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash` - **Install command (Docker runtime):** `curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash` ## You own the script. Somebody still has to run the server. You bought the 6amMart script from CodeCanyon. It is a folder of files. Before it can take an order, somebody has to install a web server, a database, PHP, a cache, a background worker and an HTTPS certificate — and then keep all of that running. SixPanel is the part that does that. You rent a fresh server, run one command, and get back a web control panel. From that panel you connect your domain, get free HTTPS, install your 6amMart code from git, update it, back it up, and see what is broken when something breaks. Everything runs on your server. Your database, your images, your customers' data. ### Three ways to drive it - **The panel** — In a browser. This is where you do almost everything. - **The sixpanel command** — On the server, for when the panel will not open. - **The installer** — Which you run once. ### With it versus without it | Without it | With SixPanel | | --- | --- | | Building a server by hand — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, a process supervisor — and keeping all of it alive | One install command. systemd is the supervisor — restart on crash, restart on reboot, memory ceilings, log rotation and a health check on every service, declared in one place. On the Docker runtime, Docker Compose does the same job. | | Guessing the database and PHP settings, or paying someone to tune them | Autotune reads the actual machine and writes the sizes: PHP workers, database buffer pool, cache memory, temporary tables, sort and join buffers and the redo log. It covers 1 core / 2 GB up to 16 cores / 32 GB, and the two places that compute those numbers are checked against each other on every build — because they once disagreed on 66 of 432 values. | | Paying a developer for every deployment | Push to git, the shop updates. Deploy history and rollback, with the last 30 deploys kept. | | Hoping the backup works | Backups run to a schedule with retention, and once a week the panel loads the newest backup into a throwaway database, counts what is inside, and deletes it again. | | Reading a stack trace to find out why the shop is down | A Health page of about twenty checks, each with one plain sentence about the consequence and exactly one fix button. | | Building and maintaining that stack yourself is the cost, whether you pay it in hours or in invoices. | Nothing. SixPanel is free on CodeCanyon, the first installation and setup is free, and the install command is the same public one for everybody — no key to enter, no code to paste. Updates arrive through CodeCanyon, and the panel can also update itself in place. | ### What it does not replace - **It does not sell you the 6amMart script.** — You buy that from CodeCanyon, and SixPanel installs the code you already own. - **It is not shared hosting.** — No cPanel account, no other websites on the machine. SixPanel expects the whole server. - **It does not run your shop.** — Prices, products, drivers and orders live in 6amMart's own admin panel. - **It is not a CDN or a DDoS service.** — Cloudflare is the real edge layer, and the documentation says so. ## One panel, two runtimes — and one of them is the recommendation Both are the same product with the same panel, the same commands and the same manual. They differ only in how the software underneath is installed, and that difference is measurable. ### SixPanel — Runs directly on the server nginx, PHP-FPM, MariaDB and Redis installed from the release's own distribution archive and supervised by systemd. Nothing is containerised, so every hop is a unix socket and the database is tuned for the machine rather than for a container. This is the faster of the two, and it is where all new work goes. - **Operating system:** Ubuntu 26.04 LTS (recommended), Ubuntu 24.04 LTS, or Debian 13 - **PHP:** 8.5 on Ubuntu 26.04, 8.4 on Debian 13, 8.3 on Ubuntu 24.04 — always the release's own package - **Database:** MariaDB 11.8 on Ubuntu 26.04 and Debian 13, 10.11 on Ubuntu 24.04 — from the same archive - **Supervised by:** systemd ### SixPanel Docker — Runs in containers The same stack as Docker Compose services. Its advantage is that the PHP and database versions never depend on the host at all: the images are fixed at PHP 8.4 and MariaDB 10.11 whichever release you run them on. It still installs, and servers already running it keep receiving updates. - **Operating system:** Ubuntu 24.04 / 26.04 LTS, Debian 13 — and Debian 12, which installs but is not recommended - **PHP:** 8.4, in the container - **Database:** MariaDB 10.11, in the container - **Supervised by:** Docker Compose ### Which one should you pick? Pick SixPanel unless something specifically requires the other. It is faster on every endpoint measured, it isolates projects at the kernel rather than inside PHP, and it is the runtime that keeps improving. Pick SixPanel Docker if you want the whole stack isolated in containers, or if you specifically need MariaDB 10.11 on a release whose archive does not carry it — the images are pinned at PHP 8.4 and MariaDB 10.11 regardless of the host. It also still installs on Debian 12, but do not start a new shop there: Debian 12's security support ended in July 2026, and the kernel, glibc, Docker and OpenSSH all still come from the host's archive. Being straight about it: new development goes into the native runtime. SixPanel Docker is maintained, not extended. If you are installing today and have a free choice of operating system, choose the native one. ## Three servers, the same shop, one difference Every performance number on this page comes from one round of measurements on real servers running a real shop's data. The setup, the method and the scripts are published, and so is the part that is still unexplained. ### How it was measured - **Three servers:** AMD EPYC 7713, 2 vCPU, 4 GB, Ubuntu 24.04 — identical except for the panel being tested - **The same application:** The same 6amMart code on all three, verified byte for byte: identical dependency lockfile, identical hash across the application, routes, modules and configuration - **The same shop:** 66,701 orders · 3,865 items · 85 stores · 17,534 customers — one real dataset, copied row for row - **The method:** Each box measures itself over loopback with its real hostname and certificate. 40 samples per cell after a discarded warm-up, and every reported figure is a median of alternating paired passes. - **Nothing thrown away quietly:** Zero rate-limited responses and zero errors in every row published. A blocked or failed request answers very fast, so a run that hides them reports a better number than the truth. **1.76x faster than a fully tuned aaPanel.** 1.82× when four requests arrive at once. Measured across the endpoints that reach PHP on both servers. ### Every endpoint, all four configurations Median milliseconds — one request / four at once. Lower is better. | Endpoint | SixPanel | SixPanel Docker | aaPanel, stock | aaPanel, tuned | | --- | --- | --- | --- | --- | | /api/v1/categories | 29.1 / 46.9 | 34.5 / 70.9 | 52.0 / 103.6 | 56.1 / 99.9 | | /api/v1/stores/get-stores/all | 17.9 / 33.3 | 24.5 / 45.0 | 37.8 / 76.4 | 38.0 / 84.2 | | /api/v1/items/search | 18.0 / 35.9 | 25.1 / 43.2 | 44.3 / 68.3 | 40.9 / 71.1 | | /api/v1/items/popular | 41.6 / 77.2 | 50.7 / 94.6 | 58.4 / 112.1 | 65.3 / 122.9 | | /api/v1/customer/order/list | 102.1 / 191.8 | 123.3 / 242.3 | 139.6 / 245.8 | 152.7 / 288.9 | | / (admin entry) | 59.6 / 102.7 | 63.5 / 156.3 | 76.7 / 144.5 | 84.8 / 171.2 | | storefront home | 54.3 / 104.0 | 111.4 / 213.5 | 83.0 / — | — / — | | websocket handshake | 2.3 / 5.8 | 4.2 / 11.6 | 2.6 / 6.3 | — / — | Two rows are marked because the servers are not doing the same work in them. The numbers are real; they are just not a fair race, and are shown rather than dropped. ### Then the rival was fully tuned, and the gap did not close Beating a competitor on its default settings proves nothing. So the aaPanel box was tuned the way a competent administrator would tune it, and every number was taken again. - PHP opcache raised from 128 MB to 256 MB, with timestamp validation switched off - Database buffer pool raised from 256 MB to 1152 MB — four and a half times larger - Database log file raised from 128 MB to 320 MB, and the query cache switched off - PHP workers corrected from an over-committed 50 down to a sized 14 - Path cache quadrupled and the web server's buffers doubled Its PHP 8.4 and its JIT compiler were deliberately left switched on. Those are its advantages, and taking them away would have rigged the test. Against the stock box SixPanel was 1.65× / 1.80× faster. Against the fully tuned box it is 1.76× / 1.82×. The gap moved slightly the other way. The database battery did not move at all. A buffer pool four and a half times larger changed nothing, because these reports are processor-bound work over rows that were already in memory. The internals did improve — cache hit rate 99.856% to 99.930%, temporary tables spilling to disk 47.3% down to 22.1% — and the response times did not follow. ### Where the gap actually comes from A speed claim is worth very little without a cause. So the difference was taken apart on the five endpoints that reach PHP on both boxes, one variable at a time. | Configuration | One request | Four at once | | --- | --- | --- | | As the two boxes ship | 1.99x | 1.91x | | After switching off aaPanel's directory restriction | 1.32x | 1.29x | | After also correcting its JIT compiler mode | ≈1.25x | ≈1.21x | - **A PHP directory restriction:** 60% - **The wrong JIT compiler mode:** 8% - **PHP version:** 0% - **Still unexplained:** 32% About a third of the difference is not accounted for, and is published as unexplained rather than credited to us. The leading untested candidate is that aaPanel compiles its own PHP while Ubuntu ships a package. Neither that nor the remaining setting difference can be isolated on one machine, so neither is claimed. ### The shape matters more than the ratio The tax is a fixed cost per request, so it dominates short work and disappears on long work. The same 20.9-second admin report is only 1.17× apart between the two boxes. If your shop is mostly heavy reports, the difference will be small. If it is mostly phone-app API calls — which is what a food-delivery shop mostly is — it is the whole difference. ### The working, in full #### The biggest single cause was one PHP setting, and it cost 16 to 26 ms on every request aaPanel restricts which directories PHP may touch. That is a real security feature, so it deserved a real measurement rather than being written off as bloat. Three alternating pairs, with the "off" arm writing an empty settings file so the per-directory scan still happens in both arms — otherwise the comparison would measure the scan rather than the setting. Every endpoint moved between 17% and 46%. A static file, which never reaches PHP at all, moved by nothing — that is the control, and it is what makes the rest a result rather than a coincidence. Arm-to-arm spread on these boxes is 1% to 13%. The mechanism was then counted three separate ways: 5,862 filesystem lookups per request with the restriction on, 214 with it off, and 217 on SixPanel. With it on, 400 path resolutions add zero entries to PHP's path cache; with it off they add 509. The cache is simply disabled, which is why aaPanel's own tuned cache-size setting bought it nothing. Confirmed on a second machine in the other direction: switching the same restriction on for SixPanel reproduced 17 to 23 ms of extra time per request. Worth knowing if you administer a server: this setting was in a per-directory file that four other places did not show. Reading the value back from the process that actually serves requests is the only reliable check. | Endpoint | Restriction on | Restriction off | | --- | --- | --- | | /api/v1/config | 37.7 | 20.3 | | /api/v1/stores/get-stores/all | 39.8 | 23.5 | | /api/v1/items/search | 40.6 | 24.1 | | /api/v1/categories | 55.4 | 33.7 | | /api/v1/items/popular | 70.7 | 51.5 | | / (admin entry) | 85.7 | 66.4 | | /api/v1/customer/order/list | 154.9 | 128.9 | | static asset (Control — never reaches PHP) | 0.4 | 0.4 | #### aaPanel runs the wrong JIT compiler mode for this application PHP's JIT setting is a four-digit number, not an on/off switch, and the two named modes are different: "function" is 1205 and "tracing" is 1254. A tuning script that only checks whether JIT is enabled will happily leave the wrong one in place and report the job as done. aaPanel ships 1205. SixPanel ships tracing. Three alternating pairs put tracing ahead on 9 of 9 endpoints at one request and 9 of 9 at four at once — geometric mean 5.1% and 6.2%. Any single one of those differences sits inside the noise of these machines. Eighteen out of eighteen falling the same way does not. For 6amMart specifically, tracing is the right mode: function JIT targets tight numeric loops, which a Laravel request does not run. #### Being one PHP version behind costs nothing — measured, not assumed SixPanel installs whichever PHP the release's own archive ships — 8.5 on Ubuntu 26.04, 8.4 on Debian 13, 8.3 on Ubuntu 24.04 — because staying on the distribution's own packages means security updates arrive automatically with no third-party repository in the serving path. The obvious objection is that a newer PHP is faster. The aaPanel box has both versions installed, so it could answer this cleanly. The 8.3 pool was first given the entire 8.4 tuning — it had been left on defaults, which would have rigged the result — and the settings were verified from the running process rather than from a file. Three alternating pairs: geometric mean 8.3 against 8.4 is 0.9994. 8.3 was ahead on 3 rows of 7, and every difference was smaller than at least one arm's own run-to-run spread. The slow admin report agreed. So the rule that keeps SixPanel on the distribution's own packages is free — it costs no speed. There is no ceiling to work around either: 6amMart's composer.json declares a bound below 8.5, but that is a declaration and not a measurement, and running the code on 8.5.4 on both the plain CodeCanyon tree and our own fork produced a byte-identical spreadsheet export and a Laravel that boots. #### What was checked and found not to be the cause Each of these is a plausible explanation someone could offer. Each was measured and ruled out. - **The web server:** Each endpoint was timed over the wire and again inside a single PHP process, on both boxes. The difference is 0 to 7 ms on aaPanel and 3.5 to 5 ms on SixPanel, most of it the encryption handshake. aaPanel's is no larger, despite writing an access log entry per request. - **The database:** Query times effectively identical across all three configurations. Datasets within about 1% on every table, and configurations matching after tuning apart from the patch level. - **How PHP reaches the database:** Both on the local socket, verified from the running process rather than from a configuration file. - **The cache layer:** Counted rather than read from a configuration file: 17.1 cache commands per request on aaPanel, 18.1 on SixPanel. Neither is silently falling back to disk. - **PHP's compiled-code cache:** Zero out-of-memory events, zero hash collisions and zero manual restarts on both. SixPanel at a 99.86% hit rate with 0% wasted. - **The hardware:** Identical down to the processor model and the set of security mitigations enabled. #### The slowest thing in 6amMart is not the server, and no panel can fix it All 297 admin pages were timed on the real 66,701-order dataset. 290 of them answer in under 300 ms. The panel is not broadly slow. Seven pages account for the entire problem. The worst, the day-wise transaction report, takes 20.86 seconds, of which 12.43 seconds is spent inside the database driver — and one single query runs 122 times at 87.6 ms each, which is 10.7 seconds on its own. It is present on every server tested and was untouched by every setting tried, including the full aaPanel tuning pass: 20,925 ms before, 20,470 ms after. This is 6amMart's own code, so no control panel can fix it and none should claim to. It is written up in full against the application itself, and it is the kind of thing our 6amMart installation service exists to address. ## Grouped the way a buyer thinks about the job Two things carry an explicit caveat. The transfer from an old server and the same-box restore were read-verified in the 15 August round and not run. They are marked below. Everything else here was exercised or is a shipped, inspectable surface — but the honest form of the sentence is “this ships”, not “this has been proven on your kind of server”. ### Getting it running From a rented server to a panel login, without a hand-built stack. - One command. The install command is fetched, checked against a published fingerprint, and only then run. If the fingerprints do not match, the command stops and nothing is installed. - It refuses a server it cannot run on, by name, before downloading anything: wrong operating system, wrong processor type, too little memory, another control panel present, or something already using port 80 or 443. - A setup wizard on first login: basics → password → domain → SSL → app → backups. - Autotune at install, and on demand later. It sizes the database, cache and PHP workers from the real machine. - Runs a whole shop on 2 cores and 4 GB. - Caveat: Or move an existing shop in. SixPanel can pull a live install off an old server over SSH — the settings file, the uploads, and a database dump piped across. Not exercised in the 15 August round, read-verified only. Run it against a spare server before you rely on it, and keep the old machine until you have. ### Your domain and HTTPS Real certificates, renewed for you, and Cloudflare handled properly. - Free Let's Encrypt certificates, renewed automatically by a daily job. - More than one domain per shop, per target (admin, storefront, websocket), each with its own primary, SSL and Cloudflare flags. - Cloudflare-aware. It first tries a real Let's Encrypt certificate through the Cloudflare proxy, which works with Full (strict). If that cannot be done, it falls back to a 10-year self-signed origin certificate, which needs Full. It ships Cloudflare's IP ranges so your logs show the visitor's real address, not Cloudflare's. - One Cloudflare token, and the panel manages a set of Cloudflare options for you. It shows desired-versus-live for each item, and a push or pull sync. Your own rules survive a write. - A firewall page that prints the exact rules for your server, plus both Cloudflare range lists and the commands to check them. The panel never touches your provider's firewall itself. ### Shipping code changes Two kinds of update that are never confused with each other. - Push to deploy. A signed webhook from your git host starts the deploy. - Deploys → Update moves your 6amMart code. Settings → self-update moves SixPanel. Neither one touches your settings file, your data/ folder or your database. - History and rollback, with the last 30 deploys kept. - A clean-tree guard. If you edited files on the server, the update refuses and names the files instead of overwriting your work. ### Not losing anything Scheduled, incremental, and proved once a week instead of assumed. - Incremental backups (restic), on a schedule, with retention. - Four destinations: the same server, S3, SFTP, or Google Drive. - A weekly automatic restore test into a throwaway database — your live data is never touched, and the result appears on both the Backups page and the Health page. - A backup holds every project's database, the uploaded files, and the application settings file. It does not hold your code — that comes back from git. - One shared backup password, generated once and kept in the panel's state. Lose it and no backup can ever be opened again. - Caveat: Restore was read-verified, not run, in the 15 August round. See the two restore limits further down as well — they are the reason this matters. ### Running it day to day, without being a sysadmin The panel names the problem and gives you the button. - Health page: about 20 checks, sorted into needs-attention, healthy and information, each with one consequence sentence and one fix button. Each check is capped at 2 seconds and the whole page at 10 seconds, so a hung check cannot hang the page. - Three sources disagree on that count. The shipped manual says “more than twenty”, the code inventory counts about 20 checks, and an older page spec says about fifteen. This page prints about 20 — the lower of the two figures grounded in the shipped product. - A watchdog that restarts services which are running but not working. A process supervisor will not restart something that is alive and broken, because nothing has crashed. SixPanel's own loop does, and its checks test whether the work is getting done rather than whether the process exists. - A jobs engine. One long job at a time, the rest queue. The log streams live into the browser. The last 20 jobs are kept, 2,000 lines each. - A settings-file editor for your app that keeps your comments, your ordering and your unrelated lines, gives each key the right kind of input, and marks the keys the stack owns as read-only. - A file manager fenced to exactly two folders: your admin code and your storefront code. - phpMyAdmin on demand — started and stopped from the Database page, never left running. - Slow-query capture you can switch on and clear from the Database page. - A sixpanel command on the server, with a manual page, a cheat sheet, a numbered menu, a did-you-mean matcher and shell completion. - The full customer manual inside the panel, behind the same login — 24 task pages. - A support bundle in one command. It collects versions, health results, service states, disk usage and the last 500 lines of every log. Before it is written, your settings file is cut down to key names only, the panel's own state file is not collected at all, and the secret code in your panel link plus common password-shaped values are masked. ### Letting other people in Time-limited access instead of handing over your password. - Temporary logins for a developer: their own name and password, expiring after 1 hour, 8 hours, 24 hours or 7 days, up to 20 live at once. The password is shown exactly once. They can run the site. They cannot change who gets in, and they cannot read your secrets. - A read-only demo login for showing the panel to somebody. Two-hour sessions, every write refused, sensitive values masked. - An activity log, and a list of live sessions you can revoke individually or all at once. - Caveat: The activity log does not cover everything. Creating, editing and manually running a scheduled task are all recorded, but deleting one writes no audit record at all. ### More than one shop on one server Separated by construction, not by convention. - Each project gets its own unix user, its own database and database user, its own application folder, its own site configuration and its own cache instance on its own socket — so one shop cannot read another's cached secrets, and clearing the cache on one can never empty another. - Two projects cannot end up sharing a database: the name is derived from a validated, unique slug. - Plan roughly 2 GB more RAM and 1–2 more cores per extra shop — budget 2 cores, the top of that range, since under-provisioning is the expensive mistake. ### Speed that is already configured A five-second micro-cache in the web server on your own machine, shaped around 6amMart's own request patterns. - A five-second cache in nginx over a fixed list of public catalog endpoints. If 100 requests arrive on the config endpoint inside one five-second window, the cache turns them into one PHP start instead of 100 — that is arithmetic from the cache window, not a measured throughput result. Storage is capped at 64 MB, with 60-second idle eviction. - Why it matters here specifically: the storefront renders on the server, so every shopper page becomes several API calls back into the same box, and every mobile-app cold start is another 15–20 API calls. - It never serves a personal or signed-in response. Any Authorization header bypasses it. Any cookie at all bypasses it. nginx refuses to store any response that carries Set-Cookie. A separate deny list covers admin, vendor panel, login, checkout, cart, order and payment callbacks. - Zone, module and language are part of the cache key, so one city's stores can never be served to another city. - It keeps the shop up when PHP does not. If the PHP pool wedges, nginx serves the slightly stale copy and refreshes in the background — a working storefront instead of a wall of 502 errors. - Everything else follows the hardware too: the database, PHP's compiled-code cache, cache memory and web-server buffers are all sized by autotune from the real machine. - Request-rate tiers sized for real networks. Tight limits on login, OTP and password-reset; wider ones for ordinary browsing; separate ones for search and for cart and order writes. The documentation calls this what it is — a flood shield, not DDoS protection — because per-address limits cannot be precise when a whole city shares one carrier IP address. - “Edge” on this site means Cloudflare, which is the actual edge layer. This cache is not that, and is not called that. ### Optional pieces Turn them on when the shop needs them. - Live order tracking over websockets (Reverb). - The optional Next.js customer website, with its static assets served as immutable. - Selling through the mobile apps only, with no website, is a supported shape. ### Shop check-up (SixPreflight, included) It checks the settings inside your shop, as opposed to the server SixPanel looks after. - SixPreflight is bundled and mounted inside the panel as the Shop check-up page. It carries about 134 checks, a weighted score and a letter grade. - Why 134 and not a bigger number: three internal sources give three answers. A direct count of unique scan check keys in the code gives 163; the engineering handover records 134–136 and instructs the lower of the two; an older page spec says about 100. This page prints ~134, the lowest figure a current source defends. - When it runs inside SixPanel it changes behavior on purpose: the copy-and-paste config blocks disappear for the layers the panel owns, and the settings that belong to your shop's own admin panel are scored separately from the server. ## Three claims, each with the reason it is true rather than an adjective ### We benchmarked ourselves against a fully tuned rival, and published where the win comes from Anybody can publish a benchmark they won. The test worth running is the one where the other side is set up properly — so the aaPanel box was tuned first: compiled-code cache doubled, database buffer pool four and a half times larger, workers corrected from an over-committed 50 to a sized 14. Its PHP 8.4 and its JIT compiler were deliberately left switched on, because those are its advantages. The gap did not close. 1.65× / 1.80× against the box as it ships; 1.76× / 1.82× against the tuned one. It moved slightly the other way. Then the difference was taken apart one variable at a time. About 60% of it is a single PHP directory restriction, about 8% is the wrong JIT compiler mode, and the PHP version is worth exactly nothing. About 32% is still unexplained, and is published as unexplained rather than credited to us. Why this counts: A ratio with no cause behind it is a marketing number. This one has a measured cause for two thirds of itself and an admission for the rest. ### We measured three operating systems, got a tie, and published the tie Three servers from one provider, ordered together, identical except the operating system. Same software, same tuning, same data — a real shop's database with 66,701 orders. This round asks which operating system, not which runtime; it was run on the container one. They tied. The gap between the three boxes (3.5 %) was smaller than the gap one box had with itself across two runs of its own configuration (8.6 %). So the recommendation was decided on how long each system keeps getting security updates, not on speed. And the report threw out its own most flattering rows because they were arithmetically impossible. Why this counts: The willingness to publish a negative result is the evidence that the method is real. Anybody can publish a benchmark they won. ### Caching and limits shaped around 6amMart's own request patterns nginx micro-caching is available to anyone. What is specific here is everything around it, and none of it can be written by somebody who does not know this application: - The allowlist of exactly which public endpoints may be cached, matched on the raw URI, default-deny. - Zone, module and language in the cache key, because 6amMart serves different stores to different cities from the same URL. - Five bypass rules that make a personalized response impossible to cache. - Request-rate tiers that separate login and OTP from browsing, from search, from cart writes. - Timeouts deliberately pinned to each other — PHP 120 s, nginx read 120 s, worker terminate 130 s — because 6amMart runs Excel exports, bulk imports and heavy store reports inside the web request rather than in the background. Why this counts: An unauthenticated search flood used to be able to fill the cache server and start evicting sessions, silently signing out logged-in shoppers. It took about 278 requests, roughly 67 seconds on one connection, on a two-project 8 GB test box. That was measured, bounded, and measured again on the same box — across the three floods the evidence file tabulates, zero evictions, session alive every time. ## SixPanel compared with aaPanel, CloudPanel, and doing it by hand This is a comparison for one job: running a 6amMart shop. It is not a comparison of these panels in general, and it would be dishonest to present it as one. | For the job of running 6amMart | SixPanel | aaPanel | CloudPanel | Plain server, by hand | | --- | --- | --- | --- | --- | | What it is built for | One application only — 6amMart | General-purpose web hosting — not tested by us; read the vendor's own feature list | General-purpose web hosting — not tested by us; read the vendor's own feature list | Whatever you build | | Speed, same hardware and same shop | Measured: 1.76× faster than a fully tuned aaPanel at one request, 1.82× with four at once, across the endpoints that reach PHP on both | The comparison above. We installed it, tuned it, and left its PHP 8.4 and its JIT in place | Not tested by us — no speed claim is made about it | Whatever your engineer achieves | | MariaDB 10.11 on Ubuntu 26.04 / Debian 13 | With the Docker runtime, yes — the image is pinned at 10.11 whatever the host runs. The native runtime takes MariaDB 11.8 from those releases' own archives instead, and measured against 10.11 on the same shop that is a wash. | Not available. Neither release carries 10.11 in its archive, and this panel installs from host packages | Not available — same reason | Only if you run containers yourself | | Other websites, mail, DNS, FTP on the same box | No. The installer refuses a server that already runs aaPanel, CloudPanel, cPanel or Plesk, or has anything on ports 80/443 | They win here. This is what general panels are for — not tested by us; check the vendor | They win here — not tested by us; check the vendor | Possible, and entirely your problem | | Users, roles, teams | No. One admin account. Plus temporary logins and one read-only demo login | They win here. Not tested by us; check the vendor | They win here. Not tested by us; check the vendor | Whatever you configure | | Tuned for this application out of the box | Autotune writes PHP workers, database buffer pool, cache memory, temporary tables, buffers and the redo log from the real machine, 1 core / 2 GB → 16 cores / 32 GB — and both places that compute it are checked against each other on every build | Not tested by us; check the vendor | Not tested by us; check the vendor | Whatever you know | | 6amMart-shaped micro-cache | Built in: allowlist, zone/module/language in the key, 5 bypasses, stale-serve when PHP wedges | nginx micro-caching is available anywhere — somebody has to write the 6amMart-specific rules. Not tested by us | Same. Not tested by us | Same | | Backups | restic, scheduled, retention, four destinations, weekly automatic restore test | Not tested by us — compare the automatic restore test specifically | Not tested by us — same | Whatever you script | | Free HTTPS | Yes, with automatic renewal and Cloudflare-aware issuance | Not tested by us; check the vendor | Not tested by us; check the vendor | certbot, by you | | Deploys | Push to git; history and rollback with the last 30 deploys kept; refuses to overwrite your edits | Not tested by us; check the vendor | Not tested by us; check the vendor | Whatever you script | | Document root stays where you put it | Yes | Recorded on a live install: aaPanel silently reverts the document root whenever any site setting is saved | Not tested by us | Yours to get right | | Track record | SixPanel is on its current release, and it is new. We cannot show you years we have not had | Not tested by us; check how long the vendor has been shipping | Not tested by us; check how long the vendor has been shipping | Linux is 30+ years old | | Readable source on your server | They may win here. The panel backend ships as V8 bytecode with the readable sources removed. We call that deterrence, not security | Not tested by us; check the vendor | Not tested by us; check the vendor | Everything is readable | | Who fixes it when it breaks | Health page names the fix; support bundle in one command | Not tested by us; check what support the vendor offers | Not tested by us; check what support the vendor offers | You | ## Which operating system to install, and why the reason is support runway rather than speed Both runtimes recommend Ubuntu 26.04 LTS. Ubuntu 24.04 LTS and Debian 13 are the other two supported releases. Not because it is faster. Six axes were measured on identical hardware — the operating system, PHP, MariaDB, nginx, Redis and the kernel — and no version swap produced a reportable difference. Two byte-identical machines disagreed with each other by 11.6 % on 20 of 20 rows, so the noise floor is larger than any effect found. The native runtime takes PHP, MariaDB, nginx and Redis from the release's own distribution archive, and all three supported releases carry a working set: Ubuntu 26.04 gives PHP 8.5 and MariaDB 11.8, Debian 13 gives 8.4 and 11.8, Ubuntu 24.04 gives 8.3 and 10.11. With speed tied, the only axis left is how long security updates keep arriving — and 26.04 is patched until April 2031. SixPreflight recommends Ubuntu 26.04 LTS, for the same reason the native runtime does. Safe to say, and this page says them - SixPanel runs the full 6amMart stack on Ubuntu 26.04, Ubuntu 24.04 and Debian 13 — the three that were measured — verified on real production data. - Every supported release carries a working database in its own archive — MariaDB 11.8 on Ubuntu 26.04 and Debian 13, 10.11 on Ubuntu 24.04 — and measured on the same shop, 11.8 against 10.11 is a wash. The container runtime pins 10.11 in its image if you want that version specifically. - Ubuntu 26.04 LTS is recommended, and gets security updates until April 2031. - A 2-core / 4 GB server served about 53 requests per second on the search endpoint, at 20 concurrent users, over 30 seconds, on a live-sized catalog of 66,701 orders, with the database answering 99.99 % of reads from memory. - A fresh install completes unattended in about five minutes (273–303 s measured; the slowest of the three, 303 s, is the figure the copy is written against). Not supported by the measurements, and this page does not say them - That any one of these operating systems is faster than another. The differences measured are smaller than the noise of a single machine. - Any percentage-faster figure derived from the internal latency tables. The spread between boxes is 3.5 % against 8.6 % self-variation — which is why no per-cell latency table appears at all. - Ubuntu 26.04's under-load latency figures. They are arithmetically impossible and were excluded. - Anything about disk speed. That column reflects which physical machine each server landed on, not the operating system — and it bought nothing either way, because the database answers 99.99 % of reads from memory and stops touching the disk once warm. - Any general “6amMart is this fast” figure. 53 requests per second describes one endpoint, on this data, on 2 cores, at 20 concurrent users for 30 seconds. - Anything about servers of 8 GB or larger. Only 4 GB machines were measured in this round. - Anything about Debian 12's speed. The native runtime refuses it by name, and it was never measured. ## What you need, and what a fresh install actually takes | Requirement | Detail | | --- | --- | | Operating system | Ubuntu 26.04 (recommended), Ubuntu 24.04, or Debian 13 — exactly three. Nothing else: older releases, including Debian 12, and every other distribution are refused by name before anything is downloaded. Debian 12's free security support ended in July 2026; the container runtime still installs on it, but a new shop should not start there. | | Processor type | x86_64, or arm64 (also written aarch64). | | CPU cores | 2 cores is the comfortable size for one shop. Autotune supports 1 core up to 16 cores. | | RAM | 2 GB is the practical minimum. The installer refuses below about 1.2 GB and warns below 2 GB. 4 GB is the comfortable size for one shop. | | Disk | Not one of the installer's gates. The three measured machines each had 79 GB. The panel refuses an upload that would leave less free than the smaller of 2 GB and 10 % of the disk. For a native (non-container) 6amMart install, SixPreflight asks for 20 GB free and prefers 40 GB. | | State of the server | Fresh. No aaPanel, CloudPanel, cPanel or Plesk. Nothing already listening on ports 80 or 443. | | Ports open at your provider | Exactly three: your panel port (a random high number picked at install), 80, and 443. Nothing else, ever. | | Access | The root login for the server. The installer refuses to run as anyone else. | | Your code | Your 6amMart code in a private git repository. SixPanel installs from git, not from a zip. | | Your phone | An authenticator app. Two-factor login is required for the owner's account and cannot be switched off. | | A domain | And the ability to edit its DNS records. | | A second shop | Roughly 2 GB more RAM and 1–2 more cores per extra shop. Plan for the top of that range — 2 cores — it is the conservative end. | | What it costs | Nothing. SixPanel is free and published on CodeCanyon, with the first installation and setup free as well. There is no licence server, no key to renew and no purchase code in the install command. | What SixPanel installs: nginx, PHP-FPM, MariaDB, Redis and a Node.js panel service, all supervised by systemd and all from the release's own distribution archive — PHP 8.5 with MariaDB 11.8 on Ubuntu 26.04, 8.4 with 11.8 on Debian 13, 8.3 with 10.11 on Ubuntu 24.04. The Docker runtime installs the same stack as containers, pinned at PHP 8.4 and MariaDB 10.11. Panel interface languages: 8 — English, Spanish, Arabic, Portuguese, French, German, Indonesian, Bengali. ### You must already have - A VPS you have root on — not shared hosting - Ubuntu or Debian, freshly installed - About 1.2 GB of RAM to install, 2 GB or more to run comfortably - A domain name you can point at the server - Your 6amMart licence and code (we do not supply either) ## Security — only what can be shown Every item here can be checked in the product. Nothing here is an assertion of general safety. The gaps in this area are in the honest-limits list below, not hidden. ### Getting to the panel at all - The panel answers only under a secret address. Everything else returns a blank “not found” page, so a port scanner cannot tell the panel apart from a closed port. The panel port itself is a random high number chosen at install, different on every server. - The secret address is a gate in front of the login, not a substitute for it — username, password and two-factor code all still run behind it. - A wrong entry code is compared in constant time, and is answered with the same blank “not found” as anything else, after a fixed 200 ms delay. It counts toward a per-address lockout. The delay is capped at 32 misses in flight; past that cap the “not found” comes back immediately. So a wrong code costs the same as anything else up to that cap, not always — 20 wrong codes in 15 minutes lock the address for 30 minutes either way. - On a fresh install the login name is generated — admin plus four random characters, for example admin7f3q — so a robot that finds a login page has no name to aim at. An install that already carried a password hash keeps the plain name admin. - Optional panel-domain lock. When a panel domain is set, even a direct request to the server's IP address gets the same blank “not found”. The way back in is over SSH. ### Signing in - Password hashing (bcrypt), a signed session cookie, and two-factor codes that cannot be switched off for the owner's account. - A lockout that survives a restart: 20 failed passwords in 15 minutes locks that address for 30 minutes. Five wrong two-factor codes do the same. - An optional IP allow-list on the login form — and saving a list that does not contain your own address is refused, so you cannot lock yourself out. ### What the panel refuses to do - Default-deny on every route, plus a cross-site-request check on every change. The deploy webhook is the single exception and proves itself with a signature over the raw request body instead. Duplicate deliveries and deliveries older than five minutes are ignored, and every rejection is written to the activity log. - The file manager cannot reach the stack. It is fenced to two folders — your admin code and your storefront code — with both a prefix check and a real-path check. The panel's own folder, the data folder and the settings file are unreachable from that API. This is stated as a security boundary, not a design preference. - Trust decisions use the real network peer, never a header a client can write. - Case-sensitive routing is set before the first middleware, which closed a real bypass where a differently-capitalized path slipped past a case-sensitive authentication test. ### Secrets - The panel's state file is owner-only (0600) inside an owner-only folder. The stack settings file is 0600. The command-line socket is an owner-only Unix socket — root-only by file permission, never exposed over the network. - The first-boot password is hashed, then blanked from the settings file and removed from the process environment, so it cannot be read back out afterwards. - A wizard install used to leave the application settings file world-readable, talking to an unprotected cache. That is fixed — every install, update, rollback and transfer now re-asserts the infrastructure keys and re-locks the file to 0600. - SSH passwords used for a transfer never appear in the process list. They are passed through the environment and scrubbed from every log line. - The support bundle is filtered before it is written — settings reduced to key names, the panel's state file not collected at all, the secret entry code and password-shaped values masked. ### Keeping one shop out of another shop's data - Every project runs as its own unix user, with a 0700 application folder and a 0600 settings file. The barrier is the kernel refusing a different user — not a check inside PHP, which a PHP bug can step around. - Each project also gets its own database user with grants scoped to its own schema, its own PHP worker pool on its own socket, and its own cache instance with its own password and its own memory ceiling. - This was tested by attacking it rather than asserted. Every cross-project read was actually attempted from inside a project's PHP, on this panel and on aaPanel. All of them failed on both — but where the two overlap they part company: a private file that another site had written into the shared temporary directory was readable on aaPanel and refused here. - PHP is additionally confined by a kernel mount namespace. It closed the shared temporary directory (57 visible entries down to 0), the panel's own code, every project's site configuration — which means every domain on the machine — and the visible process list (138 down to 6). Measured cost: none. 217 filesystem lookups per request before, 217 after. - Two further proposals were rejected by measurement rather than shipped: hiding the web server's configuration closed nothing and broke the check-up tool, which reads it, and blocking the panel's directory wholesale would have taken the database administration tool down with it. - The one-shared-cache problem this replaced was real, and it is described in full in the testing section below rather than left out. ### Releases, and what your server checks before it trusts one - Release artifacts are signed, and the signing key is offline. The panel's Settings → self-update checks the signature against a key pinned on your server, refuses a build number at or below the one installed, and checks the file's hash. - The install command is fetched and checked against a published fingerprint before it runs. If the downloaded file does not match, the command stops and nothing is installed. - Every update path is now signature-verified — the panel's Settings → self-update, the install command, and the command line's own self-update. The third one used to have neither check; it does now. - The installer itself is verified, not just the release it applies. Your server reads a published record of the installer's fingerprint, checks the file against it, and refuses to run anything that does not match — so a replaced or proxied update host cannot hand your server a modified installer. - A new signing key is adopted only when the key already pinned on your server has itself signed it — never because the update service says so, and never because the new key signs the release it arrived with. Both of those a compromised host can produce; the old key's signature over a key it never saw, it cannot. That is what stops anyone re-keying your server. ## Two independent rounds said "not ready". Here is what they found. Most software pages tell you what a product does. This one also tells you what was wrong with it before release, because how a thing is tested is the only honest evidence of how well it works. ### One verification round, by the numbers - **Routes exercised, 283 page loads across five screen sizes in light and dark:** 52 - **Interface text keys checked, in each of 7 languages:** 2,740 - **Panel workflows driven end to end, on both 6amMart codebases:** 34 - **Independent rounds whose verdict was "not ready":** 2 ### One theme ran through every serious finding Every worst defect was a green surface over a broken thing. A page that says "success", a version number that says "updated", a health check that says "healthy" — each one true as a statement and false as a fact. That is why the checks below now test the outcome rather than the exit code. ### What the rounds found, and what happened to it These are ours, they were serious, and they are fixed. Open any one for the detail. #### Backups were running, reporting success, and contained no database — Fixed The backup tool's exclude rule filtered the whole run, so excluding the working directory also cancelled the database dump files that the same run had explicitly named. The tool stored the empty directory and exited successfully. Six snapshots — one of them tagged as the database backup — held 10,888 files and not one database dump, while the Backups page reported success and a repository size throughout. It hid because the verification threshold was 21 days against a weekly schedule. Both were wrong, and both are now gates rather than settings. Fixed, and a restore was then proven rather than assumed: a fresh backup holds a 39 MB database dump that restores 192 tables and all 66,701 orders. #### The customer storefront was listening on a public port, outside every protection — Fixed It was bound to every network interface on a plain unencrypted port, bypassing the web server and therefore the certificate, both rate limiters, the cache and every security header. It was an assumption carried over from the container product with nothing behind it on a native install. The test also established that the hosting provider applies no firewall by default, so this was unmitigated on a default install rather than theoretical. Fixed, verified from the public internet, and verified again after a reboot. #### Deploy, rollback and activation updated the code and the site kept serving the old version — Fixed SixPanel keeps PHP's compiled-code cache pinned — a deliberate, measured speed choice — which means code that changes without a reload is never executed. Only one of the four paths that write code performed that reload. So a deploy pulled new code, ran the database migrations, rebuilt the caches and restarted the workers while the website served the old version indefinitely. Rollback did nothing at all. Demonstrated rather than argued, through the real web server on a file already cached: before the edit it served version one; after the edit with no reload it still served version one while the disk held version two; after the reload it served version two. Fixed at all four sites. The lesson kept: a performance setting that depends on discipline somewhere else will eventually not get it, so the reload is now part of the same function that writes the code. #### One shop could read another shop's payment and email secrets out of the shared cache — Fixed The cache was a single shared service behind one password that every project's settings file contains. Starting from one project's own user, a probe read another project's cached mail password, push-notification credentials, maps keys, SMS gateway key, anti-bot secret and two payment gateways' secret keys — and writing was permitted too, which made the victim's cached mail configuration alterable. The fix is one cache instance per project, on its own socket, in its own directory, with its own password and its own memory limit. The boundary is the filesystem; the password is the second lock. Proven by turning the attack back on it: the probe went from succeeding to being refused in both directions — refused while holding the target's own password — and was checked again against a deliberately broken permission to confirm the test itself still works. Measured cost: 3.2 MB of memory per project. The PHP worker count is unchanged on 18 of 20 server and project combinations, and the socket is actually faster than the network loopback it replaced. Moving the live data took 13.9 milliseconds and signed nobody out. #### Updates were landing on disk without taking effect, three times in one round — Fixed A server took an update, reported the new version, and carried on serving with the configuration written the day it was installed. Four different paths can put state on a server, and they were not delivering the same set. A full audit of those four paths found roughly fifteen categories of state that a fresh install produced and an updating server never received — the entire sizing ladder, the database configuration, the default PHP pool, a file included by every site, the alerting service and its failure hooks, and more. One case was invisible in two layers at once: every server on the published channel was failing the same step on every update, forever, and underneath it the command-line tool's own version check reported itself as current when it was three releases behind. Fixed, and now enforced by a check that runs on every build: every function that writes state must declare whether an update delivers it and why. Verified against 14 deliberate sabotages, all 14 caught. Then proven end to end: a server updated from the published channel and a server freshly installed produced 1,447 of 1,447 configuration lines byte for byte identical. #### On untouched CodeCanyon 6amMart, the install finished and the admin panel was unusable — Fixed Vendor 6amMart locks its admin panel behind a purchase-code activation step after login. SixPanel never asked for the code, never mentioned it, and reported the deployment as finished. It stayed invisible for a long time because our own optimised copy of 6amMart has that check disabled, so the product's entire test history had run against a codebase where the gate does not exist. The wizard now collects the purchase code and completes the application's own activation. A trap was closed on the way: the application skips the licence server entirely when the request comes from the machine itself, which a command-line request does, so any invented code would have been accepted with no packet leaving the server. Two related things were fixed with it. The storefront now installs from the zip a CodeCanyon buyer actually has, rather than requiring a git repository. And vendor projects are no longer deployed in development mode, which printed the login captcha's own answer into the page. #### The update signature protected the release but not the installer that applied it — Fixed Twelve adversarial cases now pass against the published artifact, and the same test harness produces twelve failures against the previous installer — two of them a stranger's installer succeeding and leaving a stranger's key pinned on the server. Walking further back found something worth stating plainly: a signature attests to what was built, not to what built it. The build was fetching its own tools at whatever the latest version happened to be, so a dependency tree was re-resolved on every build and shipped inside the signed artifact. Both build tools are now pinned to exact versions under a committed lockfile. A separate near-miss from the same round: a certificate command had gained an option that the installed version does not have, which would have made every renewal fail silently until certificates expired. It survived review because asking that tool for its version exits successfully no matter what other nonsense is on the line. #### Twenty-four places where the panel told the owner something that was not quite true — Fixed "Healthy overall" on a server the operating system itself called degraded — nothing in the health code had ever asked it. On the release server a scheduled service had been failing every 60 seconds for a day, firing its failure hook 1,440 times, while the headline read healthy. Self-healing treating a check that could not run as an observation of health. A 135-fold disagreement between two error counts. Disk usage accounting for 18.4% of the used space and presenting it as the whole picture — now 92.7%. An unfinished setup wizard that never requested the version endpoint at all, and mobile navigation that collapsed to zero width whenever the update notice was showing. All 24 closed. Two of the last six reported defects turned out not to be real, and both were dropped with the evidence rather than fixed for appearance. #### Every installed server was running files owned by a user that does not exist on it — Fixed The build machine's own user and group were baked into the artifact — 459 files on one server, including one that had only ever taken the published install command. Not exploitable as it stood, but it meant the system was executing code it did not own, which is not a state worth leaving alone. Corrected by the update itself: 459 files with the wrong owner became zero. ### What held up The same rounds also confirmed the things that were supposed to work, and those are worth stating with their numbers rather than as adjectives. - **Full reboot:** Back over SSH in 79 seconds, zero failed services, every service in byte-identical state to the snapshot taken before the reboot, both websockets connected, no manual step. - **Killing the panel outright:** Back in about 4 seconds. - **An ordinary update:** Zero seconds of downtime, 91 of 91 requests answered normally throughout. - **Restore from backup:** 192 tables and 66,701 orders, from a real scheduled backup rather than one made for the test. ### Still open, and stated here rather than left out - One database counter reads badly on the native server — temporary tables being written to disk on 59.8% of queries. It is a query-shape problem rather than a sizing one, and it is new since the last round. - The container product needs a release to carry the backup fix and the DNS work described above. - A stale failed background job on the test server is the entire reason its own check-up scored 88 instead of 97 — the score caps whenever any row is bad, and the underlying raw scores differ by 0.03 across about a hundred checks. None of this is unusual for server software. What is unusual is publishing it. If a panel's marketing page has no list like this, it does not mean there was nothing to find. ## Honest limits Every one of these is true today. - **It takes the whole server.** — No other websites, no other control panel, nothing else on ports 80 and 443. - **One admin account. No roles, no team accounts.** — Temporary logins and a read-only demo login are the sharing mechanisms. - **The panel is root-equivalent on the machine.** — Anyone who can log into it can run anything on that server. That is what a server panel is. On the Docker runtime, reboot, operating-system update and self-update additionally work by launching a privileged container that steps into the host filesystem. - **Restore is not yet a “move to any server” button.** — A backup run covers every project, but restore currently targets the default project. Restoring onto a different machine leaves the old machine's passwords and paths in place, and the application cannot connect until you press Update. The restore job also does not run database migrations, so an older backup under newer code stays behind the schema. Both have a working manual step; neither is automatic today. The restore path itself was read-verified and not run in the 15 August round. - **A code rollback does not undo database migrations.** — If a migration has run, rolling the code back needs a backup restore. - **The panel picks up a renewed certificate on restart.** — The daily renewal reloads nginx; the panel reads its own certificate once at boot. - **Moving a shop in from an old server was read-verified, not run.** — That was the 15 August round. Treat it as supported, not as proven on your kind of server. - **The self-healing watchdog only sees services that declare a health check.** — On the container runtime the optional websocket and storefront containers do not declare one yet. Separately, and found by testing rather than by reading: self-healing once reported a successful repair while a background worker had been stalled for 14 minutes with 250 jobs frozen behind it. Everything it can genuinely observe, it now reports as an observation; everything it cannot, it now says it cannot. - **The panel's own code is not readable on your server.** — Its backend ships as V8 bytecode and the readable sources are removed from the build; the browser files are minified and obfuscated. That is deterrence, not protection — anyone determined can still work out what it does. Your 6amMart code and your data are untouched by this. - **A signature attests to what was built, not to what built it.** — Every update path verifies its signature now, and so does the installer that applies it. But walking backwards from the signature found something worth saying out loud: the build machine had been fetching its own tools at whatever version happened to be latest, so a dependency tree was re-resolved on every build and shipped inside the signed artifact — genuinely signed, and not reproducibly the same bytes twice. Both build tools are now pinned to exact versions under a committed lockfile. The general point stands for any signed software you install: the signature covers the output, and you are still trusting whoever ran the build. - **The activity log has a hole, and the step-up rules are uneven.** — Deleting a scheduled task writes no audit record, while creating, editing and manually running one all do — so deleting a panel-level root task leaves no trace. Separately: a panel-level scheduled task requires you to re-enter your password, but reboot, operating-system update and panel self-update — all root on the host — require only a valid session. - **Three panel settings are dead configuration.** — On the Docker runtime the panel's API rate limit, its heavy-path rate limit and its upload size cap are read by the code but never passed into the panel container, so setting them in the settings file changes nothing. The documentation says never to point an administrator at them. - **No Kubernetes.** — There is no Kubernetes driver in the panel. - **PHP's JIT compiler is on in one runtime and off in the other.** — SixPanel runs PHP's tracing JIT. Against the mode aaPanel ships it measured faster on 9 of 9 endpoints at one request and 9 of 9 at four at once; whether switching JIT off entirely would be faster still on this runtime has not been tested. On the container runtime JIT is off, because there it measured slower on 11 of 12 endpoints and tied on the twelfth. Same setting, two stacks, opposite answers — both are what the measurement said. Brotli and HTTP/3 at the origin are off on both, deliberately: Cloudflare does that layer. - **The background queue uses the database, not Redis.** — Redis measured 1.76× faster for queue throughput and was still declined, because under memory pressure a Redis queue can be evicted silently — 50 queued jobs went to 0 with nothing logged and no error raised. Nothing order-critical is queued at all. - **Rate limiting is a flood shield, not DDoS protection.** — Per-address limits cannot be precise when a whole city shares one carrier IP address. Cloudflare is the real layer for that. ### It deliberately does not - Host anything other than 6amMart — no WordPress, no unrelated sites - Run mail for your domain - Replace a general panel like aaPanel or CloudPanel if you need one box for many different sites - Supply, licence or resell 6amMart itself ## SixPanel is the server. The optimized code is 6amMart itself. SixPanel makes a 6amMart install fast to set up, safe to update and cheap to run. Making 6amMart's own screens faster is separate work, and it comes with the installation service rather than as an extra — measured at 10× to 22× faster on every customer-facing screen, on a live server. Those screens went from 0.5–8.19 s to 45–370 ms. The two sets of numbers measure different things and are never blended into one table. SixPanel's are server numbers — the same application, served by different stacks. The optimised code's are application numbers — the same stack, running different code. The slowest thing measured anywhere in this round was neither: one 6amMart admin report at 20.9 seconds, which no server setting moved. The optimized code is not something you buy separately. There is no second license, no second price and no second release train — it is how the existing 6amMart installation service is delivered, at the same $300 install. When 6amMart's vendor ships a new release, the published catalog rule applies unchanged: update or upgrade to a newer script version is 50 % of the install price. Every install ships on the latest 6amMart release. ## Questions people actually ask ### What is SixPanel? A server control panel for one job: running a 6amMart shop on your own server. It installs the web server, database, PHP, cache, background worker, scheduler, websocket server and HTTPS certificate, and then gives you a web page to run all of it from. It comes in two runtimes — one that installs directly on the machine, which is the recommended one, and one that uses containers. ### Does SixPanel include the 6amMart script? No. You buy 6amMart from CodeCanyon. SixPanel installs the code you already own, from your own private git repository. SixPanel itself is free and published separately on CodeCanyon, and its install command is public — the same one for everybody. ### Which operating system should I install? Ubuntu 26.04 LTS, on either runtime. The native runtime supports exactly three releases — Ubuntu 26.04, Ubuntu 24.04 and Debian 13 — and takes PHP, MariaDB, nginx and Redis from whichever one you pick. Speed is not the reason: no version swap across six measured axes produced a reportable difference. Security updates are: 26.04 is patched until April 2031, against May 2029 for 24.04 and August 2028 for Debian 13. Debian 12 is refused by name on the native runtime; the container runtime still installs on it, but its security support ended in July 2026, so do not start a new shop there. ### Why is the recommendation about support runway rather than speed? Because speed did not decide anything. Six axes were measured on identical hardware — the operating system, PHP, MariaDB, nginx, Redis and the kernel — and no version swap produced a reportable difference. Two byte-identical machines disagreed with each other by 11.6 % on 20 of 20 rows, which is larger than every effect found. What does differ is how long each release keeps receiving security patches, and an operating system running out of support is the one event that forces a full server rebuild. Ubuntu 26.04 LTS has the longest runway of the three, to April 2031. ### How small a server can I use? Two processor cores and 4 GB of RAM run a whole shop — that is the size we measured on. The installer refuses below about 1.2 GB and warns below 2 GB. For a second or third shop, plan roughly 2 GB more RAM and 1–2 more cores each. ### How fast is it? Measured against aaPanel on identical hardware — 2 cores, 4 GB, the same shop with 66,701 orders — SixPanel answered 1.76× faster at one request and 1.82× faster with four arriving at once, across the endpoints that reach PHP on both machines. aaPanel was fully tuned first. The full table, the method and the part still unexplained are all above. ### How long does the install take? About five minutes, unattended, on the container runtime — 273 to 303 seconds measured across three operating systems. The native runtime has not been timed the same way, so no number for it is printed here. Getting from a rented server to a live shop, including DNS, the certificate and installing your code, takes about an hour on the first server either way. ### Can I host my other websites on the same server? No. The installer refuses a server that already runs aaPanel, CloudPanel, cPanel or Plesk, or that has something using ports 80 or 443. SixPanel manages the web server, the certificates and the firewall plan for the whole machine, and two systems doing that on one box break each other. Running more 6amMart shops on the same server is supported. ### Can I give my developer access without giving them my password? Yes. Create a temporary login with its own name and password, expiring after 1 hour, 8 hours, 24 hours or 7 days. It can run the site. It cannot change who gets in and cannot see your secrets. There is also a read-only demo login for showing the panel to somebody. ### Does updating SixPanel touch my data or my code? No. Updating SixPanel replaces SixPanel's own code. Your settings, your data — database, uploads, certificates, local backups — and your application code are left exactly as they are. One thing worth knowing, because we found it the hard way: an update that lands files on disk is not the same as an update that takes effect. Every path that writes state now has to declare whether an update delivers it, a check runs on every build, and a freshly installed server and an updated one were proved to produce 1,447 of 1,447 identical configuration lines. ### How do I know the backups actually work? The panel proves it, and the reason it proves it is that this went wrong once. Backups ran, reported success and contained no database at all for four days, because the tool's exclude rule cancelled the dump files the same run had named. That is fixed, and it is now a gate rather than a setting: a restore is loaded into a throwaway database, counted and deleted — 192 tables and 66,701 orders, from a real scheduled backup. Two honest caveats remain: restoring onto a different server needs one manual step afterwards, and restore currently targets the default project. ### Is SixPanel open source? No. The panel's backend ships as V8 bytecode with the readable sources removed, and the browser files are minified. We call that deterrence, not security — anyone determined can still work out what the code does. Your 6amMart code and your data are yours and nothing here obscures them. If readable source on your own server is a requirement, a general-purpose open panel is the better choice for you. ### What is the difference between SixPanel and SixPanel Docker? The same panel, the same commands and the same manual — only the way the software underneath is installed differs. SixPanel installs nginx, PHP, MariaDB and Redis directly from the release's own distribution archive and lets systemd supervise them. SixPanel Docker runs the same stack as containers, pinned at PHP 8.4 and MariaDB 10.11 whatever the host runs. The native one is faster on every endpoint measured and isolates projects at the kernel rather than inside PHP, so it is the recommendation, and it is where new development goes. Pick the container one if you want the stack isolated in containers, or if you need MariaDB 10.11 on a release whose archive does not carry it. ### Your page lists defects in your own product. Why? Because it is the only honest evidence that the testing is real. Two independent end-to-end rounds returned a verdict of “not ready” before this was called finished, and they found backups that reported success with no database in them, a storefront listening outside every protection, and deploys that updated the code while the site kept serving the old version. All are fixed, each with the check that now keeps them fixed. If a panel's marketing page carries no list like this, it does not mean there was nothing to find.