The server panel built for one job — running 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.
- Faster than a fully tuned aaPanel — same hardware, same shop, measured
1.76×
Faster than a fully tuned aaPanel — same hardware, same shop, measured
- Runs a whole shop
2 cores / 4 GB
Runs a whole shop
- Published on CodeCanyon, first setup done for you
Free
Published on CodeCanyon, first setup done for you
- Panel interface languages
8
Panel interface languages
Reading this with an AI assistant?
Getting SixPanel
SixPanel installs from one command. Nothing to sign up for, no key to enter, no code to paste — it is the same command for everybody. It is free.
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashWhat protects a command running as root is not the address — it is the release signature. The installer carries our signing key and refuses any file that does not match, automatically. The install page explains it.
Try it before you download
Read-only login
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.
Get SixPanel
Free- Updates included — every release goes to CodeCanyon at no further cost, and the panel can update itself in place. No licence server, no key to renew.
- First setup is free — send your purchase code and server details on WhatsApp or email.
Nothing to activate — runs on your own server, no phone-home, and it keeps working if this site is down.
What it is, and what it replaces
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
Every row is the same job, done the two ways. Left is what running 6amMart asks of you without SixPanel; right is what it becomes with it.
Getting the server running
Without it
Building a server by hand — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, a process supervisor — and keeping all of it alive
With SixPanel
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.
Sizing the database and PHP
Without it
Guessing the database and PHP settings, or paying someone to tune them
With SixPanel
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.
Shipping a change to the shop
Without it
Paying a developer for every deployment
With SixPanel
Push to git, the shop updates. Deploy history and rollback, with the last 30 deploys kept.
Knowing the backup works
Without it
Hoping the backup works
With SixPanel
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.
When the shop goes down
Without it
Reading a stack trace to find out why the shop is down
With SixPanel
A Health page of about twenty checks, each with one plain sentence about the consequence and exactly one fix button.
What it costs
Without it
Building and maintaining that stack yourself is the cost, whether you pay it in hours or in invoices.
With SixPanel
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.
Two ways to run it
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.
- Recommended
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.
Install command
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- 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.
Install command
curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash- 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.
Measured, not claimed
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.
1.76×
faster than a fully tuned aaPanel
1.82× when four requests arrive at once. Measured across the endpoints that reach PHP on both servers.
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.
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/categoriesForced to PHP on all three — the cleanest like-for-like row | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allThe store listing every customer sees first | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchThe heaviest read in the application | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularJoins across the whole catalogue | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listSigned in and uncacheable — the slowest call on every box | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)SixPanel redirects in 430 bytes; aaPanel renders 352 KBDifferent work | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeSixPanel renders the page; aaPanel's is a proxy-cache hitDifferent work | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeTime to the connection being accepted | 2.35.8 | 4.211.6 | 2.66.3 | —— |
Green is the fastest configuration in that row.
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.99× | 1.91× |
| After switching off aaPanel's directory restriction | 1.32× | 1.29× |
| After also correcting its JIT compiler mode | ≈1.25× | ≈1.21× |
The gap, attributed
- A PHP directory restriction60%
- The wrong JIT compiler mode8%
- PHP version0%
- Still unexplained32%
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≈60% of the gap
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 | Change |
|---|---|---|---|
/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 assetControl — never reaches PHP | 0.4 | 0.4 | 0% |
aaPanel runs the wrong JIT compiler mode for this application≈8% of the gap
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 assumed0% of the gap
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 causeSix candidates
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 itApplication code
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.
Everything we publish
Every report, in one place
No number on this page stands alone — each comes from a published report with its method, its caveats, and the results that did not flatter us. Read them before you buy; that is what they are for.
SixPanel vs aaPanel
1.76× faster at one request, 1.82× at four arriving together — against a fully tuned aaPanel, with the cause broken down and 32% of the gap honestly labelled unexplained.
SixPanel vs SixPanel Docker vs aaPanel
Three panels on identical hardware and a byte-identical shop — the full method behind the headline numbers.
SixPanel vs CloudPanel
A fair one: CloudPanel is good general-purpose software. The question is which problem you are solving.
SixPanel vs a plain server
What the panel adds over the hand-built server most owners start with — and what that costs over a year.
Which operating system
Ubuntu 26.04 vs Ubuntu 24.04 vs Debian 13, measured: speed is a tie, support windows are not.
Which database engine
Five engines against a real shop. MariaDB 11.8 and 10.11 are a wash on the whole application; both MySQLs cannot run it unmodified.
Optimised 6amMart — the measured results
The 22× featured strip, the 297-page admin sweep, a 17.5-second report brought to 0.7 — with the two pages left slow on purpose, published beside the wins.
The scale test
66,701 real orders, 113,231 order lines — the dataset where the silent defects surfaced.
Defects fixed
The ones that cost money without ever showing an error — coupons, clocks, stock, double payments.
What is still open
The page that makes the other four worth reading: what we have not solved, stated plainly.
The changelog
Every release, including the mistakes and what they taught us.
What you actually get
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.
- Read-verified, not run: 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.
Why it matters: the first day is where most shops lose a week — this one ends with a working page.
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.
Why it matters: HTTPS failures are the classic silent killer — a certificate that expires on a Saturday takes the shop with it.
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.
Why it matters: the riskiest minutes of running a shop are the ones right after "deploy" — this makes them boring.
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.
- Read-verified, not run: 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.
Why it matters: an unopened backup is a hope, not a backup. The weekly restore test is the difference.
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.
Why it matters: the panel you actually open every day should answer "is everything fine?" in one glance, not one hour.
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.
- Read-verified, not run: 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.
Why it matters: most panel break-ins are not clever — they are a guessed password on a visible login page. This one is not visible.
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.
Why it matters: an agency’s second shop should not be able to read the first one’s data even in theory — here that is enforced by the kernel, and we attacked it to check.
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.
Why it matters: speed is the one thing a customer feels on every single visit — and the reason these numbers are published with their method.
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.
Why it matters: tools you need rarely should cost nothing while idle — these start on demand and get out of the way.
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.
Why it matters: the server can be perfect while a wrong setting inside the shop quietly costs orders — a second pair of eyes reads those.
What runs by itself
The automation, mapped
"Automated" is an easy word to print. Here is every job the panel runs without you — what triggers each one, and what you would otherwise be doing by hand at midnight.
- Once, at the start
The whole server, from one command
One paste on a fresh Ubuntu server installs the web server, the database, PHP, the cache, the queue worker, the scheduler, the websocket server and the panel itself — each sized to the machine it lands on. You type a domain; everything else is placed, configured and started.
- Before every expiry
HTTPS that renews itself
Certificates issue automatically — DNS-based when Cloudflare manages the domain, so they work before the internet can even reach the box — and every renewal reloads the web server through a per-certificate hook, so one broken certificate can never freeze the others.
- On your schedule
Backups that actually run
Incremental backups on the schedule you set, to the same server, S3, SFTP or Google Drive, with retention applied after every run. Every project’s database, uploaded files and settings — the code comes back from git.
- Every week
A restore test, not a success message
Once a week the panel restores the newest backup into a throwaway database and counts the rows. A backup that cannot actually be opened turns the Health page red — because a success message is not evidence.
- Every few minutes
Self-healing for the quiet failures
The watchdog restarts a service that is running but broken — the case an ordinary supervisor misses entirely, because nothing has crashed. A restart it performs shows up in the activity log with its reason.
- On install and update
Tuning sized to the machine
The database buffer pool, cache memory, temporary-table sizes and PHP workers are computed from the machine’s real memory and cores — one sizing ladder, measured across 36 server shapes, applied identically by the installer and the panel.
- Every night
Database housekeeping
A nightly sweep clears the expired rows the application itself never deletes, and on Sundays the tables are optimised — only when disk headroom allows it, and with every result inspected rather than assumed.
- On every deploy
Measured indexes, kept in place
A pack of database indexes — each one measured on a real 66,701-order shop before it was admitted — is checked and re-applied after every code change. Checked by what each index covers, not by its name, so a renamed index cannot fool it.
- On every git push
Push-to-deploy, end to end
Push to your repository and the shop updates itself: pull, dependencies, database migrations, the config cache rebuilt only where that is measured safe for your exact code, PHP reloaded without dropping a request. A rollback button holds the previous release.
- Continuously
Health checks that name the fix
Thirty-plus checks run on their own schedules — services, disk, certificates, DNS, Cloudflare, the panel’s own files against the release that shipped them. A failing row names the exact fix, not just the problem.
- When something needs you
Email that respects your inbox
At most one email per problem every six hours, with a coloured verdict readable from the inbox preview — and a green "resolved" when the problem clears, so silence never has to be interpreted.
- When you press the button
One-button, signature-verified updates
One button fetches the release, verifies its signature against the key pinned on your server — a replaced download host cannot re-key your machine — applies it, and restarts services in a measured order that keeps the shop serving.
The pattern behind all of it: the panel does the work, writes down what it did, and checks its own result — and anything it cannot verify, it reports instead of claiming.
Under the hood
Advanced engineering, running by itself
None of this is a checkbox on a feature list. Each one is real machinery with measured behaviour, hard safety rules, and a report you can read.
Self-healing supervisor
A 60-second loop repairs what actually breaks live shops: a stuck queue, an expired certificate, maintenance mode left on. Bounded by hard rules — it never starts what you stopped, and never acts while a deploy or backup is running.
Incremental, encrypted backups
Built on restic: every run stores only what is new or changed since the last one, deduplicated and encrypted — daily backups stay fast and small while every snapshot restores in full. Targets: local disk, S3, SFTP, Google Drive.
Backups proven, not assumed
A green backup job is not evidence. A scheduled verify opens the newest snapshot and checks your database dump is actually inside — the honest answer to “can I restore?” comes from the artifact, not the exit code.
Tuned to your server, automatically
One measured sizing ladder computes the database buffer pool, Redis memory and PHP worker counts from your box’s RAM and CPU — at install, and again when you resize. Installer and panel share the single definition, held together by a build gate.
A micro-cache proven safe
Hot API endpoints answer from nginx’s cache — 16.9 ms down to 0.6 ms, measured — but only endpoints proven caller-independent get in: a static gate reads the app’s handlers and a live three-arm probe confirms no customer can ever see another’s data.
Every project fully isolated
Each shop gets its own unix user, its own PHP-FPM pool and its own password-protected Redis instance; its workers run in a systemd sandbox with a read-only system and no privilege escalation. One compromised project cannot read another.
Cryptographically signed updates
Every release ships an ed25519-signed manifest with an expiry date. The panel refuses anything unsigned, stale or signed by the wrong key — and a rotated key must prove itself against the release before it is ever trusted.
It reads your app before it acts
The panel asserts nothing blindly. Config caching is decided by reading your 6amMart’s own code, so a build that reads settings at runtime is never silently broken. Untouched CodeCanyon code and the optimised build both get the right answer.
Auto-healing, incremental backups, signed updates — you configure none of it. It is simply how the panel is built.
Why it feels easy
Easy is a design decision, not a coat of paint
None of this is a simplified mode hiding the real controls. It is the real controls, arranged so the next step is always obvious.
One paste, no prerequisites
No Docker to learn, no compose files, no SSH folklore. The stack is Ubuntu’s own packages supervised by systemd, and one command lays all of it down.
A wizard that suggests its own answers
Six steps — basics, password, domain, HTTPS, application, backups. Each step proposes the sensible answer; most of setup is confirming, not deciding.
Type one domain, get the whole plan
From a single domain the panel plans the dashboard, storefront and websocket hosts, the DNS records to create, and which of them Cloudflare should proxy. Names that would quietly break HTTPS are refused with the spelling that works.
Problems arrive with their fix attached
No bare "failed". A red row tells you the exact setting, file or button that resolves it — the difference between a to-do item and a mystery.
Every action is a job you can watch
Installs, deploys, backups and fixes run as jobs with live logs. Buttons show a spinner while they work, and a job refuses to report success unless its own re-check passes.
The manual lives inside the panel
Every Help link lands on the page about the thing you are looking at. The same manual ships in the download and is published on this site.
A command line for the bad day
A sixpanel command on the server mirrors the panel — with a man page and shell completion — for the day the browser is not an option.
It speaks your language
Eight languages. Arrive from this site and the panel opens in the language you were reading; follow a link back and the site does the same.
The three things nobody else does
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
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.
Exactly what we have on the two competitors, stated precisely
The table has 14 rows and two competitor columns, so 28 competitor cells. Four of those 28 say something other than “we have not tested this”, and here is each one:
- One cell records something we watched a competitor's product do. aaPanel silently reverts the document root whenever any site setting is saved — recorded on a live install. That is the Document root row, aaPanel column.
- Two cells rest on a third party's behavior that we verified, not on testing the panels. Neither Ubuntu 26.04's nor Debian 13's archive carries MariaDB 10.11, and both panels install the database from the host's packages — so on those releases they cannot supply that version. SixPanel's native runtime takes 11.8 from the same archive instead, and SixPanel Docker carries 10.11 in its image. That is the MariaDB 10.11 row, both competitor columns.
- One cell reports our own measurement of a competitor. aaPanel was installed on identical hardware with the same shop's data, tuned by us first, and measured — that is the Speed row, aaPanel column, and the whole method is above. CloudPanel was not measured, so its cell says so.
- The remaining 24 competitor cells all say “not tested by us”. That is the literal wording, in every one of them — counted, not assumed.
We make no claim about how old either competitor is. No source in this set establishes either product's age, so no such claim appears. What the Track record row can honestly say is only what we know about our own age.
We have now benchmarked SixPanel against aaPanel — identical hardware, the same shop's data, and aaPanel tuned before the numbers were taken. The method and every figure are above. CloudPanel was not measured at all, and no speed claim about it appears anywhere on this page.
| 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 |
There is no price row because there is no price. SixPanel is free, published on CodeCanyon, and the install command is the same public one for everybody — no key to enter, no code to paste, nothing to sign up for. The first installation and setup is free too. Updates arrive through CodeCanyon, and the panel can also update itself in place.
When aaPanel or CloudPanel is the better choice
Five real cases. If any of them is you, buy the general panel and do not buy this:
- 1You want more than one website on that server. SixPanel takes the whole machine and refuses to share it.
- 2You need mail, DNS or FTP hosting on the same box. SixPanel does not do those at all.
- 3You need several staff accounts with different permissions. SixPanel has one admin account and no roles.
- 4You are running something other than 6amMart. Every advantage on this page comes from knowing one application well.
- 5A long production track record is your first criterion. SixPanel is new. That is a fair reason to wait.
And one for doing it by hand: if you have a sysadmin, a hand-built server is not worse. A competent engineer can tune MariaDB, write cache rules and script backups. What SixPanel removes is the need to have that person, and the need to remember to re-check any of it.
Operating system
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.
| Choice | SixPanel / SixPanel Docker | SixPreflight |
|---|---|---|
| Recommended | Ubuntu 26.04 LTS, both runtimes | Ubuntu 26.04 LTS |
| Also supported | Both runtimes: Ubuntu 24.04 LTS and Debian 13. The Docker runtime also installs on Debian 12, which the native runtime refuses by name | Ubuntu 24.04 LTS, Debian 13 |
| Why | Speed is tied across all three, so the deciding input is support runway: 26.04 is patched until April 2031. The native runtime takes PHP and MariaDB from whichever release you pick. | Same reason: the database comes from the operating system, every supported release carries a working version, and the runway is what is left to choose on. |
Supported is not the same as measured. Three releases are supported by the native runtime, and all three were measured — Ubuntu 24.04, Ubuntu 26.04 and Debian 13. Debian 12 is refused by name: its free security support ended in July 2026. The container runtime still installs on it, and you should still not start a new shop there, because the kernel, glibc, Docker and OpenSSH come from the host's archive no matter what runs inside a container.
Why every tool now points the same way
An earlier database-engine round put MariaDB 10.11 first, and for a while that split the recommendation, because only Ubuntu 24.04 carried it. Re-measured on identical boxes with the same 66,701-order shop, that split has gone.
MariaDB 11.8 against 10.11 on the whole application is a wash. The rows that suggested otherwise were discarded, because the harness was timing an encrypted handshake rather than the database.
The one place 11.8 looked slower does no work at all.
It was SELECT 1 — a statement that does no work, reading 12 ms on one arm against 29 ms and 37 ms on the other two. A floor that moves three times over is not query execution: MariaDB 11.8 negotiates TLS on the unix socket and 10.11 does not, so the probe was timing a handshake. Measured directly, 24 ms per client call on 11.8 against 6 ms with TLS off and 10 ms on 10.11. A shop never pays it — mysqlnd does not negotiate TLS on a socket, 0.12 to 0.21 ms per connect.
The old "11.x is 2.7× slower" figure was never about 11.8.
It came from one report query on MariaDB 11.0's cost model, and it is withdrawn as a whole-application claim. So nothing now argues for pinning an older release: the native runtime takes 11.8 from Ubuntu 26.04's and Debian 13's own archives, and 10.11 from Ubuntu 24.04's.
One answer, and it is not a speed answer. Take the release that keeps getting patched the longest.
How it was measured
- Measured on 15 August 2026, on the stack build current on that date. SixPanel has shipped since, and nothing in this section has been re-run on the current release. The date is what pins the measurement.
- Three servers from the same provider, ordered together, identical except the operating system — which is every release the native runtime supports.
- Same processor on all three: 2 × AMD EPYC 7713, 2 cores. RAM 3,915 / 3,910 / 3,921 MB. Disk 79 GB each.
- The software was byte-identical across all three — MariaDB 10.11, the same PHP build, the same web server. This round was run on the container runtime, which is what made that possible: it holds the stack still so the operating system is the only thing changing.
- Real data, not a fixture. A real production shop's database: a 410 MB dump restoring to 515 MB, 66,701 orders, plus 894 MB of real uploads.
- A fresh SixPanel install on each box, through the normal customer path. No hand tuning — autotune picked every value, and it picked the same values on all three.
- Warm, then measured. Warm-up samples discarded; the second run is the one reported.
- Percentiles, not averages.
Requests per second — the search endpoint, 20 people at once, 30 seconds
This is the number to trust.
| Operating system | Requests completed | Requests per second |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
Spread between the three: 3.5 %. The Ubuntu 26.04 box disagreed with itself by 8.6 % across two runs of its own identical configuration — 49.6, then 53.9.
Arithmetic note, because a page that makes a virtue of catching impossible numbers cannot print percentages a reader cannot reach from the counts beside them. The internal report prints the spread as 3.7 % and the self-variation as 8.7 %. Both are rounded up, so this page prints the truncated recomputation instead: (1,616 − 1,561) ÷ 1,561 = 3.5234 % → 3.5 %, and (53.9 − 49.6) ÷ 49.6 = 8.6694 % → 8.6 %. The finding is unchanged — the spread between boxes is still smaller than one box's disagreement with itself. The per-second column above is the source's own 1-decimal rounding: 1,616 ÷ 30 = 53.8666 and 1,595 ÷ 30 = 53.1666 truncate to 53.8 and 53.1, and only 52.0 is already truncated. The column is left as the source prints it so the two files can be laid side by side; the percentages are the page's own, and they are the numbers that get quoted.
Read the whole block as “about 53 requests per second on 2 cores, on the search endpoint, at 20 concurrent users, over 30 seconds” — and nothing more. Every one of those qualifiers travels with the figure wherever it is repeated on this page.
Idle latency — recorded, and deliberately not printed
Serial latency was measured on every arm: storefront home, admin login and the API endpoints, one request at a time on an idle box.
Those per-cell numbers are not on this page, and this is the reason. The internal report forbids any “X % faster” figure taken from those tables. A three-column table of millisecond values is that figure with one subtraction: any reader with a calculator, and every AI summarizer without one, will produce the comparison the report rules out. Printing the table and adding “but do not compare these” does not work, because a quotation keeps the numbers and drops the caveat.
- The three boxes tied on the number that matters, and one box disagreed with itself by more than the three disagreed with each other.
- A small, consistent difference did show up on one arm's idle serial latency. It is recorded in the internal report and deliberately not claimed, for three reasons stated there: it is a roughly fixed cost rather than a proportional one, which is the signature of a wait rather than of work; it disappears completely under load, which is exactly where it would matter; and with one machine per operating system, the kernel version and that particular physical host cannot be separated.
- Two arms' under-load percentile rows were thrown out entirely.
Rows were thrown out, and it matters that they were
The Ubuntu 26.04 arm's under-load percentiles are arithmetically impossible. Twenty workers for 30 seconds is 600 worker-seconds, so 1,616 completed requests have an arithmetic mean of 371 ms. That arm reported both its p50 and its p99 below that mean — a p99 that is faster than the average request. Both of its runs show it, so it is systematic to that machine, not a stray sample.
Taken at face value those rows would make that machine look dramatically better under load. It is not — its completed-request count is within 3.5 % of the others. The two percentile values themselves are not printed on this page: the internal report rules out Ubuntu 26.04's under-load latency figures as a class. The arithmetic above is enough to show why they were discarded, and the discarding is the point.
The test harness now carries a cross-check based on Little's Law, so a spoiled sample announces itself instead of becoming a headline.
The database, on the real 515 MB dataset
Read the caveat before the numbers. Every cross-machine difference in this table falls inside Ubuntu 24.04's own run-to-run range of 85–125 ms on the same three queries. The columns are not a ranking; they are three samples of one number. The real finding is the last row.
| Query | Ubuntu 24.04 | Ubuntu 26.04 | Debian 13 |
|---|---|---|---|
| Count all orders | 120 ms | 96 ms | 106 ms |
| Count all order lines | 102 ms | 102 ms | 110 ms |
| Orders joined to order lines, 50 rows | 85 ms | 80 ms | 81 ms |
| Buffer-pool hit rate | 99.991 % | 99.989 % | 99.987 % |
The last row is the finding: a 515 MB database inside a 1,024 MB buffer pool means about 99.99 % of reads are answered from memory, and this workload stops reading the disk once it is warm.
How long the install took
| Operating system | Unattended install | Problems |
|---|---|---|
| Ubuntu 24.04 | 303 s | none |
| Ubuntu 26.04 | 281 s | none |
| Debian 13 | 273 s | git is missing from the minimal image, which broke the clone outright — found here, fixed here |
303 s is five minutes and three seconds, which is why this page says “about five minutes” and not “under five minutes”.
Why April 2031 decided it
With speed tied, the deciding input is how long each system keeps getting security updates. An operating system running out of support is the one event that forces a full server rebuild — and rebuilding the server is the single thing SixPanel cannot do for its owner.
| Operating system | Free security support until | Runway from August 2026 |
|---|---|---|
| Ubuntu 26.04 LTS | April 2031 | 4 years 8 months |
| Ubuntu 24.04 LTS | May 2029 | 2 years 8 months |
| Debian 13 | August 2028, then community LTS | about 1 year 10 months |
| Debian 12 — container runtime only, not recommended | ended July 2026 | past |
MariaDB 10.11 itself runs out around February 2028. On the container runtime that is an image pin and a separate decision; on the native runtime it only applies to Ubuntu 24.04, since 26.04 and Debian 13 take 11.8 from their own archives. Either way it is why the host operating system should be the one that needs replacing least often.
If your hosting company does not offer Ubuntu 26.04 yet, take Ubuntu 24.04. It is fully supported and you lose nothing you could measure.
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 the round broke, and we fixed
Three real defects surfaced only because the measurement was run on real servers with real data. These are all three that the source records — the list is complete, not a selection.
- 1The installer failed on Debian 13. The minimal image ships no git, so the clone broke outright. Fixed.
- 2The test harness was measuring nothing on the API rows. Its request headers were being split apart, so every API row printed zero samples — quietly, on all three machines. Fixed, and a run that collects no samples now says so loudly instead of printing a silent result.
- 3Two scripts disagreed about the PHP memory limit, while a comment claimed the formulas matched exactly. Corrected.
This section stays on the page. It is the evidence that the measurement was real.
What you need
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.
What a fresh install actually takes — the honest timeline
“Five minutes” is the install command, not the job. The install command is about five minutes. Getting from a rented server to a live shop is about an hour.
| Step | Time |
|---|---|
| Put your code in a private git repository (once, on your own computer) | about 20 minutes if you have never used git |
| Update the server and add three small tools | a minute or two |
| Run the install command — checks the system, installs Docker, verifies the signature, downloads and checks the files, generates passwords, picks a random panel port, sizes everything for the machine, then builds and starts | 273–303 seconds measured across three operating systems — about five minutes |
| Open the three ports in your hosting provider's dashboard | a few minutes |
| First login, and set up two-factor on your phone | a few minutes |
| Point the domain and get the free certificate | under a minute once DNS has spread — start the DNS record early |
| Install your 6amMart code from git | a few minutes |
| Total for a first server | Set aside an hour. You will probably finish sooner. |
What the installer prints at the end, and what you must save immediately: the full panel URL, the username, and the password. The password is shown once and stored only as a hash — it cannot be read back.
The single most common failure is not the install. It is the panel port not being open at the hosting provider.
Security
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.
A measured attack, bounded and re-measured
This is the security proof on this page, because it has numbers on both sides.
All of this was measured on a two-project 8 GB test box with Redis capped at 476 MB. That is a different machine from the 4 GB boxes in the operating-system round above — only 4 GB machines were measured in that round, and both statements are true. The after-fix runs were made with the listing budget forced to 64 MB, which is the setting the smallest supported box gets, not the 245 MB an 8 GB box would normally be given.
Before the fix
| Measurement | Value |
|---|---|
| Redis memory ceiling on that box | 476 MB |
| One item-search entry at the largest page size (limit=200) | 917,704 bytes |
| Copies written per entry | 2 — a live key and a full-size stale twin |
| 20 one-letter searches at that page size | +34.2 MB in 4.8 seconds — measured, so about 1.71 MB per term |
| Requests needed to fill the whole cache server | 476 ÷ 1.71 ⇒ about 278, roughly 67 seconds on one connection |
| Signed-in shopper's session | evicted — silently signed out |
Arithmetic note, because this page cannot make a virtue of catching impossible numbers above and then print a table that fails its own multiplication. The internal report states a per-term cost of 1.79 MB and a fill figure of about 279 requests. Neither follows from the other: 917,704 × 2 = 1,835,408 bytes = 1.835 MB, not 1.79 MB, and 476 ÷ 1.79 = 265.9, not 279. The row that does reconcile everything is the measured one — 20 searches cost 34.2 MB, i.e. exactly 1.71 MB each, and 476 ÷ 1.71 = 278.36, truncated down to 278; nothing here is rounded up. That also matches the stated timing: 20 requests took 4.8 s, so 278 take 66.7 s ≈ the 67 seconds the source reports. This page prints the chain a reader can check, and drops 1.79 MB and 279 rather than repeating them.
After the fix — the three floods the evidence file tabulates, including the one that stores nothing
The evidence file describes “six concurrent unauthenticated floods” above a three-row table and never reconciles the two. Whether that means six flood processes producing three tabulated results, or three of six runs reported, the source does not say — so this page says “the three the source reports” and makes no completeness claim.
| Flood | Entries stored | Listing bytes in Redis | Evictions | Session |
|---|---|---|---|---|
| 200 requests at the largest page size (limit=200) | 0 | 0 | 0 | alive |
| 500 requests at a 50-row page size | 206 | 51.5 MB | 0 | alive |
| 2,000 requests at a 50-row page size | 207 | 51.8 MB | 0 | alive |
Across those floods Redis as a whole peaked at 53.6 MB of its 476 MB. That figure is the whole instance, not the listing family: the table above caps listing bytes at 51.8 MB, so 53.6 MB cannot be the listing cache.
On the smallest supported box the listing family is capped at 64 MB of a 128 MB Redis instance. At roughly 1 KB per session that leaves room on the order of 60,000 signed-in shoppers — space that also holds everything else Redis is doing on that machine, so treat it as a headroom figure, not a seat count.
What the panel is, said plainly
Three facts the product's own documentation insists on.
- The panel is root-equivalent on the machine, by construction: it installs packages, writes system configuration and restarts services. On the Docker runtime it additionally mounts the Docker socket. Neither arrangement is containment, and neither is presented as one.
- The secret entry address is a gate. The login runs behind it, and every login runs a password and a two-factor code.
- There is exactly one admin account and there are no roles. Sharing is done with temporary logins and one read-only demo login.
How we test
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.
- Routes exercised, 283 page loads across five screen sizes in light and dark
52
Routes exercised, 283 page loads across five screen sizes in light and dark
- Interface text keys checked, in each of 7 languages
2,740
Interface text keys checked, in each of 7 languages
- Panel workflows driven end to end, on both 6amMart codebases
34
Panel workflows driven end to end, on both 6amMart codebases
- Independent rounds whose verdict was "not ready"
2
Independent rounds whose verdict was "not ready"
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 databaseFixed
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 protectionFixed
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 versionFixed
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 cacheFixed
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 roundFixed
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 unusableFixed
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 itFixed
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 trueFixed
"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 itFixed
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
Honest limits
Every one of these is true today.
- 1
It takes the whole server.
No other websites, no other control panel, nothing else on ports 80 and 443.
- 2
One admin account. No roles, no team accounts.
Temporary logins and a read-only demo login are the sharing mechanisms.
- 3
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.
- 4
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.
- 5
A code rollback does not undo database migrations.
If a migration has run, rolling the code back needs a backup restore.
- 6
The panel picks up a renewed certificate on restart.
The daily renewal reloads nginx; the panel reads its own certificate once at boot.
- 7
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.
- 8
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.
- 9
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.
- 10
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.
- 11
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.
- 12
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.
- 13
No Kubernetes.
There is no Kubernetes driver in the panel.
- 14
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.
- 15
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.
- 16
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.
SixPanel and 6amMart
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.
FAQ
Questions people actually ask
Fourteen questions, answered with the same numbers as the rest of the page.
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.
Start with the free check, then decide
SixPreflight tells you whether the server you have is ready for 6amMart, and exactly what to change. If you would rather we ran the whole thing, talk to us.
See what changed in every release