# Which operating system

> Source: https://www.allsweb.com/compare/operating-systems
> Markdown for agents: https://www.allsweb.com/compare/operating-systems.md
> Publisher: AllsWeb (www.allsweb.com)

Part of: Comparisons

SixPanel runs on the newest releases, so the choice is no longer a trade against a database version. What is left is which release the software is actually built and tested on, and how long that release keeps receiving security updates — not speed, which we measured on six separate axes and will not claim.

## The short answer

**Install Ubuntu 26.04 LTS.** Two reasons: every SixPanel release is built and tested on it, because all three of our own servers run it — and it stays patched to April 2031, over two and a half years longer than Debian 13.

Ubuntu 24.04 LTS and Debian 13 are fully supported, tested before every release, and a healthy server on either is fine to keep. 26.04 is simply the one to ask for when you are starting fresh.

| Release | Security updates until | Status | What its archive serves |
|---|---|---|---|
| **Ubuntu 26.04 LTS** — install this | April 2031 | **built and tested on it** | PHP 8.5 · MariaDB 11.8 |
| **Ubuntu 24.04 LTS** | May 2029 | supported | PHP 8.3 · MariaDB 10.11 |
| **Debian 13** (trixie) | August 2028 | supported | PHP 8.4 · MariaDB 11.8 |
| Debian 12 (bookworm) | ended July 2026 | **refused by name** | PHP 8.2 only — end of life December 2026 |

None of the three needs a third-party software source, and SixPreflight asks for the same release SixPanel does.

**This is not a speed claim.** Across everything we measured, the differences between these releases were smaller than one machine's disagreement with itself.

## Where every component comes from

SixPanel takes everything from one place, and this is where that shows.

**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.

**The retired container runtime took them from container images instead**, so the table never applied to it: it ran **PHP 8.4** and **MariaDB 10.11** whichever host it was put on, while the host still supplied the kernel, glibc, Docker itself and OpenSSH. It was retired on 29 August 2026 and no install command is offered for it, so there is nothing to choose between here any more — one runtime, and the table above is it. The paragraph stays, in the past tense, because its release notes are still published and a reader may arrive from them.

That is the whole of the mechanism, and on both runtimes it is why the only axis left is the support date.

## Which processor architecture

A second choice, and SixPanel publishes for both.

| | x86_64 (amd64) | arm64 (aarch64) |
|---|---|---|
| **SixPanel** | yes | yes |
| SixPanel Docker (retired 29 Aug 2026) | yes | never published |

The native panel ships as compiled code, which only runs on the processor type it was built for, so there is one signed release per architecture. Both are published and the install command is the same for both — an AWS Graviton (`t4g`, `c7g`, `m7g`), Ampere, Oracle ARM or Hetzner `CAX` box installs with nothing extra to ask for or paste. arm64 was verified end to end on an AWS `t4g.medium` (Graviton, Neoverse-N1): install, panel running, entry page reachable.

**Neither architecture is the faster choice**, and this is a case where the measurement refuses to rank. On boxes of the same shape — 2 cores, ~3.8 GB, Ubuntu 26.04, PHP 8.5.4, MariaDB 11.8.6, so a difference is the machine rather than the software:

| Workload, seconds for a fixed job (lower is better) | Intel | ARM |
|---|---|---|
| PHP, 40M integer operations | 0.85 | **0.61** |
| PHP, 120k sha256 | **0.12** | 0.20 |
| Node, 400M integer operations | **1.31** | 1.52 |

Three workloads and two directions: ARM leads plain PHP integer work by 28 %, loses on sha256, and Node prefers Intel. There is no single winner, and a page that picked one from these rows would be reading a preference into a wash.

The row that does not vary is the one that matters most. **Every instance type measured had the same disk** — about 125 MB/s sequential and 330 synced 4k writes per second, within 6 % across all three. That is the storage tier's own baseline, not a property of the processor, and it is the ceiling a database actually waits on. Choosing between these instance types does not move it.

So pick on price and on what your provider offers. arm64 is frequently cheaper for the same shape, which makes it a first-class option rather than a compromise — both architectures are published and neither is provisional.

:::note 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](https://www.allsweb.com/compare/database-engines) 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 the release to install is decided by test coverage and support runway, not by 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](https://www.allsweb.com/compare/sixpanel-vs-aapanel-vs-docker) 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, the longest window of the supported set — and, with every release built and tested on it, the reason it is the one to install. 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 refused by name.** 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 installer points at Debian 13 rather than building a server that is already out of support. The retired container runtime did install on it, which is the only reason Debian 12 is mentioned on this site at all — and it was never a good idea there either: 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](/sixpreflight) is for.

## Related

[Which database engine](https://www.allsweb.com/compare/database-engines) is the other choice that matters, and there the hard answer is about correctness rather than speed. [SixPanel vs SixPanel Docker vs aaPanel](https://www.allsweb.com/compare/sixpanel-vs-aapanel-vs-docker) is where both runtimes were measured against each other and against a tuned rival, before the container one was retired. See also [SixPanel vs a plain server](https://www.allsweb.com/compare/sixpanel-vs-plain-server).