Check the server before the shop opens
SixPreflight is a server-readiness checker for 6amMart. Upload one folder, open it in a browser, and up to 163 checks end in one sentence: ready to open, or not ready — and exactly what to fix first.
Always the current release, and it runs on your own server. It reads: it never reads or writes an application table, and never sends mail or SMS to anyone. Three surfaces can act outside the tool's own folder, and a fourth writes inside it — each only when you press its button. See “What it will change, if you ask it to”.
163
distinct checks in the code
10
steps, cheapest and most-likely-broken first
1
sentence at the end of it
A–F
grade, with every blocker named
Reading this with an AI assistant?
Getting SixPreflight
SixPreflight is a folder of PHP you upload. Nothing to install first, and nothing to sign up for. It is free.
Try it before you download
Demo password
Password: a3uap648vnh7yqenc9vb
No username — SixPreflight asks for the password only.
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 SixPreflight
Free- Updates included — every release goes to CodeCanyon at no further cost. 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 does
For a shop owner, not an engineer
You have bought 6amMart, you have rented a server, and somebody has installed it. The site loads. That is not the same as being ready. A shop can look completely normal in a browser while its payment gateway has no working credentials, its push notifications go nowhere, its .env file is readable by anyone on the internet, its scheduled jobs have never run once, and its database is configured to use a fraction of the memory you are paying for. None of that shows up until a real customer places a real order and something quietly goes wrong.
SixPreflight is the check you run before that happens. You upload one folder into your site, open it in a browser, set a password, and press a button. It looks at the server the way a careful engineer would — the hardware, PHP, the database settings, the web server, file permissions, what the internet can reach, and whether payments, email, SMS, maps and push notifications actually work when you call them for real.
Then it gives you one sentence — “Ready to open” or “Not ready to take orders” — a letter grade, and an ordered list of what to fix, each item with the exact line to change, the file it lives in, and what it costs your shop to leave it alone.
The scan itself only reads. Where the tool can act, it acts on a button you press, never on its own.
With it versus without it
What you know before you open
The same server on both sides. The difference is whether you find the problems, or a paying customer does.
The day you open
Without SixPreflight
The site loads in a browser, so you open. A shop can look completely normal while its payment gateway has no working credentials, its push notifications go nowhere, its .env is readable by anyone on the internet, its scheduled jobs have never run once, and its database is set to use a fraction of the memory you are paying for.
With SixPreflight
Up to 163 checks end in one sentence — ready to open, or not ready to take orders — with a letter grade and an ordered list of what to fix first.
How you find out something is wrong
Without SixPreflight
A real customer places a real order and something quietly goes wrong. That is your first signal, and it costs you the order and the customer.
With SixPreflight
You find out before you open, from a scan you run yourself — each item naming the exact line to change, the file it lives in, and what it costs your shop to leave it alone.
A credential that is present but wrong
Without SixPreflight
It looks exactly like one that works. A config file with a value in it tells you the value is there, not that it is correct.
With SixPreflight
Real calls settle it: a real Firebase token minted and posted to Google’s token endpoint, a real SMTP conversation with EHLO / STARTTLS / AUTH, and a live geocoding call to Google Maps. Present-but-wrong fails here — the only place it can be caught before a customer finds it.
What the internet can already reach
Without SixPreflight
You assume the files that should not be public are not public. Nothing on the server tells you otherwise, because nothing is making the requests.
With SixPreflight
It fetches a fixed list of known-risky addresses off your own live site — /.env, /.git/config, /artisan, the installer’s database.sql, and the tool’s own files — and reports what actually came back.
What it costs
Without SixPreflight
Finding this out from a customer is the expensive version.
With SixPreflight
Nothing. SixPreflight is free on CodeCanyon and the first setup is free. Nothing in the package checks a licence, an account or an expiry date, and nothing in it reports anything back to AllsWeb.
Run on real servers
What it scored when we pointed it at our own machines
A checker that has never published a result is an assertion. These are from the same measurement round as the SixPanel benchmark — the tool deployed to real servers running a real shop, and scored the way a browser scores it rather than from a shell.
SixPanel
97 · A
Rows needing attention: None
SixPanel Docker
96 · A
Rows needing attention: None
Read a capped score correctly
The score caps at 88 while any single row is in the red, no matter how good the rest is. That is deliberate — a shop that cannot trade should not read as a B+ — but it means a capped number tells you almost nothing about the other ninety-nine checks. Earlier in the same round one server read 88 and another 96, and the difference between their underlying scores was 0.03 across about a hundred checks. The entire visible gap was one stale background job. Always read the red rows, never the headline alone.
A defect this round found in the tool itself
SixPreflight's own scan runner had no error handling at all. On a server where the hosting company has disabled a PHP function, calling it in PHP 8 is not a suppressible warning — it is a fatal error — so a single disabled function ended the whole scan with a stack trace instead of a report. That is precisely the shared cPanel and Plesk hosting most likely to need this tool in the first place. It is fixed: a disabled function is now one row that says it could not be measured, and the scan finishes.
And one it gets wrong on a hardened server
On a server where PHP is confined by a kernel sandbox, SixPreflight cannot read the web server's configuration — and it reports one timeout setting as unset when the web server has in fact set it. Absence of evidence read as evidence of absence, which penalises a server for being hardened. It is listed here because a tool that reports its own blind spots is worth more than one that does not have any.
How it works
Stepped, not one long wait
The page itself runs no checks. It draws an empty shell, and then the browser asks the server for one step at a time.
First paint is instant
Measured on the test install: 6.8 KB in 2 ms, against 36 KB and about 1.6 s when the page did all the work before rendering. On a server that is by definition possibly misconfigured, waiting on the slowest check before showing anything is the wrong trade.
The progress bar is real
Completed steps over total steps, not an animation. When it stops, something is genuinely stuck, and the label says which check.
A hung check cannot take the page down
Every step is its own short request, so nothing runs into max_execution_time. A step that throws is reported as a finding and the scan carries on. Every finished step is written to disk as it completes, so an interrupted scan is still readable.
Two buttons
Check now
Reads local configuration and looks up the server's public IP — about a second.
Deeper check
Adds the two steps that make real outbound calls: the public-exposure tests against your own URL, and the live integration tests.
Honest detail: “Check now” is not entirely offline. The public-IP row asks an outside echo service — ifconfig.me, then api.ipify.org, then icanhazip.com, tried in order and cached between scans, deliberately three providers so one bad minute does not overwrite a known-good answer.
The three ways it runs
SixPreflight works out what it is looking at and changes what it says, because honest advice is different in each case.
On a plain server — no application installed yet
This is the mode for choosing a server or preparing a new one. Hardware, PHP, the database server, the web server, permissions and public exposure are all still checked. The .env step returns nothing, the application step returns only the profile row, and the database step reports “not checked — no application here to hold credentials” as a pass rather than letting a missing connection become the worst row on a correctly empty box.
You can still audit a bare box's database by pointing env_path at a stub .env that carries the credentials.
Inside your shop — at the 6amMart admin codebase
Upload the folder into public/, the directory your web server actually serves. The application root is found by walking up from the tool's own folder, at most five levels, to whichever directory holds artisan — so both public/preflight/ and a folder in the application root work, and an upload buried deeper than five levels silently gets standalone mode instead. The correct home is public/ — a folder in the application root is only reachable by URL when the document root is wrong, which is itself the most serious thing this tool looks for.
Here every check runs, including the ones written from the 6amMart codebase specifically: the scheduler that pays stores and riders, modules marked enabled but missing, the exact PHP extensions its vendor packages require, and the websocket layer behind live delivery tracking. On any other Laravel application everything about the server still applies exactly as written, and the 6amMart-specific checks are skipped rather than guessed at.
Embedded in SixPanel
On a SixPanel server the panel owns the web server, PHP, the database configuration, cron, the queue worker and the certificate, and rewrites those files from its own templates on every deploy — so a value pasted in by hand is silently lost at the next deploy. In that mode SixPreflight drops the paste blocks, the raw nginx and Apache blocks, the php-fpm restart lines and the “where to click in your hosting panel” paths, and points at the SixPanel page that owns each setting instead. It keeps everything about the application — .env, business settings, missing or wrong keys, a wrong APP_URL, broken storage, errors in the log — because that is the half the panel cannot put right by itself. It says which mode it is in, in one line at the top of the page, so the mode is never a mystery.
The mode is decided by an environment variable set by the server block that answers the path (SIXPANEL_EMBED=1), or by 'embedded' => true in config.php. A request header is deliberately not the primary signal: a header is written by whoever makes the request, so it would survive the panel's frame and nothing else — open the same page in a new tab and the tool would flip back to standalone advice on the same server. X-SixPanel-Embed: 1 is honored only when you switch on 'trust_embed_header', which is off by default, because ungated it would let any visitor hand themselves the managed-server view on a server that is in fact theirs to fix.
What it checks
163 distinct checks, in ten steps
163 distinct checks live in the code, run in ten steps, ordered cheapest and most-likely-broken first. The two steps that make outbound calls are marked slow and only run on a Deeper check.
| Step | What it looks at | Checks | Real examples |
|---|---|---|---|
| System & hardware | The machine you are paying for | 7 | vCPU count, RAM, swap, free disk, load average, OS release, whether any backup tool exists at all |
| PHP runtime | The language the shop runs on | 18 | PHP version band, 25 required extensions, memory_limit, effective max_execution_time, display_errors, OPcache on/off, OPcache memory and file count, hit rate |
| Application health | Laravel and 6amMart itself | 22 | .env tracked in git, pending migrations, failed jobs, queue backlog, log size, error count in the log, whether the scheduler has ever run, module list valid, trusted proxies, install settings present |
| Environment (.env) | The one file everything reads | 14 | duplicate keys (the last one wins, so your edit does nothing), invisible \r characters, an invalid or shipped APP_KEY, APP_DEBUG=true, a malformed APP_URL, keys nothing reads, keys that go null once config is cached |
| Host identity & permissions | Who owns the files | 9 | public IPv4 and IPv6, the PHP user, file ownership, the six directories that must be writable, world-writable files, a world-readable .env, anything writable and executable inside public/ |
| Web server | nginx or Apache in front | 17 | handler type, gzip, server tokens, FastCGI read timeout, Apache modules and MPM, php-fpm worker count vs memory, the upload size chain, live compression, static caching, HSTS, certificate expiry |
| Cache, queue & realtime | Background work | 11 | queue connection, whether a queue worker is actually running and supervised, session and cache drivers, Redis, Memcached, Reverb credentials and scheme, Pusher credentials |
| Database configuration | Where the money lives | 32 | InnoDB buffer pool sized against your real data and RAM, redo log, flush method, max_connections against php-fpm workers, skip_name_resolve, sql_mode, charset, PHP-vs-database clock skew, buffer-pool hit rate, temp tables on disk, database user privileges |
| Public exposureslow | What a stranger can fetch | 12 | HTTPS, .env readable over the web, .git/config readable, laravel.log served, an uploaded .php file actually executing, Debugbar or Telescope answering, installer database dumps left in place, this tool's own files served as text |
| Payments, email & SMSslow | The services that must work | 21 | a real SMTP conversation, a real Firebase token mint, a real Google Maps geocode call, payment methods usable, SMS gateway credentials, storage disk writable, maintenance mode, reCAPTCHA, timezone, currency |
The column adds to 163. Two rows carry a qualifier.
- One of the 32 database checks — db_standalone — exists only for the case where there is no application to hold credentials. It stands in for the other 31 rather than joining them.
- Two of the 21 payments/email/SMS checks are prefix bases (sms_, social_) that expand at run time into one row per active gateway or per configured social login. So that step can emit more than 21 rows on a busy shop, or fewer on a bare one.
No single run performs all 163 — and here is exactly why
An installed shop can produce at most 162 distinct rows — and no single run emits all 162
db_standalone is emitted only when there is no application, so an installed shop can never see it; that is the 163rd. The 162 is a ceiling, not a run.
A Deeper check on an installed shop emits 160
When the deeper step is going to follow, the web-server class suppresses its two config-read twins — nginx gzip and server_tokens, or Apache keepalive and server_tokens — because the live measurement answers the same question off a real response, and the two can disagree (gzip on; with a gzip_types list that omits application/json is a pass by config and a warning by measurement, about one setting). Those twins sit inside the 162; they are the reason a Deeper check lands at 160 rather than 162, not an extra pair on top of it.
A “Check now” emits 123 — it skips 39
Those 39 are the 12 public-exposure checks, the 21 payments/email/SMS checks, and the six web-server rows that can only be read off a live response — compression, static_cache, keepalive_live, server_banner, hsts and cert_expiry. The two config-read twins are present in this run, because the live measurement that would have replaced them is not coming.
Both those figures count distinct keys, and a real server lands lower still — use the lower end
Three of the 17 web-server keys belong to whichever web server you are not running (nginx contributes client_max_body_size, gzip and fastcgi_read_timeout; Apache contributes apache_modules, apache_mpm and keepalive), and the database step carries engine-conditional pairs — MySQL 8.0.30+ reports innodb_redo_log_capacity, everything else reports innodb_log_file_size, never both. Counting the web-server split alone, a Deeper check on an nginx or an Apache install emits no more than 157, and a “Check now” no more than 120; each engine-conditional database row takes it lower again.
On a plain server, 40 rows have nothing to read
The 14 .env checks, the 12 Laravel application checks, the 9 6amMart platform checks and the 5 realtime checks have nothing to read at all — 40 rows, leaving only the profile row from the application step.
So the honest form is “up to 163” — with a Deeper check on a 6amMart install running the full set available to it, which is 160 distinct keys and no more than 157 rows on a real single-web-server box.
Neither slow step is guesswork
The exposure step fetches real addresses off your real site
It fetches a fixed list of known-risky addresses off your own live site — /.env, /.git/config, /storage/logs/laravel.log, /artisan, /composer.json, /vendor/autoload.php, the installer's database.sql and public.zip, /telescope, /_debugbar/open, the store-signup route, and this tool's own files — and reports what actually came back.
The service step makes real calls
It mints a real JWT and posts it to Google's token endpoint to prove your Firebase service account works, opens a real SMTP conversation with EHLO / STARTTLS / AUTH, and makes a live geocoding call to Google Maps. A credential that is present but wrong fails here, which is the only place it can be caught before a customer finds it.
The SMTP probe stops at authentication. It sends EHLO, negotiates STARTTLS, authenticates and then QUITs — there is no MAIL FROM, no RCPT TO and no DATA in that class, so nothing is delivered to anyone.
Two more pages that are not part of the 163
Both are real product surfaces and neither contributes to the score.
Live delivery tracking — 15 checks
Its own page, covering the Reverb process, the process manager, the listening socket, firewall, proxy, certificate, credentials, app keys, app settings, channel auth, client target, config cache, queue, CDN and driver. For a 6amMart buyer this is the feature behind the live map, and it is checked separately rather than folded into the server score.
Test order alert
Sends a real push notification to a real store or rider device, through the platform's own artisan command rather than a hand-built payload. There is a “Show what would be sent” button that runs it dry, but the default button sends for real.
How it scores
One number — and it tells you what it could not measure
Every check ends as one of four things: pass, warning, problem, or not measured.
The number is a weighted average, not a count. The weight table runs from 200 down to 11, set by what it costs you when it is wrong — APP_DEBUG=true sits at 200, the OS name row sits at 12, and app_profile and public_ipv6 sit at 11. Any key not in that table falls to a default of 10, and one live scan key does exactly that: db_standalone, which is genuinely unranked and shows up in the tool's own drift report. A pass earns its full weight, a warning earns half, a problem earns nothing.
| Score | Grade | What it means |
|---|---|---|
| 90 and above | A | Production ready |
| 75–89 | B | Good. Clear the amber items and re-check |
| 55–74 | C | Workable, but leaving real performance on the table |
| 35–54 | D | Not ready. Several settings will hurt under load |
| Below 35 | F | Do not go live on this configuration |
Blockers cap the grade
Some failures are not “points off” — they mean the shop cannot trade. One blocker caps the score at 74, two at 54, three or more at 34, so a blocker forces the grade band down and the weighted average only decides where inside that band you land. With no blockers at all, a single red row still caps the score at 88 — an A is unreachable with any red on the page.
The blocker list is short and specific, and it is exactly nineteen named keys plus anything beginning sms_: .env readable over the web, logs served over the web, the site in maintenance mode, an uploaded .php file executing, new stores unable to register, no usable payment method, the database unreachable, storage misconfigured, mail failing, SMS failing, a sql_mode the platform breaks under, the wrong charset, the scheduler not running, a certificate expiring inside 14 days, and five further .env faults — a missing or shipped APP_KEY, APP_DEBUG=true, a broken database block, a broken mail block, and duplicate keys.
Note what is deliberately not a blocker: files above the document root being readable is graded as a warning, not a blocker, because that is disclosure rather than a breach. The list is short on purpose — if everything is an emergency, nothing is.
One consequence worth stating plainly: cert_expiry is a blocker that only gets measured on a Deeper check, because it is read off a live TLS handshake. A “Check now” cannot tell you your certificate expires next week.
Why “not measured” is never graded — and why that matters
A check the tool could not run is excluded from the score entirely.
That is the single most important thing to understand about the number. On a managed panel, PHP is confined to the site's own directory — which is correct and worth keeping — and that means /proc, /etc/os-release, the nginx config and the php-fpm pool config cannot be read at all. Seven checks then have no answer to give.
A tool that scored those as failures would punish you for a hardening measure you should keep. A tool that scored them as passes would be lying. SixPreflight does neither: those rows say “not readable from here”, one row in the PHP section explains why once and gives both ways round it, and none of them touch the score.
The same rule applies to the backup check. If no backup tool is found, the row is not measured — not a warning — because your hosting provider's snapshots are invisible from inside the server, and the tool refuses to call something broken that it simply cannot see.
A locked-down server must not score badly for being locked down. That is the rule, and it is why the number is worth reading.
The fix list
Every warning and every problem lands on the What to fix page, reds first, then in weight order. Each carries an impact label derived from the same weight that produced the score, so nothing is graded on one scale and prioritized on another.
- Stops orders
- Can stop orders
- Serious risk
- Risk
- Slows the site
- Worth fixing
- Tidying
Each card tells you what the setting is now, what it should be, which file it lives in, the command to run if there is one, and how to prove the change took. There is a “show me every line to paste” block per destination file, holding only the lines that still need changing — because copying twenty values one at a time is how a digit gets dropped. Settings to paste and commands to run are kept in separate blocks; they go to different places.
The database targets on the cards are derived from the same calculation that produces the my.cnf block you copy, so the per-row figure and the block can never disagree.
It also remembers
The tool keeps the last 60 scans on disk. The history page shows a “since the last scan” card — what newly broke and what you newly fixed — you can compare any two saved checks side by side, and export a run as a text file.
A read-only ?api=findings endpoint returns the last saved check as JSON for a dashboard or monitor. It never starts a scan: a monitor that triggered a full scan — one step of which fetches URLs off your live site — on every dashboard refresh would be a load generator wearing a monitor's clothes. The response carries run.age_seconds so the caller can say “this is two weeks old” instead of reporting stale news as current.
The other half
It also has a second half: the setup script
SixPreflight reads and explains. bin/setup-6ammart.php is the other half of the package: it makes the changes. The shipped docs page says it in one line — “SixPreflight reads a server and explains what to change. setup-6ammart.php is the other half: it makes those changes.”
A bash script with a .php extension, deliberately
PHP takes the file, hits an exit on line 3, and hands a browser nothing. Run it with bash, never through a browser.
The default mode is a dry run
Running it by accident changes nothing. --check reports current versus recommended. --apply does the work.
84 catalog entries, 40 of them safe to apply without asking
Its source of truth is the same tuning catalog the fix cards use — 84 entries across php, php-fpm, os, mysql, nginx, laravel and 6ammart, of which 40 are marked safe to apply without asking and 44 are prompted with the trade-off stated in one line, or printed as a manual instruction. No entry in the second group is ever applied silently, including under --yes.
Disputed count, stated openly
The shipped docs/setup.html page says 84 entries, 40 safe-to-automate, 44 not. The script's own header and a direct count of the three data/tuning-*.json.php files both say 86 / 41 / 45. The lower published figure is the one used above.
Writes to a live nginx vhost, the scheduler cron and anything that starts a queue worker over a backlog all sit in the prompted class: each shows exactly what it is about to do and asks, and --yes does not answer for them.
So SixPreflight is a checker with an opt-in fixer beside it, not a checker alone.
Four guides ship with it
The docs set gives the fixer a quarter of its pages.
How to use it
index.html — the dashboard, the two scan buttons, the fix list and the history page.
What to install, and where every credential comes from
requirements.html — the packages, the extensions, and which console each key is issued from.
Which PHP, database and OS
versions.html — the recommendation, the ranked scorecard, and the reason behind each pick.
What the setup script does
setup.html — the catalog, which entries automate, and which ones stop and ask.
Why this beats guessing
Four things you cannot check by eye
Against your own judgment
The vendor's prerequisite page lists minimums, and minimums are the wrong thing to build on. “MySQL 5.7+ / MariaDB 10.3+” hides that the two flavors behave differently under ONLY_FULL_GROUP_BY: MySQL 5.7.5+ enables it by default and copes, because it derives the functional dependency these reports rely on; MariaDB leaves it off, and breaks if you turn it on — the item-wise report then fails with ERROR 1055. That was verified by running the report on both, not assumed. So the mode has to stay off on MariaDB, and on MySQL the default should be left alone. The tool grades that specific combination, not the version number.
Against a phpinfo() page
phpinfo() prints values, and nothing more. Your real max_execution_time is the smaller of php.ini and the php-fpm request_terminate_timeout; SixPreflight works out that effective number and grades it. phpinfo() cannot size your InnoDB buffer pool from your actual RAM, your actual php-fpm worker count and your actual data size — SixPreflight does, then checks whether php-fpm's workers can even fit inside max_connections. It cannot compute an OPcache file-count target from the number of PHP files in your project. And it cannot tell you what the internet can fetch from your site, because it is not making requests.
Against your hosting company's word
“The server is fine” is not a claim anyone can check. This is: it fetches /.env off your own live URL and tells you what came back. It opens a real SMTP session. It mints a real Firebase token. It makes a real Maps call. Every one of those is a fact with a timestamp, saved to a file you can export and send to whoever told you it was fine.
And it tells you when it does not know
A tool that always has an answer is guessing somewhere. This one names the rows it could not measure and takes them out of the score.
Already on SixPanel?
Already on SixPanel? You already have this
On cPanel, aaPanel, CloudPanel or a bare VPS, SixPreflight is for you
You own the web server, PHP, the database config, cron and the certificate, so every paste block and every command is yours to use.
On a SixPanel server it is already there
SixPanel mounts SixPreflight inside the shop and surfaces it as the panel's own Shop check-up page. You do not download anything, and the settings the panel owns are pointed at the panel page that owns them instead of at a paste block that the next deploy would overwrite.
See SixPanelOne more honest note for that mode: on a SixPanel box the application's own settings — 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 and not the server's. The plain-English verdict at the top still speaks for the whole business.
Requirements and running it
Requirements, how to run it, and what it will change
What the tool itself needs
| Requirement | What it needs |
|---|---|
| PHP | 8.2 or newer to run the tool |
| Web server | Anything that serves your site's public/ directory |
| Write access | preflight/config.php (or paste a password hash by hand) and preflight/history/ |
| Application | None required. It runs on a bare server |
| Panels it recognizes | cPanel · aaPanel · CloudPanel · DirectAdmin · Plesk · CWP · plain server |
What it grades your server against
| Resource | Floor | What to pick |
|---|---|---|
| vCPU | 2 | 4 |
| RAM | 4 GB | 8 GB |
| Free disk | 20 GB on the requirements page — but the disk check itself passes at 20 GB, warns between 10 and 20, and only fails below 10 | 40 GB+ |
| Storage type | SSD | NVMe |
| Hosting type | VPS or dedicated | VPS with root |
The free-disk row genuinely disagrees with itself, and you will see it on screen
Requirements::platform() hardcodes “need 20 GB, pick 40 GB+”, while the hardware check grades against min_free_disk_gb = 10 from config.php — so a server with 12 GB free is a requirement failure in one table and an amber warning in another, on the same page.
In a browser — the normal way
Upload the folder
Upload the whole preflight/ folder into your site's public/ directory.
Set a password on the first screen
Open https://your-domain/preflight/ and set a password. It will not start without one, and whoever opens it first is the one who sets it — so do this as soon as the upload finishes. Minimum eight characters. If config.php is not writable, the page says so and gives you the one-line password_hash() command to paste instead.
Press a button
Check now takes about a second. Deeper check adds the outbound tests.
Delete the folder when you are finished
It is protected, but it reports server internals and has no reason to stay on a live site.
Optional: restrict access by IP with allow_ips in config.php (single addresses or CIDR ranges, IPv4 and IPv6). Behind Cloudflare or a load balancer the address it sees is the proxy's, so an allow-list of your own IP locks you out — leave it empty and rely on the password, or restrict at the proxy. If you do lock yourself out, the 403 page prints the address that actually arrived and what the proxy claims it is.
What it will change, if you ask it to
The scan reads. Four surfaces in the package can write, and none of them fires on its own — each needs a button or a command.
The Error logs page can clear a log
The Clear button truncates the file with ftruncate rather than deleting it, because PHP, MySQL and nginx hold those files open and unlinking leaves them writing to a handle with no name. It requires the CSRF token, and if the file is not writable by the PHP user it prints the shell command instead of acting. That is a write to Laravel, MySQL slow/error, php-fpm and web-server logs — files the tool does not own.
The Test order alert page sends a real push
To a real store or rider device, through the platform's own artisan command. A “Show what would be sent” dry-run button exists; it is not the default.
The database benchmark creates and drops its own table
Named zz_preflight_bench_<random> with a fresh random suffix per run — the full safety argument is below.
Setting a password rewrites config.php
And the dashboard's “save profile” action writes operator-supplied RAM and vCPU figures into the server profile file. Both live inside the preflight/ folder.
And separately, on purpose: bin/setup-6ammart.php applies changes when you run it with --apply. That is the point of it.
From the command line — no application, no browser
The two comparison tools are command-line only and refuse to answer over HTTP.
php preflight/server-compare.php # measure this machinephp preflight/server-compare.php --save=box-a.jsonphp preflight/server-compare.php --compare=box-a.json,box-b.jsonphp preflight/detect-size.php # record RAM and vCPUThey are not the only files with that guard. Eleven files in the package refuse to run outside the command line — those two, eight test harnesses including tests/smoke.php, and bin/setup-6ammart.php. tests/smoke.php is the reason the guard matters: left web-reachable with no password, which is how it once shipped, one anonymous GET cost eleven seconds of CPU, a full probe of the application database, ten requests the server made to its own public URL, and outbound calls to Google Maps, the configured SMTP host and Firebase, repeatable as often as anyone liked. The scan now probes your server for exactly that file, because a folder like this gets copied between machines for years.
server-compare.php is standalone and has zero dependencies — it needs no application at all, which is what makes it the right tool for comparing two servers you are thinking of renting, before you commit to either.
Reading the benchmark scores
Both scores are normalized so they mean the same thing at any difficulty setting — only the machine changes them, and higher is faster. A current cloud vCPU reads about 100. Run it two or three times at different hours: a burstable instance drops sharply once its credits are gone, and that will not show in one run. The reference machine behind that 100 is an AMD EPYC 7713 vCPU with local NVMe, PHP 8.3, OPcache on.
On the database score, watch single-row INSERT/sec in particular: with innodb_flush_log_at_trx_commit=1 each one waits for a disk sync, so that number is really your storage's fsync latency. It is the clearest difference between providers.
Apply the suggested my.cnf first, then compare two servers — otherwise you are comparing configurations, not machines.
What to actually install
SixPreflight's own recommendation, for a native install with no containers:
- Ubuntu 26.04 LTS
- PHP 8.5
- MariaDB 11.8
PHP 8.5
Whatever your release's own archive ships — 8.5 on Ubuntu 26.04, 8.4 on Debian 13, 8.3 on Ubuntu 24.04. 8.5 was doubted because phpspreadsheet, via maatwebsite/excel, declares php <8.5; that is a declaration in composer.json rather than a measurement, composer's platform check is off, and running the code on 8.5.4 produced a byte-identical spreadsheet export on both the plain CodeCanyon tree and our own fork. All of them run at effectively the same speed, so this is not a speed decision — take the one your release patches for you.
MariaDB 11.8 or 10.11
Either, whichever your release carries — measured on the same shop, 11.8 against 10.11 is a wash. What is not a wash is the flavour: both MySQL versions need code changes before 6amMart will run on them at all, because item search sets a MariaDB-only optimizer flag and two index migrations read a server catalog in a case MySQL does not return, leaving the schema part-applied.
Ubuntu 26.04
Level with Ubuntu 24.04 and Debian 13 on speed — the measured differences were smaller than one machine’s disagreement with itself. What separates them is the support window: April 2031 for 26.04, against May 2029 for 24.04 and August 2028 for Debian 13. This is a support-window decision, not a speed one.
What those engine figures cover They come from one machine and one dataset — a real shop's dump of 66,701 orders — with each engine migrated first and the resulting index sets diffed to 460 indexes, identical on all five, so the comparison is of engines rather than of missing indexes. They compare the five engines against each other on that one box. They are not a statement about how fast 6amMart is in general.
Nothing here says one operating system is faster than another: the measured differences between operating systems were smaller than the spread of a single box against itself.
How it runs
Nothing in the package checks a license, an account or an expiry date, and nothing in it reports anything back to AllsWeb. The outbound calls it makes are all to places you already deal with — your own site, your own SMTP host, Google's token and geocoding endpoints — plus one public-IP echo service to discover your own address.
The honest reason the checks exist at all: they came out of building and fixing these servers, and every one of them is a question we would have to ask you anyway. A shop owner who can answer them before getting in touch saves a day; a shop owner who cannot gets a report they can send to their host.
Honest limits
Read this before you rely on the number
It cannot see what the server will not show it
Checks that need shell_exec or /proc degrade to “not measured” rather than guessing. Managed panels disable different things, so some rows are blank on one host and populated on another.
On a managed panel, seven checks have no answer
open_basedir confines PHP to the site's directory. That is correct and worth keeping. The rows say so and are excluded from the score.
A “Check now” cannot see six of the web-server rows, and one of them is a blocker
Compression, static caching, live keep-alive, the server banner, HSTS and certificate expiry are read off a real response, so they only appear on a Deeper check — and cert_expiry is on the blocker list. Run the Deeper check before you trust a green result.
The tool contradicts itself on free disk
The requirements table says you need 20 GB free; the disk check calls 10–20 GB a warning and only fails below 10. Two answers to one question, on one page.
It reports what the server says it is configured with
If a panel applies configuration at a layer this tool cannot see, trust the panel's own interface over this. cPanel and aaPanel manage PHP and MySQL config through their own UI and can overwrite hand-edited files; CloudPanel and a plain server leave the config files authoritative. If a setting keeps reverting after a restart, that is the panel rewriting it — change it through the panel instead.
The benchmarks measure this machine at this moment
A noisy neighbour makes every number pessimistic — check the load-average row before drawing conclusions.
The exposure step is not a penetration test
It fetches a fixed list of known-risky addresses off your own URL and reports what came back. It does not look for unknown vulnerabilities and it is not a code audit.
One thing genuinely cannot be tested from a server
The Google Maps client key is restricted by browser referrer, so the tool can tell you it is missing, or that it is dangerously identical to your server key — but it cannot verify a correctly-restricted one from the server side, and says so rather than passing it.
Row counts in the size table are estimates
They come from information_schema. Exact counts would mean a full scan of every table on a live site.
An upload buried more than five directories below artisan gets standalone mode
Silently — the application-root search stops at five levels.
It is a checker first
The scan itself changes nothing. Four surfaces in the package write when you press their button, and bin/setup-6ammart.php applies changes when you run it with --apply. All five are listed above.
Is it safe on a live shop?
Yes, and here is exactly why.
The real-data probes are read-only by construction
Every probe goes through one query() method that refuses anything that does not begin SELECT, EXPLAIN, SHOW or WITH — and there is no code path in that class that can issue INSERT, UPDATE, DELETE, ALTER, CREATE or DROP, which is the guarantee that actually carries the promise. The session is put in TRANSACTION READ ONLY where the server supports it, so even a mistake would be rejected by the database rather than by this code. Every statement carries a 15-second server-side limit, so a probe against an unexpectedly huge table cannot sit holding resources — and a probe that trips it is reported as “too slow”, which is itself the finding. Verified: row counts and SUM(order_amount) are identical before and after.
The database benchmark never touches an application table
Every object it creates is named zz_preflight_bench_<random> with a fresh random suffix per run; it checks the name is free before creating anything and aborts rather than touching an existing table; no statement in it can name a table it did not create; cleanup is gated on the table having actually been created, runs in a finally block and a shutdown handler, and writes commit in small batches so nothing holds a long lock. Verified: orders and items row counts identical before and after, and no zz_preflight_ table survives the run.
The scope is the table, not the database, and the difference is the whole promise
It never reads from or writes to any application table — that is the README's own wording and it is the right one. The benchmark creates and drops one table of its own inside the application's database, under a name it generates, and removes it again; nothing else in that database is touched.
Inside its own folder it writes one thing
preflight/history/, one file per saved scan. Those files describe the server's weaknesses in detail, so each is named .json.php and starts with a PHP exit statement — fetched over HTTP the web server executes it, stops immediately, and returns nothing. That holds on nginx too, which ignores .htaccess.
Got a red list and no time?
Send us the exported report. We install, configure and hand back 6amMart on your own server, with a senior engineer signing off the release.
Server ready, shop still slow?
SixPreflight tells you whether the server is ready. If the shop itself is slow, that is the application, not the server — and it is what the 6amMart installation service now ships on top of the latest 6amMart release: the AllsWeb-optimized 6amMart build measured 10× to 22× faster — 90–95% faster — on every customer-facing screen, measured on the live server, with the CDN bypassed.
FAQ
Questions people actually ask
How do I know if my server is ready for 6amMart?
Run SixPreflight on it. It holds 163 checks across hardware, PHP, the application, .env, permissions, the web server, caching, the database, public exposure and every outside service. A Deeper check on a 6amMart install runs the full set available to it — 160 distinct checks, and no more than 157 rows on a real box running one web server; a quick “Check now” runs 123, no more than 120 on that same box, skipping the 12 exposure checks, the 21 service checks and the six web-server rows that need a live response. Either way it ends in one sentence, a letter grade A–F, and an ordered list of what to fix first.
Does SixPreflight change anything on my server?
The scan does not. It never reads or writes an application table, and never sends mail or SMS to anyone. Four surfaces do write when you press their button: the Error logs page can truncate a log file, the Test order alert page sends a real push to a real device, the optional database benchmark creates and drops its own table, and setting a password rewrites the tool's own config.php. The package also ships bin/setup-6ammart.php, which applies changes on purpose when you run it with --apply.
Is it safe to run on a live shop that is taking orders?
Yes. The database probes are read-only by construction — the query() method refuses anything that does not begin SELECT, EXPLAIN, SHOW or WITH, there is no code path in that class that can issue a write, and the session runs in TRANSACTION READ ONLY where supported. The optional benchmark works only on a table it creates itself with a random name, and removes it in a finally block and a shutdown handler. Both were verified by comparing row counts and SUM(order_amount) before and after.
Do I need 6amMart to use it?
No. It detects what it is looking at. On a plain server with no application it still checks hardware, PHP, the database server, the web server, permissions and exposure — though the 14 .env checks, the 12 Laravel application checks, the 9 6amMart platform checks and the 5 realtime checks have nothing to read, leaving only the profile row from the application step. On any Laravel application, everything about the server still applies and the 6amMart-specific checks are skipped rather than guessed at. On 6amMart, every check that can run does.
What score do I need before I go live?
90 or above is an A — production ready. Below that, read the blockers first: a single blocker caps the score at 74 no matter how good everything else is, two cap it at 54, three or more at 34. Even with no blockers, one red row caps you at 88. Blockers are the things that stop the shop trading — no usable payment method, mail failing, the database unreachable, .env readable over the web, a certificate expiring inside 14 days. Run a Deeper check before trusting the number: that last one, and five other web-server rows, are not measured at all on a quick check.
Why do some rows say “not readable from here”?
Because your hosting panel confines PHP to your site's own directory, which is correct and worth keeping — so /proc, /etc/os-release, the nginx config and the php-fpm pool config genuinely cannot be read. Seven checks then have no answer. They are reported honestly and excluded from the score entirely, so a locked-down server is never punished for being locked down.
Does it work on cPanel, aaPanel, CloudPanel or a plain VPS?
Yes — that is its main market. It recognizes cPanel, aaPanel, CloudPanel, DirectAdmin, Plesk, CWP and a plain server, and gives per-panel install commands and paths. Worth knowing: cPanel and aaPanel manage PHP and MySQL configuration through their own interface and can overwrite hand-edited files, so if a setting keeps reverting after a restart, change it through the panel instead.
Does it only tell me what is wrong, or can it fix it?
Both, and the fixing half is opt-in. The dashboard asks you to make each change by hand first, because a person who makes a change understands what they changed. When that is not practical, bin/setup-6ammart.php does the same work from the command line: default dry run, --check to report, --apply to act. It applies only the catalog entries flagged safe to automate — 40 of the 84 published entries — and prompts or prints the rest, including under --yes.
I run SixPanel. Do I need to download this?
No. SixPanel mounts SixPreflight inside the shop and surfaces it as the panel's Shop check-up page. In that mode it drops the paste blocks for anything the panel owns — the web server, PHP, database configuration, cron, the queue worker, the certificate — and points at the panel page that owns each setting, because a value pasted by hand there is lost at the next deploy. It keeps every application-level check.
What PHP and database version should I actually install?
Ubuntu 26.04 LTS, and then whatever its own archive ships — PHP 8.5 and MariaDB 11.8 — for a native install. PHP 8.5 was doubted because one dependency declares a bound below it, but that bound is a declaration and not a measurement: running the code on 8.5.4 gave a byte-identical spreadsheet export on the plain CodeCanyon tree and on our fork. Every PHP and MariaDB version measured ran at effectively the same speed, so none of this is a speed decision. What is real is the flavour: both MySQL versions need code changes before 6amMart runs on them at all, because item search sets a MariaDB-only optimizer flag and two index migrations read a server catalog in a case MySQL does not return.
Can I plug the result into my own dashboard?
Yes. ?api=findings returns the last saved check as JSON over HTTP Basic auth, with a stable contract version. It never starts a scan, and the payload carries run.age_seconds so your dashboard can say “this reading is two weeks old” instead of presenting stale news as current.
Upload one folder. Open it in a browser. Get one answer.
Always the current release, running on your own server. It reads first, and it tells you what it could not measure instead of guessing.
Nothing in the package checks a license, an account or an expiry date, and nothing in it reports anything back to AllsWeb.