Running inside SixPanel

If you run 6amMart through SixPanel, you already have SixPreflight. It is mounted inside your shop as the panel's own Shop check-up page, and it deliberately tells you something different there, because SixPanel already owns half the server.

Both SixPanel runtimes were scanned before this was written: 97 out of 100, grade A on SixPanel, 96, grade A on SixPanel Docker, with no red rows on either.

SixPanel is two runtimes, and neither one is assumed

This matters here because SixPreflight has to work out what it is standing on before it can report anything about it.

SixPreflight runs the same checks on both, and enters the same SixPanel mode on both. Where a finding differs between them, it is because the server genuinely differs — not because the tool assumed one shape.

An earlier version of this page gave a narrower reason for the container runtime: that Ubuntu 26.04 and Debian 13 do not carry MariaDB 10.11, so a container was the only way to get it. The first half is still true. The conclusion is not — the recommended runtime takes MariaDB 11.8 from the archive on those releases, and 11.8 against 10.11 measured a wash on this platform's own queries. The database version is no longer the reason to pick containers.

The two runtimes also accept different hosts, which is worth knowing before you build a server. The recommended runtime supports Ubuntu 26.04, Ubuntu 24.04 and Debian 13, and refuses Debian 12 by name. SixPanel Docker still accepts Debian 12 — but Debian 12's own security support ended on 11 July 2026, and the kernel, glibc, Docker and OpenSSH come from the host's archive whatever runs in a container. It installs; do not start a new shop on it.

What it scores on a SixPanel server

Both runtimes were scanned on real servers rather than reasoned about:

Two things are worth saying about those numbers rather than just printing them.

We are scoring our own work here. That is worth your scepticism. What makes the figures checkable is that the same free tool is the one you run yourself, on your own server, and it reports the same rows we read.

The gap between 97 and 96 is not a ranking. As Reading the report explains, a score this close says nothing useful about which runtime is better. The zero in the last column is the part that carries information — no red rows means nothing on either machine trips the cap, so both numbers are describing the whole check set rather than one broken row.

Two customers, two different pages

SixPreflight is built for two different situations, and it needs to say different things in each one.

On cPanel, aaPanel, CloudPanel or a bare VPS — its main market — you own everything on the server, so you get every paste-ready block and every command exactly as described in the server and configuration guide.

On a SixPanel server, the panel owns the web server, PHP, the database configuration, cron, the queue worker and the certificate, and it rewrites those files from its own templates on every deploy. A value pasted in by hand there is not just unhelpful — it is actively wrong, because the next deploy silently throws it away.

In that mode, SixPreflight:

• Drops the paste blocks, the raw nginx and Apache config, the restart commands, and the setup script — none of them apply here
• Points at the SixPanel page that owns each setting instead
• Keeps everything about the application — .env, business settings, missing or wrong keys, a wrong APP_URL, broken storage, errors in the log — because that half is still yours to fix
• Says which mode it is in, in one line at the top of the page, so it is never a mystery which world you are in

One honest note either way: on a SixPanel box, the settings that belong to your shop — payments, mail, SMS, Firebase, maps, timezone, currency — are held out of the server score and listed separately, because they are the shop owner's job, not the server's. The plain verdict at the top of the page still speaks for the whole business, not just the half SixPreflight is scoring.

How it knows which mode it is in

Two signals decide it, checked in order:

1. An environment variable set by whoever serves the mount point. This is the primary signal, because it is attached by the server itself — every request to the path carries it, regardless of how the request was made. Opening the page in a new tab, or someone else pasting the link, does not change the answer.
2. A setting in the tool's own config file, for a mount that cannot set an environment variable, and as the way to force either mode by hand if you ever need to.

Neither signal asks which runtime it is. Both runtimes serve the mount point, so both set the variable, and the mode is the same either way.

A request header is deliberately not used as the primary signal, even though it looks like the obvious option. A header is set by whoever makes the request rather than by the server, so it would not survive being opened in a new tab or shared as a link — the tool would flip back to standalone advice on the exact same server, in the same session, which is more confusing than useful.

The panel is doing its own supervision underneath

On a SixPanel box, the queue worker, the scheduler and the websocket server behind live tracking already run as supervised services of their own — each with a restart policy, a memory ceiling, ordering behind the database, and rotated logs. On the recommended runtime those are systemd units; on SixPanel Docker they are containers under Compose.

Either way, installing systemd units or another supervisor on top would give one process two owners fighting over it, which is worse than doing nothing. So SixPreflight does not offer to.

It also cannot inspect those services directly, and the reason differs by runtime:

• On SixPanel, the tool runs as the project's own unix account inside a restricted process view. It cannot see its neighbours' processes — which is the isolation working, not a fault.
• On SixPanel Docker, it is in a different container from the services it would need to look at.

So the panel writes what it knows into a shared file once a minute instead: which services exist, their health, and the result of a real websocket handshake against the live-tracking server.

If that file is missing or stale, the relevant rows read "no answer" rather than guessing at a confident wrong one, and point you at the panel's own Services page.

Where to go next

• Reading the report — why a score of 96 and a score of 88 can describe near-identical servers
• Security and privacy — how the tool protects itself either way
• The server and configuration guide — the full picture for a server you manage yourself