Which operating system
Both SixPanel runtimes now run on the newest releases, so the choice is no longer a trade against a database version. What is left is how long each release keeps receiving security updates — not speed, which we measured on six separate axes and will not claim.
The short answer
Take Ubuntu 26.04 LTS, on either runtime, unless you have a specific reason not to. The reason is a date.
| Release | Security updates until | Native SixPanel | SixPanel Docker |
|---|---|---|---|
| Ubuntu 26.04 LTS — recommended | April 2031 | yes | yes |
| Debian 13 (trixie) | August 2028 | yes | yes |
| Ubuntu 24.04 LTS | May 2029 | yes | yes |
| Debian 12 (bookworm) | ended July 2026 | refused by name | installs, but do not start here |
SixPreflight follows the native runtime's list.
None of that is a speed recommendation. Across the systems we measured, the differences were smaller than one machine's disagreement with itself.
Where every component comes from
The two runtimes answer that differently, and it is the only real difference between them.
A native install takes every component from the release's own archive — the web server, PHP, the database, the cache. Nothing is compiled and no third-party repository sits in the serving path, so a security fix arrives the way the rest of the operating system's fixes arrive. Which versions you get therefore follows the release:
| Release | PHP | MariaDB | nginx | Redis |
|---|---|---|---|---|
| Ubuntu 26.04 LTS | 8.5 | 11.8 | 1.28 | 8.0 |
| Debian 13 | 8.4 | 11.8 | 1.26 | 8.0 |
| Ubuntu 24.04 LTS | 8.3 | 10.11 | 1.24 | 7.0 |
Node.js is the one exception — one declared version, 26.8.1, the same on all three.
SixPanel Docker takes them from container images instead, so that table does not apply to it: it runs PHP 8.4 and MariaDB 10.11 whichever host you put it on. The host still supplies the kernel, glibc, Docker itself and OpenSSH, which is why the host's own support date matters there too.
That is the whole of the mechanism, and on both runtimes it is why the only axis left is the support date.
What this page used to say
Until recently this page recommended Ubuntu 24.04 LTS for the native runtime and Ubuntu 26.04 LTS for the container runtime, and gave one reason for the split: MariaDB's own installer script refuses to put version 10.11 on Ubuntu 26.04 or Debian 13, a native install took its database from that script, and 10.11 was the pinned version.
Both halves of that have gone. The native runtime now takes MariaDB from the archive — 11.8 on Ubuntu 26.04 and Debian 13, 10.11 on Ubuntu 24.04 — and does not use mariadb.org's script at all, so the refusal never reaches it. And the pin itself was retired by measurement: 11.8 against 10.11, on identical servers with the same shop's data, is a wash. The database page shows that measurement.
What has not changed is the container runtime. It carries mariadb:10.11 as an image, so the host's package list was never consulted there and still is not — which is why it can offer 10.11 on any host it supports. The part that is now false is only the conclusion drawn from it, that the native runtime therefore has to stay on 24.04.
So both runtimes recommend the same release, and the recommendation is about support runway rather than database versions.
Why the PHP version does not decide it
The three releases ship three different PHP versions, and none of that changes the answer.
8.5 is not a problem. It was previously ruled out here, on the grounds that the spreadsheet library behind Bulk Import, Bulk Export and every Excel report declares it needs PHP below 8.5. That bound is a declaration in the library's own metadata, not a measurement, and nothing enforces it — the platform check that would is switched off. So the code was run on PHP 8.5.4 instead of read: the xlsx round-trip came back byte-identical, and the framework boots. That was checked on both the plain CodeCanyon tree and the optimised fork. Ubuntu 26.04's archive PHP is 8.5.4, and SixPanel installs it.
8.3 against 8.4 is nothing on speed, and that was measured rather than assumed. The aaPanel box in the three-panel comparison had both versions installed, so it could answer cleanly — the 8.3 pool was first given the entire 8.4 tuning, because it had been left on defaults, and every setting was verified from the running process rather than from a file. Geometric mean of 8.3 against 8.4: 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.
Why speed is not the reason
We installed the same 6amMart, on the same hardware, with the same real dataset, on three operating systems, and measured them. Under 20 concurrent users hitting the search endpoint for 30 seconds, on identical 4 GB / 2-core servers:
| Operating system | Requests in 30 s | Per second |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
The spread across all three is 3.5 %. That looks like a result until you notice the next number: Ubuntu 26.04 disagreed with itself by 8.6 % across two runs of its own identical configuration — 49.6 req/s once, 53.9 the next time.
A difference between machines that is smaller than one machine's disagreement with itself is not a finding. It is noise, and it ranks nothing. So the correct reading of that whole table is "about 53 requests per second on 2 cores", and nothing more.
That table is one axis of six. The operating system, the PHP version, the database version, the web server, the cache and the kernel were each swapped and measured, and only one of them decided anything — the cache, and on compatibility rather than speed. Nothing else produced a difference worth reporting.
Warning
This is why we make no OS speed claim, and why you should be sceptical of anyone who does from numbers this size. If a comparison does not tell you its run-to-run variance, it has not told you whether its difference is real.
One thing we measured and have now withdrawn
This section used to record an observation we declined to claim: Ubuntu 24.04 was consistently about 10 ms slower per request on idle serial latency — every run, on two different endpoints, with non-overlapping ranges. The consistency was the reason it seemed worth mentioning at all.
It is withdrawn, because we later measured what consistency on its own is worth. Two byte-identical machines — same release, same configuration, same data — came out 11.6 % apart on 20 of 20 rows. Not the processor, not contention from other tenants, not memory fragmentation; nothing we could attribute. A one-directional difference across every row is something identical servers produce, so it is not evidence that the software differed.
With one machine per operating system, nothing separated "this kernel is slower" from "this host was slower", and the identical-box result says the second explanation is entirely capable of doing all the work. Recorded here as retired rather than deleted, because the earlier version of this page mentioned it.
We also cannot use the storage-speed figures from those runs at all. They reflect which physical host each virtual machine landed on, not the software.
So what actually decides it
One thing: how long you keep getting security updates.
Ubuntu 26.04 LTS is patched to April 2031, which is the longest window of the supported set and the reason it is the recommendation for both runtimes. Debian 13 runs to August 2028 and Ubuntu 24.04 LTS to May 2029 — both are well supported, and neither is a short clock. If you have an existing 24.04 box, there is no measured reason to move it.
Debian 12 is a different matter, and the two runtimes treat it differently. Its normal security support ended in July 2026, and the only PHP its archive carries — 8.2 — reaches upstream end-of-life on 31 December 2026. The native installer refuses it by name and points at Debian 13, rather than building a server that is already out of support. The container runtime still installs on it, and you should still not start a new shop there: a container brings its own PHP and database, but the kernel, glibc, Docker itself and OpenSSH all come from that host archive, and that is the part no longer getting fixes.
What is not supported
Anything that is not Ubuntu or Debian. CentOS, Rocky, Alma, Arch, Windows: not tested, not supported. This is a deliberate narrowness — supporting two families well is what lets everything else be configured correctly by default. Debian 12 sits just outside the line for the native runtime specifically, as above.
Sizing, honestly
Every measurement above is from a 4 GB, 2-core server. We have not measured 8 GB or larger machines, so nothing here predicts them.
That 4 GB box ran a real shop's data — a 410 MB dump, 515 MB once loaded, roughly 66,700 orders — with 99.99 % of database reads answered from memory rather than disk. It is a genuinely workable size to start on. It is also the size at which a readiness check has something to say, which is what SixPreflight is for.
Related
Which database engine is the other choice that matters, and there the hard answer is about correctness rather than speed. SixPanel vs SixPanel Docker vs aaPanel is where the two runtimes were measured against each other and against a tuned rival. See also SixPanel vs a plain server.