SixPanel release notes

• Ubuntu 26.04 LTS and Debian 13 are now supported, and Ubuntu 26.04 is the one to pick for a new server. The three supported releases install these, each from its own distribution's archive, so security patches arrive the same way the rest of the system's do:

Which one is fastest was measured rather than assumed, on identical servers with the same 66,701-order shop on each. The honest answer: the differences between these stacks are small enough that any of the three is a good choice — pick on how long the release is supported, not on speed.

• Ubuntu 26.04 installs no longer fail on the PHP version Ubuntu itself ships. The installer refused PHP 8.5, so the recommended operating system could not be installed at all — it stopped with "PHP 8.5 cannot run 6amMart". That was read off a library's declared version range rather than measured; running the code proved 6amMart works on 8.5, including the spreadsheet export the limit was about. Checked on both the plain CodeCanyon code and the optimised build.
• Debian 12 is no longer supported, and the installer now says so by name and points at Debian 13. Debian 12's security support ended on 11 July 2026, and the only PHP in its archive stops getting security fixes on 31 December 2026 — so a box installed on it would have quietly stopped receiving patches.
• A fresh install no longer tells its owner the server might be compromised. On the first boot after installing, the panel's file-integrity check reported 14 of the installer's own files as hand-edited, with the advice "change this server's passwords" — the most alarming message the panel can produce, on a server nobody had touched yet.
• The panel no longer names the wrong operating system. Five places said "Ubuntu" to an owner running Debian, in the health report, the disk page and three translations.
• Node.js is now one stated version (26.8.1) that the build and the installer both read from a single file, instead of each deciding for itself. A side-effect of the old arrangement: on a server upgraded across Node major versions, yarn could go missing while the install still reported success, and the failure only surfaced later when deploying the customer website.
• The customer website can now be installed before you have a certificate. It used to be pointed at https:// your admin address no matter what, so on a shop that had not finished Domain & SSL yet the website could not render a single page: every page asks your admin panel for its configuration from the server side, and that call was refused because there was no certificate to trust. The deploy failed with "the website started but answers HTTP 500" and nothing said why. It now uses http:// while a host has no certificate — which is the address that actually works then — and https:// once it has one.
• Getting a certificate now rebuilds the website by itself. The address is compiled into the website when it is built, so changing a file afterwards changes nothing that runs. Finishing Domain & SSL now schedules the rebuild, says in the job log which address moved and why, and skips the rebuild when nothing moved.
• The website's own published address (the one in its canonical and share-preview tags) follows its OWN certificate, separately from your admin address — so one can be secured before the other without either of them advertising a link that does not open.
• If the website still answers an error after a deploy, the failure now names this cause when it is the cause, instead of only reporting the error code.

• The read-only demo no longer names the other websites on your Cloudflare site. The check-up row that lists them ("served somewhere else, not by this server") was still printing them in full — those are your own other addresses, so they are now shortened like everything else.

• Tightened the shortened values in the read-only demo. A very short email address or machine name was being shown in full, and a plain machine name (no dots) was passed through as it was. Everything that names someone is now shortened, however short it already is. localhost and names like box.local are still shown as they are — they are true of every server and hide nothing.

• Hidden values in the read-only demo now keep their shape, so a row still makes sense. A domain reads `da*.al*.net, an email ow*@al.net`, an address `203..., a folder /home/* — the visitor can see what kind of thing the row is about without learning whose it is. Before, all of them were replaced with ***`, which hid the point of the row along with the value.
• Passwords, keys, tokens and the database user are unchanged: those are still hidden completely, because half a password is still a password.

• The read-only demo is now stopped at the control it pressed, instead of being asked to confirm a change that could never happen. Four places opened a confirmation or a whole multi-step wizard first — creating a project, adding backup storage, turning automatic backups off, applying Cloudflare settings — and only refused at the end. Every confirmation and every wizard in the panel now answers a demo visitor straight away with the same read-only note.
• A new temporary login's password is labelled "Password" again; it read "Demo password".

• A new temporary login is now handed to you as three separate fields — the address to open, the username, the password — each with its own Copy button. Before, all three sat in one box that only kept a single line, so copying it produced one run-together string; pasted into the address bar that read as a broken panel ("unauthorized") when nothing was broken. The all-in-one-block form is still there, folded away, for pasting into a message.
• The language and theme buttons in the header are square again inside a project. The project switcher was taking the space they needed, and the browser squeezed them into ovals with the icon pressed against both edges.
• The read-only demo no longer shows any of this server's addresses. Every shop domain, and the panel's own address, is now hidden from it the same way passwords, email addresses and file paths already were — the demo password is public, so an address is an identity too. Your own login, and temporary logins, still see everything as before.
• The "demo" marker in the sidebar is one short word now, with the full wording in its tooltip; it used to be wider than the sidebar and wrapped under the version number.

• The read-only demo now shows every page in the navigation — nothing is tucked away. The Security page answers it with one honest owner-only card, pages whose data the demo may not see say so in place of it, and the server keeps refusing every write and every secret regardless of what is visible.

• Testing a fresh temporary login finally works the way an owner actually tries it. The share block's address now carries the username (…#u=temp1), and opening it shows the sign-in form with the username filled in — even in the browser that is already signed in as you, which used to land in your own panel and make every new login look broken. Signing in there switches the session; the hint under the block explains both that and the private-window way to test side by side.
• When a demo visitor presses any button that would change something, the refusal now says, in their own language, that this is demo mode — you can look at everything, change nothing. A live battery of 47 checks (every mutating request family, every secret-carrying read, every showcase page) now proves the read-only demo: all writes refused, all secrets refused, all pages readable.
• The theme button shows the sun in light mode again (the one-release flip to target-mode icons is reverted), and header icons can no longer be clipped at odd browser zoom levels — the icon used to sit on the text baseline, which at some zooms pushed its bottom edge under the button's.
• When temporary logins expire, the log line now names them — "temp1 stopped working" is only diagnosable if the trail says temp1 expired.

• The project switcher's new chevron actually shows. 1.4.52 drew it as a background image, and the pill's own background shorthand immediately painted over it — visible for exactly one screenshot. The pill now sets its colour without touching the image.

• The Cloudflare page no longer lists a ghost project called "localhost" on a fresh install. That row was the panel's own hidden default project wearing the installer's DOMAIN placeholder as a name; it is now hidden here exactly as it is everywhere else, and a placeholder domain can never become a project's display name.
• The project switcher draws its own clear chevron — the browser's native select arrow was a hairline glyph that all but disappeared inside the pill (light, dark and right-to-left languages each get theirs).
• The theme button now shows the mode a click gives you — a moon while the panel is light, a sun while it is dark — matching the words in its own tooltip. It used to show the mode you were already in, which read as the wrong icon.
• The read-only demo's backup page: the custom-schedule storage list now also says the demo hides storage destinations, instead of claiming none exist.

• The read-only demo now shows much more of the panel, and never lies about what it hides. A demo session can see real job history and the live "job running" pill (step error text stays hidden — those lines are raw command output); the pages whose data the demo may not see — the activity feed, cron entries, backup destinations — now say exactly that in the demo's own words instead of a red error or a false "nothing here yet". Every write stays refused and every secret stays masked, exactly as before.
• Passwords pasted with a stray trailing space or newline now sign in. A password copied out of a terminal, an email or the temporary-login share block usually arrives with one, and the login then failed on a value that was right. The trimmed form is tried only after the exact one fails — a password that genuinely ends in a space still works, and nothing gets looser.
• After creating a temporary login, the panel now tells you the one thing that makes it look broken when you test it yourself: this browser is already signed in as you, so open the address in a private (incognito) window to see the login form.

• The Settings page's "Automatic disk cleanup" row no longer says off on a server where the cleanup is actually on. Never touching the setting means ON (every option, Sunday 04:30) — the Disk page and the timer itself have always honoured that default, but this one row read the raw saved value and showed "off" until the owner saved the setting once. It now asks the same module the timer does, so the three places can never disagree again.
• Reverb (the live order tracking websocket) now writes its log to the application's own log folder — storage/logs/reverb.log, beside Laravel's — instead of the system journal. That is where everything already looked for it: the panel's Error logs page, SixPreflight's "Where Reverb writes" row, and both log rotators cover that file by name. Existing projects pick this up on their next panel restart, which re-renders the service definition and restarts Reverb onto it.

• The "Database care and speed indexes" health row no longer claims a build attempt failed when none did. A panel update can add a new speed-index rule during the day, and until the 04:10 nightly pass has run the index is simply not there yet — the row used to read that as "the last attempt could not build them", blaming a job that did nothing wrong. It now says both possibilities honestly, and the Run-now job log names which one it was.

• The two remaining slow first-loads after a panel restart are gone, finishing the work 1.4.47 started. The version check used to dial the update service inline on the first request after every restart — 1.7 seconds, riding in the boot burst of the first sign-in — and now answers instantly ("checking" on a server that has never checked, the last verdict otherwise) while one background refresh fills the cache; the badge and the Settings page quietly re-read a few seconds later. The explicit "Check now" button still waits for a live answer, as a pressed button should. And the dashboard overview used to pay its cold costs — a CPU sample plus spawning PHP and the database client for their version strings — in the first request after a restart (measured 1.6 s against 0.5 s warm); the server now pays those once at boot, before anyone signs in.

• The panel opens noticeably faster, and never as a blank page. Two causes, both measured: the panel-address endpoint made a live call to Cloudflare's API on its first request after every restart — 2.3 seconds, sitting on the boot path of every sign-in — and now serves its last answer instantly while refreshing in the background (the what-is-my-IP lookup got the same treatment). And while the panel boots on a slow connection, the screen used to be pure white for the whole download; it now shows the SixPanel mark and a spinner from the very first paint, with no script involved — so even a boot that dies shows motion instead of a void.

• Five refinements to the new busy buttons and notifications, found by an adversarial review the same day: a notification being read (pointer on it, or keyboard focus on its close button) is never the one evicted when five stack up, and it leaves with the same fade as a dismissal; keyboard focus now holds a notification open exactly the way hovering does; on phones a tap anywhere on a notification dismisses it (tap used to pin it open, because a touch "hover" never ends); after a failed login the keyboard focus returns to the password field instead of being dropped; and the busy-spinner's internal marker was renamed so it can never collide with the job system's own button tagging.

• Every button you press now shows that it is working: the moment an action disables its button, a small spinner joins the label and stays until the panel answers. A grey button used to read as broken; now it reads as busy. The Log in button does this too — a click on a slow connection no longer feels dead.
• Notifications were redesigned to actually be seen: each one opens with a coloured verdict icon (green tick, red cross, amber mark), can be dismissed with its own close button, and holds on screen while your pointer is over it — an error stays up longer than a success. At most five stack up; the oldest makes room.
• The "Panel files unchanged since install" health check no longer raises an alarm about the panel's own phpMyAdmin download — over four thousand files the panel itself fetched (and checksum-verified) were being reported as "present that the release did not install".

• Push-to-deploy no longer refuses a push whose commits were made earlier and pushed later (a rebase, or local work pushed after the fact). The anti-replay staleness bound now measures when the PUSH happened — the forge signs that timestamp — instead of when the commit was written, which once made the panel record a perfectly genuine delivery, answer GitHub "stale delivery", and deploy nothing. A replayed old delivery still carries its original push time, so the protection stands unchanged.

• The utf8mb4 fix button works on its very first press: the first release read the list of narrow tables in a shape the database client never returns, so the fix widened the database default and then stopped with "Table 'undefined' doesn't exist" before converting anything. The fix now names each real table, and a new build gate replays the exact wire shape the client answers in, so this class of mistake cannot ship again.

• The SixPreflight page can now FIX two findings itself: "Whether emoji and every language are safe to store" (the panel converts every still-narrow table and column to utf8mb4, re-checking the live schema first) and "Modules enabled but not installed" (the ghost entries are switched off in modules_statuses.json so the file reflects reality). Each fix is a real job with a live log, runs only for the signed-in owner, and says in its last line that the reading clears on SixPreflight's next check.
• Alert emails got a design: one clean card — who is talking and which server, a coloured verdict line readable from the inbox preview (red = needs you, green = resolved, blue = information), the details in readable paragraphs, and a footer that says why the email arrived. The same words still travel as plain text beside the HTML, and no email ever carries the panel's secret address.
• The panel opens in your language when you arrive from the AllsWeb site (?hl=<language> on any panel link — the same eight languages both sides speak), and every link out to allsweb.com returns you to the site in the language you are reading the panel in.
• An uploaded .php file under /storage/app/public/ is now refused outright (404) instead of being served as text — the nested vhost rule the ^~ prefix always needed. SixPreflight's "upload folder runs PHP files" reading turns green on the next check.
• tmp_table_size / max_heap_table_size floor is 128M on servers with 3 GB+ of RAM: measured on the reference box, 64M spilled a third of all temporary tables to disk mid-query with gigabytes free.

• Updates no longer stop on a tree the app itself dirtied: 6amMart's translate() appends any missing key to resources/lang/*/messages.php at request time, so on a live shop the tracked file drifts modified just from pages being viewed, and every later update refused with "local changes present". The update now reverts those files before the clean-tree check — lossless, because the app re-adds any missing key the next time its page renders, while keeping the old copy would clobber the keys a new drop ships.
• The index pack gains order_details (item_id, order_id, quantity, price, discount_on_item): the item-wise and store-sales report aggregates become index-only instead of paying ~113k row lookups for the summed columns (measured on the reference dataset: 610-1,060 ms unstable → ~310 ms stable).

• The Activity page's project filter listed the hidden built-in "default" project on servers that never used it; its rows (panel self-updates, mostly) now read as server-wide, the way every other page treats it.

• A new Activity page (panel menu, next to Backups): everything that happened on this server in one stream — every admin action with the address it came from, and every job with its status and a "View log" button. Filter it every way at once: WHO (a signed-in admin, or the panel acting by itself — and the badge says whether that was the schedule, a push deploy, self-heal or the CLI), WHICH PROJECT it touched (or server-wide), WHAT KIND of thing it was (backups, deploys, domain & SSL, database, security…), plus a text search over the details. Filtering repaints in place — no page jump, no lost scroll.
• Jobs now record who set them off. New jobs carry their origin (admin / schedule / webhook / self-heal / CLI); history from before this release shows an honest "—" rather than a guess.

The running-job work, finished the way it feels rather than the way it reads in code — three reports from real use, three fixes:

• The page no longer jumps to the top when a job starts or ends. Press a button halfway down a page and the page stays exactly where you are — the button under your finger, now quiet, with the running strip beside it. Opening a different page still starts at the top, as it should.
• The end of a job is announced by name, everywhere. "“backup full → Contabo S3” finished ✓" appears wherever you are — another page, another tab, scrolled away — and a failure says FAILED in red with a pointer to the log. Before this, a finished job changed one small chip and nothing else; which action had finished was anyone's guess.
• The live log now ends with a verdict, not a last line. The log closes with an unmissable "✓ ✓ ✓ THIS JOB FINISHED — every step completed." (or the red ✗ version naming failure), and the log panel itself takes the verdict's colour along its edge.

• A queued certificate request could quietly undo another one. Ask for HTTPS on the website while the admin domain's certificate was still being issued, and the second job — finishing later — wrote the domain records back the way they looked when it was QUEUED: the admin domain's fresh certificate flag included. Nothing visible broke until the next panel restart re-rendered the web server from those records and dropped the admin domain's https server — the shop's admin went unreachable hours after every job had reported success. A certificate job now saves only what it certified, merged into the records as they are at that moment.

• 1.4.35 could not start. The 1.4.35 panel crash-looped on every server that installed it: the build had deleted a file the panel reads at its own startup. If your panel went unreachable after updating, this release fixes it — and the build now refuses to package any release whose compiled tree does not boot and serve its own login page first.

The panel always knew only one job runs at a time; now every page does too. The round started from one report: upload the install zip, the live log opens — and the form you uploaded from sits there unchanged, still willing to take the same zip again. Every flow on every page was then checked for the same class of gap.

• A running job shows everywhere. A pill in the page header names whatever is running, on every page; clicking it opens the live log. The page whose flow it is paints a progress card — each step ticking off as it finishes — and that card is still there after a reload, in another tab, and for jobs the panel started by itself (a push deploy, the scheduled backup).
• While it runs, the buttons that would collide with it go quiet — and come back by themselves the moment it finishes, with the page repainting to show what changed.
• The same action cannot be started twice. A second "run backup now" while one runs is refused with a sentence, not queued behind it; same for a certificate request (Let's Encrypt rate-limits repeats, so a double press had a cost), the websocket wizard, a .env apply. Installs, updates, rollbacks and restores refuse while anything at all is running — including the narrow window two browser tabs used to be able to win.
• A refused upload costs a second, not ten minutes. The zip upload used to go up completely and only then learn a job was running; it is refused before the first piece now. The database import gained the same manners.
• A successful install now says so. A leftover error in the success path meant the one flow everyone runs first finished silently — no message, and the page still saying "not installed" until a manual reload.
• The website zip update asks before shipping, the way the admin one always did — a slip on the file picker used to rebuild and restart the live storefront with no way back.
• "Run now" on a scheduled task now follows the run to its end and reports how it went; failures used to vanish.

What installing 1.4.33 on a third server, from a bare Ubuntu to a full shop, turned up. The install itself was clean — no spare services appeared, the wizard's one-click backups worked, the websocket address was finished by the install — and the round's own log-reading found these:

• A minute-by-minute error in the log of a shop nobody had broken. From the moment an install's code lands until the install (or the vendor's own web installer, which can take a while) finishes, the scheduler was already ticking — against a database with no tables in it, one error line per minute, ending in a "15 errors in 24h" warning on the shop's first check-up. The workers now stay off from the moment the code lands until the install has finished.
• The restore test mentioned a project you cannot see. On a server whose built-in "default" project was never used (every server installed since it became hidden), the test still listed it: "localhost — empty database — nothing to prove". It no longer appears anywhere on the Backups page.
• The storefront install ended with wrong directions. "Set the website domain, then turn the website vhost on" — on a server where both had happened automatically at project create. It now says the site is live at its address, or names the one thing actually missing.
• The Home page's backup card says when the next automatic backup runs.

A night on the database and on the panel itself, measured with a real shop's data (a 410 MB database) on the optimised codebase and on the untouched CodeCanyon download.

Your database is looked after by itself now

• The speed indexes apply themselves. 6amMart's tables lack the indexes the admin panel and the apps need for the queries they run most, and the card that offered to add them had a button nobody pressed — the shop installed from the CodeCanyon zip on the second server was missing 34 of them. They are now added at the end of every path that puts data into a project's database: install, the vendor's own web installer, update, zip update, transfer, database import and restore. Measured: 36 indexes added to the vendor shop in 1.0 s, the shop answering throughout. Two new ones make the order reports faster — the store report 151 → 36 ms, the earning report 180 → 77 ms on the real data.
• Nightly database care, nothing to set up. Every night at 04:10 the panel removes what the app can never use again — expired and revoked sign-in tokens (24,578 on the real shop, which 6amMart never purges), day-old one-time codes (4,956), stale password-reset tokens, expired cache rows, failed jobs older than 90 days — re-checks the speed indexes, and on Sundays rebuilds tables that have freed a lot of space, after checking the disk can hold the rebuild. Measured: 33,232 rows gone in 1.2 s, shop answering throughout. Your own rows — in-app notifications, visit and search logs — are kept for ever until you choose otherwise on the Database page, where each choice says exactly how many rows it would remove.
• The check-up page has a row for both, and the Database page shows the last pass and what tonight's will remove.

Things that were wrong and looked fine

• Every server kept a spare set of services for a project you never see. The first thing the setup wizard saved created a PHP pool with two idle workers, a Redis server and four service units for the built-in "default" project — on every server installed from the public command — and the services table listed them as four stopped services. They are retired when idle, and a server where it already happened cleans up at its next restart (verified: both shops answered throughout). A follow-up read found that a push from GitHub could bring them back, from the internet, unsigned — the webhook no longer can, and an unsigned push answers 401 and creates nothing.
• Turning phpMyAdmin off could stop PHP for every shop on the server when its pool was the last one. It keeps one pool serving now.
• A new project's live-updates address sat as "needs you" until you found the wizard for it. Creating a project registers the address; nothing could serve it until the app existed; and the step that finishes it was a wizard on the Domain page. The install finishes it now, and the apps are pointed at the address only once it answers. Verified on both shops of the second server, through Cloudflare.
• The check-up said "7 files changed by hand — treat this server as compromised" after the panel itself had re-written its own server files at boot. Every write the panel makes is on the ledger now.
• "15 error lines in the last 24 hours" on a shop installed an hour ago were the log's previous life. Errors are counted from the moment the app was installed.
• A table rebuild that ran out of disk was logged as space given back. MariaDB reports that failure in the result rows, not the exit code; the rows are read now, the disk is re-checked per table, and one failing rule no longer cancels the rest of the night.
• A PHP-extensions row that warned "user does not exist" on fresh servers, a website row that timed out on a site answering in 100 ms because every check ran at once at boot, and a check-up that the Home page waited for before it painted anything — all three fixed. Home paints in about 90 ms and the attention card fills in when the verdict lands.

The panel is lighter

Every page was read for what it repeated, what it asked for no reason, and what it showed about a different project than the one in the heading.

• The check-up folds its healthy and informational rows behind a count; what needs you is all that is open. Every "Take me there" opens the row's own project.
• The Cloudflare tab no longer draws twenty-five full cards to say "nothing to do" twenty-five times: what differs stays open, the rest folds, and the verdict counts only the settings "Set this up for me" would change. The "how is Cloudflare set up" question can be answered with one click.
• Backups: one schedule card instead of the same plan stated three times, the first storage's snapshots load with the page, and the restore test says which databases it proved rather than printing the same list twice. Every "next run" on the panel reads "in 9h · date" — a server clock on UTC and a browser elsewhere used to show two different times for one backup.
• Deploys: a shop installed from the CodeCanyon zip shows the zip, "by hand", and the buyer username it was installed with — no branch, no automatic deploys, no mode switch, and the admin password is generated for you.
• Logs: one tab per service that actually runs for this project.
• Projects, Overview, Database, Settings: the permanent green hero, the finished setup meter, two cards that repeated the sidebar, the clock essay and the self-heal service list are gone or folded to a line.
• The setup wizard's last screen turns daily backups on itself instead of sending you to the Backups page, and has one "Exit setup" instead of two kinds of skip.
• Weekly disk cleanup is on by default on a server that never chose.
• Eight languages: this round's new and reworded text is translated, not left in English.

A second server, wiped to a bare Ubuntu and installed with the public install command, then driven end to end twice over: once with a real shop's data on the optimised codebase, and once with the untouched CodeCanyon download. Everything below is something that walk found.

Things that were broken and looked fine

• Your apps could be told your shop has no live order tracking, and every page on this panel said it was working. 6amMart hands the phone apps their websocket address out of its own settings table, and restoring a backup — or importing a database from another install — replaces that table with whatever the backup held. The websocket server was running, this server was routing to it, and the address handed to the apps was empty. Live order tracking was dead in every app on the shop and nothing said so.

Two things changed. The check-up page now asks the question the apps ask, so a shop whose apps cannot see the address is a failure with the one button that repairs it. And restoring a database now corrects the address by itself, so you do not need the check-up page to notice.

• Your customer website could be down and the check-up page stayed entirely green. Nothing on it asked about the website at all — every row was about the admin panel, the API, the database or the workers. Measured with the website stopped: shoppers were getting an error page while all twenty-two rows were green and the server reported no failed service. There is a row for it now, and it asks over your own server rather than trusting what a visitor's cache answers.

• A website that was down still answered "everything is fine" to the internet. The friendly "This shop is not open yet" page was served with a success code, so Cloudflare cached it as a good page, a search engine would index it as your home page, and any uptime monitor stayed green through the outage. It now answers with the correct temporary-error code and says when to come back.

• "Alerts go to you@example.com" did not mean any alert had ever arrived. The row checked that the settings were filled in. A wrong password, a wrong port, or a mail provider that started refusing — all of which leave the settings looking perfect — meant every alert this panel produced was being thrown away while the page said alerts were fine. It now reports what actually happened to the last one: refused (quoting the mail server's own words), accepted (with when), or never needed yet — and it says which.

• The row that promises PHP is confined to its own folders was reading the wrong thing. The confinement is fixed when PHP starts, so a change that was never followed by a restart is on disk and not in force — and the row was reading the configuration on disk. It now asks the PHP that is actually serving your shops.

The CodeCanyon zip could not be uploaded at all

The 6amMart admin download is 354 MB, and installing from that zip is how most buyers start. It could not arrive: too large for the panel's own web address, too large for Cloudflare in front of it, and the panel's direct address is closed once it has a domain of its own — which it does, on any properly set-up server.

The panel now sends a large zip up in pieces and puts it back together on the server. Proven on the real download: 354 MB, in 45 pieces, none of which needed retrying, followed by a clean install of the untouched vendor codebase.

Three things had to be right for that, and each was found by doing it rather than by thinking about it: the pieces are sized for a slow home connection rather than for the size limit (the first attempt died two-fifths of the way through), a piece whose connection is cut is now noticed instead of hanging for ever, and retrying one cannot corrupt the file.

Also: the message shown when a file really is too big used to be a piece of internal shorthand — literally upload.tooBig on screen — and the advice it gave pointed at an address that is closed. Both fixed, in all eight languages.

For the untouched CodeCanyon codebase specifically

• A shop installed with 6amMart's own web installer told its apps no websocket address. That installer rewrites the settings file from scratch and leaves out the three values that say where to connect, and this panel only filled in values that were already there. It now writes them outright.
• Installing from the vendor download was walked end to end for the first time — its own web installer, then this panel's "Finish setup" — and the panel repairs what that installer leaves behind, including a line it writes malformed.

A restore finished green and left the shop down

• Restoring a backup rebuilt the configuration and never told PHP. This server compiles PHP once and never re-reads a file (that is a large part of why it is fast), so the freshly restored configuration sat on disk while every worker went on serving the one it started with. Measured on a fresh install: the restore job reported success at every step, and the admin panel, the API and the storefront all answered 500 until php-fpm was reloaded by hand — on the one job you reach for when things have already gone wrong. Four other places had the same gap: the boot-time repair of your websocket settings, the automatic repair that puts your site back on its normal routes, and turning websockets off and on. All five now hand the result to the running site, and there is a check that will not let a sixth appear.
• One stray file could block every future update. Anything your project's own user ran — an update's dependency install, or a single command typed over SSH — could leave a dot-folder in the app directory, and the update then refused to start with "commit, stash or revert them", which is not something you can do from the panel. Updates now clear those two known folders first.

Your shop could go down the first time you cleared its cache

• The app could not read its own settings file, and nothing said so. On a freshly installed project .env ended up owned by root while your shop runs as its own user. It worked anyway — every page was being served from the cached configuration, which had the database password baked into it. The moment that cache was cleared, by an update or by this panel's own "Clear Laravel's caches" button, every page returned 500 and the error named a database called forge that does not exist on your server. Measured on a fresh install: the shop ran fine for ninety minutes and then went down on a routine update.

Three things changed. The file's owner is now set alongside its permissions, every deploy re-asserts it (so a server already in this state repairs itself the next time you press "Get the latest code"), and the health page has a check that sees it before the cache is cleared rather than after.

The fresh-box round: a server wiped back to a bare Ubuntu, installed with the public install command, then walked all the way through — the first-run wizard, a project, its domain and HTTPS, the 6ammart app, the customer website, backups to cloud storage, email alerts and Cloudflare. Everything below is something that walk found.

Things that would have failed you quietly

• Your panel's own HTTPS certificate never renewed on a server with no project on it yet — which is exactly where a new install sits the moment the wizard finishes. The nightly renewal asked whether any project had a certificate, and the panel's own is not a project. Nothing else would have caught it: Ubuntu's own certbot timer is switched off on these servers. Your panel would have gone to an expired certificate at 90 days with every page still reporting green.
• A private repository for your customer website could not be installed at all. The admin app's install form has a box for an access token; the website form did not, and there was no other way in — the deploy key is only offered for a checkout that already exists. The clone came back with git asking for a username. The box is there now.
• Your restore test reported a shortfall on every server, for ever. Every install carries a starter project with no app in it, and an empty database was counted the same way as a database the test could not check: "PASSED for 1 of the 2 … NOT proved". Empty and untested are different news and now read differently.

Things that told you the wrong thing

• "You skipped the setup steps" appeared on a brand-new server whose owner had just finished all three of them — and it named their password and their address as still waiting. The reminder now only counts the steps the wizard actually walks you through, and it lists the ones genuinely left.
• The Cloudflare page said "not on your plan" about the cache rules, the firewall rules and the rate limit when the only thing wrong was that the shop belongs to another project on the same Cloudflare site. Free has all three. The rows now say "not needed on this site" and the summary line counts them separately.
• A full rate-limiting slot blamed you for it. Free allows one rate limiting rule per Cloudflare site, not per project, so a second shop on the same site found the slot taken — and was told "0 rules of your own are using all of it" and to go and delete them. It now says who is actually holding it, that nginx on your server still limits those addresses, and the two real ways out.
• A full firewall phase answered with Cloudflare's API string — "exceeded the maximum number of rules in the phase http_request_firewall_custom: 6 out of 5" — and left the shop with no Cloudflare firewall rules and no idea why. Same treatment: who filled it, what still protects you, what to do.
• A failed test email said only "timed out after 15s". Most hosts (Linode, Google Cloud, Oracle, AWS, Vultr) block outbound mail ports on a new server until you ask them to open it — measured on a stock server: 25, 465 and 587 all hang while the same provider's 2465 connects at once. The message now says so and names the alternative ports mail providers offer. A mail server that answered and then stalled says that instead.
• server uninstall did not mention the project accounts it leaves behind. It has to leave them — they own the files and databases it deliberately keeps — but a later install checks for them to decide whether a project already exists, so the next "fresh" install behaved differently for reasons nothing had mentioned.
• The origin-lock explanation was missing in all seven translations.

For us

• Building a release that retired a file could not finish at all: the check that refuses to both ship and retire the same path took the whole build down when it found nothing wrong. 1.4.29 was the first release to hit it.

The Cloudflare round. Everything below was found by auditing what SixPanel already does against what Cloudflare actually offers, and checking each finding twice.

Switching something off could break your shop

• The encryption row's off switch would have taken your whole shop down. It set Cloudflare to talk to your server without encryption, and your server answers that by sending the visitor back to the secure address — round and round, for your storefront, your admin panel and all three phone apps. One click, nothing asking if you were sure. Three other rows had the same shape: switching off "0-RTT — off" turned 0-RTT on, switching off "Rocket Loader — off" turned Rocket Loader on, and the cipher row's off switch quietly did the on action and reported success. None of those four has an off switch any more. If you want the panel to stop deciding one of them, press Keep.
• The panel could switch off "I'm under attack" mode while you were under attack. It read the setting as something to correct, and the confirmation you saw said only Set "Security level: medium" to medium. It now leaves it alone and explains what that mode costs — every caller is asked to run a browser check, and your phone apps cannot run one, so ordering stops while your website still looks fine. Every setting now names what it is about to replace.

Your phone apps

• On a paid Cloudflare plan the rate limit would have shown your apps a browser puzzle. The customer, store-owner and rider apps cannot solve one — to them it is a blocked request with no explanation. It blocks on every plan now, which is something an app can understand and retry. Cloudflare would have rejected the old setting anyway, so paid plans were getting nothing.
• The exemption that protects your payment confirmations now also covers Cloudflare's bot protection, which is the part most likely to stop a payment provider's call — those calls come from a machine, which is exactly what bot protection looks for.

Your Cloudflare site may have other websites on it

• The panel's rules used to apply to every website on your Cloudflare account, not just this shop. If you keep a WordPress site on the same domain, setting up the rules here would have blocked its admin area and broken its appearance. The rules now name your shop's addresses, and a new check-up row lists any other website sharing your Cloudflare site.

Not everyone uses Cloudflare

• The Firewall page gave every server the same instructions, written for a server behind Cloudflare — close everything except Cloudflare's addresses. On a server that is not behind Cloudflare, following them takes your shop offline; following only half of them looks fine for about three months and then every HTTPS certificate on the server expires at once. The page now checks each of your addresses and gives the right instructions, and when it cannot tell, it gives the safe ones.
• Files like database dumps and configuration backups are now refused by your server itself, not only at Cloudflare — including the compressed names people actually use, such as .sql.gz.
• A new check-up tells you if your order emails can be forged, which until now you could only find out through the Cloudflare page.

Somebody could run up your SMS bill

• One address in the customer app sends a real text message to any phone number the caller types, and nothing anywhere limited it — not your server, not Cloudflare, not the application. It is limited on both now.

Refuse visitors that skip Cloudflare (new, and off until you turn it on)

• If someone learns your server's address they can go straight to it and skip every protection Cloudflare gives you. Your server can now refuse anyone who does. It stays off until you switch it on, it refuses to switch on if any of your addresses would be cut off by it, certificate renewals and the panel's own checks keep working, and if anything goes wrong you can lift it over SSH with sixpanel origin-lock off even with the panel down.

Smaller things

• Tiered cache is included on the free Cloudflare plan and the panel was telling you to buy Pro for it, while reading a setting your plan cannot change.
• The HTTPS-only setting is now checked properly. A policy lasting five minutes used to be reported as correct.
• Rules and blocks you set by hand in Cloudflare are now listed in the check-up, so a rule nobody remembers is not invisible.
• If you skipped the first-run setup, there is now a Finish setting up button to go back to it. Before, skipping it once was permanent.

• The Deploys page could say your website has no repository while deploying it from one. The website's repository address is recorded at the end of the first install, so an install that was interrupted left it blank forever. The panel now reads it from the checkout itself, which knew all along.

• 1.4.26 fixed the build; the running website service was doing the same thing. systemd also takes the home folder from your project's user, so npm run start recreated .npm/_logs in your app checkout minutes after the deploy had cleaned it. All four per-project background services now use the same dedicated home.

The website build stops leaving files in your app folder

• Building your storefront ran as your project's own user, and that user's home folder is your app checkout — so Next.js wrote its telemetry file to .config/ there and npm wrote its logs to .npm/. Two visible consequences: your Home page reported them as application files that had changed since the last deploy, and the next app update would have refused to run because it saw a modified folder. Builds now use a home of their own, and the next website deploy clears what the old ones left — only those two names, only at the top of the checkout, and only if your code does not track them.

• The cleanup 1.4.24 describes did not actually run: it asked whether the release ships …/deploy.js, and the answer came back yes because that text appears inside …/deploy.jsc. Every stray file looked like a shipped one and nothing was removed, without a word in the log. It now matches whole paths, and a test creates a tree with three strays, a shipped loader and an innocent file and counts what survives.

An update could leave the old panel running under the new version number

• This one is worth reading even though it is short. An update lays the new release over your server without deleting anything, which is exactly right — your settings, your data and your apps have to survive it. But if a plain JavaScript file was ever left beside the panel's compiled code, the panel loads that file instead, and goes on reporting the new version while running the old code. SixPanel now removes those during every install and every update, using the list of files the release actually shipped, so it can only ever remove a stray copy and never one of its own.
• The same trick is the cheapest way for someone to swap out a piece of a protected panel on your server, so the Panel files unchanged since install check now reports it separately and in its own words: not "a file changed" but "this file is being loaded instead of the panel's own".

The hardening round. Everything below was found on a server installed from scratch the way you install one, and fixed and re-measured on the same server.

A shop installed into the wrong database

• This is the one to read. On a server with more than one project, the second project's installation ran against the FIRST project's database. Every step of the job reported success; the project's own database was left empty and its live site read the neighbour's data. The cause is that SixPanel's own settings file names a database, and the application never overrides a setting that is already in the environment it was started in. The rule that keeps those apart existed for the background workers and did not cover the jobs the panel runs itself — which is where a shop is installed. It does now.
• If you have one project, this never affected you. If you have more than one and installed the second recently, open Database for that project and check the name it is using.

Rate limiting

• Adding nine characters to a web address used to skip every rate limit on this server. /index.php/login_submit and /login_submit are the same page to the application and were two different things to the web server, so the tight limit on sign-in — one a second — never applied to the first spelling. Measured: thirty attempts, all thirty admitted. Now six admitted and twenty-four refused, the same as the ordinary address. The Cloudflare rule SixPanel writes was walked past by the same trick.
• Every limit now applies to a visitor's whole address range on IPv6, not to one address. The smallest allocation anybody is given is 18 quintillion addresses. Keyed one at a time, the limits were free to walk around.
• There is a ceiling on the whole server, not just on each visitor. Four requests per PHP worker may be in front of your shop at once; past that the next one is refused in under a millisecond. Without it a handful of visitors staying politely inside their own limit could still fill the queue, and what everybody got then was not a "try again" — it was a broken page, including the customer who made one request.
• A refused request never touches your shop. Nothing here reaches PHP.

Your customer website

• The website could not be built on a 4 GB server while the shop was running. The build asks Node for a memory ceiling, and that ceiling was worked out from free memory alone — so on a normal server it came out around 1 GB and the build died on it, with two and a half gigabytes of swap sitting untouched. SixPanel creates that swap itself during installation. It now counts towards the build, and the same server that could not finish reported a 2,332 MB ceiling and built the site.
• A build that was interrupted used to poison the next one. If a build was cut short — a restart, an update, a reboot — the half-finished dependencies were left behind, and the next deploy saw a folder full of them and skipped the install. The build then failed with code 127 and said nothing useful. SixPanel now checks whether the last install actually finished, not whether it started, and says which of the two it is repairing.
• Pictures on your storefront have their own speed limit. Resizing an image is the single most expensive thing your server does per request, and it runs on the same process that draws your pages. It used to share one limit with everything else. Now a flood of resize requests is pinned at its own rate while ordinary browsing is untouched — measured: 900 requests in 13 seconds from one address, none refused; 2,000 in 12 seconds, held at the limit.
• The web server now keeps its connections to the website open instead of opening a new one for every request. Measured: 200 page loads used to leave 200 spent connections behind and now leave two live ones. Under a flood that is the difference between serving and running out of connection slots.

Cloudflare

• A new check-up row tells you if Cloudflare has added addresses your server does not know about. If that happens, every visitor arriving through those parts of Cloudflare looks like one visitor to your server, and the rate limits start refusing real customers in whichever regions they cover — while everything else looks perfectly normal. SixPanel reads Cloudflare's published list, checks it looks genuine before believing it, and tells you. It never rewrites anything on its own from something it read off the internet.

What can run on your server

• Only one file can run as a program. Your shop has exactly one entry point, in both the CodeCanyon version and ours. The web server used to be willing to run any file ending in .php that existed under your site; now it runs that one and answers "not found" to everything else. The entry point itself is no longer reachable from outside at all.
• Probes for software you do not run are refused by the web server. /wp-admin/, /phpmyadmin, /telescope and a dozen more used to start your whole application and run a database query, once per probe, to build a "not found" page.
• Repeated failed SSH logins are banned — five tries in ten minutes, one hour out. Port 22 is open on every server, and nothing here used to watch it. Server → Health shows how many addresses are banned. On the test server the first ban happened within four hours.
• The server's network settings are sized for a burst of traffic rather than for a general-purpose desktop, and Health reads the live values back so you are told if something else changes one.

Would you know if something changed?

• SixPanel now checks its own files against a list every release carries.
• And your shop's files against what you deployed, which is what a file dropped into your site by somebody else looks like.
• And the settings files it writes for you — about forty of them. Edit one by hand and the panel tells you, instead of quietly writing over it later.
• The background workers now run with the same confinement the web server has. They run your shop's code and had none of it.

The panel's own address

• The door that never closed. Direct access on the server's IP address and port is switched off once the panel has answered on your domain from the internet. On a new server that check ran about forty seconds after the DNS record was created — often a few seconds before the record had finished spreading — so it correctly refused to close the door and told you to try again. Nobody tries again. The panel now keeps checking on its own and closes it the moment your address answers.
• The lock is on the connection, not on what the caller claims. It used to be decided by the hostname in the request, which the caller writes: dialling the IP address and claiming your domain walked past it.
• /healthz answered {"ok":true} to anyone on the internet, from the first line of the code whose whole job is to make this port look closed.

Backups

• A project's backup contained different things depending on which project it was. The first project's backup swept in log files and compiled pages that nothing would ever restore; every other project's contained the uploads and nothing else. Both now contain the same list: the settings file, the database, the uploads, and the keys.
• Those keys are the third thing this found. Both versions of 6amMart keep the key that signs every phone's login in a place the backup was not looking. A restore would have signed out every customer, driver and store owner, and nothing would have said why.
• The database password no longer appears on a command line during a backup or a restore, where any other account on the server could read it.

When something is wrong

• A job interrupted by the panel restarting now says so. It used to end as a bare red "failed" with no reason and no failed step — a backup that stopped on "initialising the repository" with nothing after it. It now says the panel stopped underneath it and that nothing after the last line happened. A job that was still waiting says nothing of it ran and it is safe to repeat.
• The check-up can see whether the rate limits are firing, and tells apart somebody trying passwords from ordinary customers being throttled.
• It reads your shop's own rate limiting too — the CodeCanyon version ships almost none, and that is worth knowing.
• And whether your customer website will re-serve images from any address on the internet. The CodeCanyon storefront is configured to, which turns your server into somebody else's image host.

Smaller things

• The language menu no longer says "(coming soon)" beside seven languages that are finished. It had been asking the wrong question since the panel started loading one language at a time.
• A new server no longer starts on an Indian clock. The timezone defaulted to Asia/Kolkata everywhere in the world, which also put PHP five and a half hours away from the database on a brand-new server. It takes the server's own clock now, and the first-run wizard can move the server's clock with it — which is only safe before a shop exists, and is refused afterwards.
• The wizard remembers that you filled in the welcome step. It used to remember that in your browser, so the same server asked you again on your laptop.
• An upload too large to reach the panel is refused in your browser, with the real limit in the message, instead of by an error page the panel never sees.
• The page header no longer lets the page scroll through it.
• The customer website now answers with the same four security headers the admin panel always has.

Two things the panel could see and never told you about, and one warning it kept raising about a comment.

When something is wrong

• Failed background jobs are now on the check-up. "The queue worker is running" and "the work is getting done" are different things, and until now nothing here could tell them apart: a worker that starts, takes jobs and throws on every one looks perfectly healthy from the outside. What it leaves behind is a list of failed jobs, and each one of those is an order email, a push notification or a payment callback that never happened — with nothing telling you or your customer.
• It measures whether jobs are failing NOW, not whether they ever failed. One failure last month is history and is not counted against your server; anything in the last hour, or five in a day, is a live fault and says so. The wording, the windows and the verdicts are the same ones the settings check-up uses on the same table, so the two can never tell you two different things. Nothing here retries a job for you: re-running a queued payment callback can charge a customer twice, so that stays your decision.
• The panel now reports which dangerous PHP functions are blocked. The settings check-up has been quietly marking this down on every SixPanel server, and nothing in the panel mentioned the setting at all. It does now, including why two names on the usual hardening lists are deliberately left out: they are the same function twice, they block nothing your server was not already able to do, and switching them off breaks the error page you need on the day something goes wrong. Measured, on both 6amMart codebases.

Serving configuration

• "This server is still running an older serving configuration" stopped being raised about a comment. The check compared the whole configuration file character for character, so a single comment line left over from the product being renamed was enough to tell you the improvements in your release were not switched on. It now compares the settings themselves and ignores comments and blank lines. A genuine settings difference is still reported exactly as before.

The settings check-up (SixPreflight)

• It can now see your backups. SixPanel takes the backups on this server itself — a schedule, a repository and an off-server copy that live outside your shop's folder — so the check-up, which looks from inside the shop, found nothing and reported "unknown" while this panel knew the answer to the hour. The panel now writes the state down where the check-up reads it: whether it is scheduled, when the last one finished, whether a test restore has actually passed, and whether a copy exists somewhere that is not this server. All three are reported separately, because they fail separately.
• And it stops claiming your web settings are current when they are not. Three of its rows printed values with "as SixPanel wrote it into nginx.conf" and a green tick, while this panel was reporting the same server as running an older configuration. The panel now hands over that verdict too, so the check-up either confirms the value or says plainly that it could not.
• Update to SixPreflight 1.5.1 on your projects to get both, from the SixPreflight page in the panel.

An update now finishes the job: it removes what a release took away as well as laying down what it added. And the health check-up stopped disagreeing with the server's own supervisor about whether anything had failed.

Updates

• An update deletes the files a release removed. Until now an update only ever added and overwrote, so anything a release took out stayed on your server for as long as the server lived — while a server installed from scratch on the same day did not have it. Two dead brand images shipped in 1.4.20 are the case that showed it. A release now carries the list of what it retired, worked out by comparing the release you are running with the one you are getting, and the update removes each one.
• A file you changed yourself is never deleted. A retired file is removed only while its contents are still exactly what SixPanel wrote. If you edited it, it stays where it is and the update says so. Nothing outside SixPanel's own folder is ever touched — not your sites, not your projects, not your settings, not your backups.

When something is wrong

• The check-up now asks the server's own supervisor. Every other check looks at something SixPanel already knew to look at. This one asks systemd — the part of Ubuntu that starts everything on your server — for its verdict, which is the only question that catches a failure nobody wrote a check for. On a real server, systemd called the machine "degraded" all day while this page said "Healthy overall".
• A failed service that is not ours is still reported, as exactly that. You are told the server reads as degraded, which service it is, and that nothing SixPanel or your shop runs is affected — instead of a green headline that contradicts what you see the moment you log in over SSH.
• The scheduler no longer marks the whole server broken for an application error. A project whose code is deployed but whose 6ammart installation was never finished had its once-a-minute scheduler failing every minute, which put the entire machine into a "degraded" state and sent a failure notice each time. A failed tick is now reported once, where you can act on it — the Scheduler row tells you when the last successful run was — and the details are still in the service log.

Also

• The settings check-up (SixPreflight) on your projects is at 1.5.0, so the numbers SixPanel quotes on the Health page come from the current check set.

Housekeeping after the two-step sign-in: the product's own name in the mail it sends you, an honest answer from two screens that were quietly saying the wrong thing, and the sign-in card sitting exactly where it should.

What you read

• Alert emails say SixPanel. The name on the From line and at the start of every alert subject — a service failed, a login lockout, a repair, a job failure, the disk filling up — still said "6ammart panel". An alert arrives at 3am with a subject and nothing else, so it is the line where the name matters most. The files the panel writes onto your server say SixPanel too, which is what you see when you look at your own web-server configuration.
• The sign-in card no longer shifts by a pixel when the second step is taller than the first. It was pinned already; the pin was rounded to a whole pixel and the card is centred on a half one.

When something is wrong

• A login lock now tells you what locked it. If five wrong six-digit codes locked an address out, sixpanel unlock and the Security page used to show "wrong codes: 0" — the count is cleared when the lock trips, so that the address gets a clean set of tries when the lock lifts. Beside an unrelated wrong password from an hour earlier, the table pointed at the wrong cause at the one moment anyone reads it. It now reports the count that caused the lock, for as long as the lock lasts.
• "Test my backup now" no longer shows five green ticks for a test that tested nothing. When there is no backup it can read — an empty storage, a full disk — the steps it skips now say so instead of finishing green and silent. The result itself was already recorded honestly and the health page already warned; it was the job you watch that looked fine.
• And the advice underneath that warning matches the reason. It used to send you to the Disk page whatever had happened, including when the disk was fine and the storage simply had no database in it yet.

Signing in is now two steps, and a deploy tells you before it signs your customers out.

Signing in

• The 6-digit code has its own page. You type your username and password first; if two-factor login is on, the next page asks for the code alone, says which account is signing in, and gives you one way back. The old form put all three boxes on one page.
• Six digits is enough — there is no button to find. Type or paste the code and it submits itself. Pasting the "123 456" your authenticator app shows, space and all, now works; before, the space was counted as one of the six characters and the last digit was thrown away, so nothing happened.
• A wrong code does not cost you your password. You stay on the code page with the box cleared and ready. Only a wrong password, a locked address or a blocked address sends you back to the first page.
• On a phone, and in your language. The page is drawn for a 390px screen in both themes, and the new wording is translated in all eight panel languages.
• The same protection as before. The code page is not a new door: it is the same sign-in, with the same limits. Five wrong codes within fifteen minutes still lock the address out for thirty, and while it is locked the first page refuses too.

Also in this release

• An update that would sign everyone out now says so first. On a shop that keeps its sessions in the cache, the cache-clearing step of an admin update ends every session on the server — admins, vendors, delivery riders and shoppers, mid-order. That is how Laravel is built, not something on this server, and the panel now reads your shop's own settings and warns before it starts instead of after.
• Build caches can no longer grow without a limit. The space your website's build tools keep between deploys is now capped.
• You can restore one project on a server that runs several. Restoring used to be all-or-nothing. The database it writes into is taken from that project's own settings and checked against them, so a restore cannot land another shop's data on top of a live one.
• The panel can no longer lock itself out through Cloudflare. Its own address was left out of the check that decides the zone's SSL mode, so a server whose shops all held real certificates could switch to a setting that rejected the panel — and the one address that answers with a login started returning an error page.
• The tools that build a release are now pinned by content, not by version. A release is signed, but until now the two programs that produce the signed files were downloaded fresh on every build with nothing checking what arrived. Every one of them, and everything they depend on, is now verified against a recorded hash before it runs.

This release is mostly a name and a logo. The product is called SixPanel — no suffix. The Docker-based sibling is SixPanel Docker, and it carries a different mark, so it is obvious which of the two a server is running. Nothing about how you install or update changes: the install line, the address it comes from and the update button are all exactly what they were.

The name

• "SixPanel Native" is gone from everywhere you can read it. The manual, the installer's own messages, the command-line tool's help and manual page, the header comment on every configuration file the panel writes onto your server, and the description systemd shows for every service it manages (systemctl status sixpanel said "SixPanel (native)" and now says "SixPanel").
• Your install and update commands are unchanged, deliberately. The address installer.allsweb.net/sixpanel-native/ is the one your server already updates from and it stays. /sixpanel/ is a different product. Nothing you have written down or scripted needs editing.

The logo

• The panel now wears the SixPanel mark — on the browser tab, the sign-in card, the sidebar and the setup wizard. It replaces the AllsWeb logo the panel had been showing, which named the company that builds it rather than the product you are running.
• The tab icon is drawn for tab size. A heavier cut of the same mark, because the thin end of the original disappears at the ~18px a browser tab actually renders.
• The name beside the mark is now text, not a picture. It follows your light or dark theme and sits properly next to the version number. On a phone the name steps aside and the mark stands alone, so the row keeps the version, the update badge and every navigation icon.
• The sidebar stopped saying the name twice. The product name used to be printed under the logo because the logo said "AllsWeb"; now that the logo says SixPanel, the line below it carries the version alone.

Also in this release

• Your website records can no longer be switched to "DNS only" by accident. The Cloudflare page drew an on/off switch next to "Orange cloud on your website records". Turning it off published your server's real address for every one of that project's records — the thing the rest of the panel spends its effort hiding. The switch is gone, along with two quieter paths that could freeze a grey record in place; the Fix button, which is the only press that was ever right, stays.
• A record that is already "DNS only" is now reported as something to fix. Every box set up before that rule has them, and the Domain page had been calling them correct. It now says which records are one flag away and offers the change — it does not make it for you, because your customers are already being served through those names.
• Your project settings check-up stops losing points for being hardened. Two things SixPreflight could not see about a SixPanel server — how long the web server will let a request run, and whether the application logs are being rotated — were being answered as "unknown" or, worse, as "no". Both are now reported by the panel, so the score reflects the server you actually have and you are not advised to add a log rule the panel already manages.
• A deploy started by GitHub or from the command line is filed under the right project. Those two paths had no way to say which project they were for, so the run appeared on the default project's Deploys page — or on every project's page — instead of on the one it had just deployed. Nothing deployed wrongly; the history was in the wrong place.

The most important thing in this release: if you run the 6amMart code exactly as it comes from CodeCanyon, the panel could not take you from a zip file to a serving shop. Three separate stops on that one path, plus a websocket setting that named an address the server never used, and a database-clock gap the panel now tells you about instead of quietly widening.

Getting a stock CodeCanyon shop online

• "Automatic install" no longer promises something your code cannot do. The automatic option needs a command that our optimised 6amMart ships and the stock CodeCanyon code does not. The panel offered it anyway — already selected, described as "the panel does everything" — and then failed eight steps into a fourteen-step job, after it had deleted your 190 MB upload and spent six minutes installing dependencies, telling you to start over and pick the other option. It now looks at the code you just uploaded, before any of that, and if the command is not there it finishes with the browser wizard and says so in the log. Nothing is lost and nothing has to be re-uploaded.
• Putting your shop into production mode no longer fails on the shops that need it. The job that turns off the developer settings your code ships with — including the debug page that shows your database password to anyone who triggers an error — cleared the caches first, and one of those caches lives in a database table that stock 6amMart does not create until it is installed. So on a shop between "uploaded" and "wizard finished", the job wrote the fix correctly, then went red without ever loading it. It now finishes, and says which cache it could not clear and why. A genuine failure is still a failure.
• Your visitors keep the "coming soon" page until your website can actually show them something. The friendly holding page appeared whenever nothing was answering on your website's port — so the moment the website service started, it went away, even if every page it produced was an error. Building your website before installing your shop did exactly that: every page asks the shop for its settings, the shop is not there yet, and visitors got a bare error page instead. The panel now checks that your website really serves a page before it calls the deploy done, and if it cannot, it stops it again so visitors keep the "coming soon" page — and tells you which of the two reasons it was.

Live order tracking

• The websocket settings written into your app now match what actually runs. Every project's settings file said the live-updates server listens on all network addresses, on port 9006. On this server it listens on the local address only, on a port allocated per project — so on a server with more than one shop, the file named the wrong port as well as the wrong address. Nothing was affected while the panel ran it, because the panel passes the real values directly. It mattered the moment anyone started that server by hand to look at a problem: it would then have opened a public port, unencrypted, that no certificate covers and nothing else on the server points at. Existing servers are corrected automatically on update.

Your database's clock

• The Database page now tells you that your database and your shop disagree about what time it is. They do, on every server: your shop runs on the timezone set in your 6amMart admin panel, and the database runs on the server's own clock. Almost nothing is affected — your shop writes and reads its own dates with the same clock — but a small number of columns are filled in by the database itself, and one of them is what "trending searches" reads. On a shop east of about +05:30 that six-hour window works out at nearly zero, so trending search quietly shows random categories instead. The new card names the exact columns on your database, what the gap costs, and — deliberately — offers no button, because changing the database's timezone would silently re-label every date you have already stored. An order placed at 21:28 on the 29th would start reading as 02:58 on the 30th, every daily report would move with it, and nothing would look broken.
• The timezone step no longer tells you the database will catch up on its own. It said so, and it was not true on this server — that sentence dated from the Docker version of SixPanel, where it was.

Found by an independent check of 1.4.16

• A file inside an uploaded zip can no longer publish something it does not contain. A shortcut entry in a deploy archive was being restored and then followed by the web server, so one entry could serve any file the web server can read at an address on your own shop's domain. Deploy archives are now refused if they contain one.
• Nothing was rotating your application's log file. On an idle demo shop it reached 41 MB in five days. Every project's Laravel log is now rotated daily and compressed, including projects created later.
• The disk breakdown adds up. It accounted for 4.79 GiB of 21.17 GiB used, counted your uploads twice, named only one of two storefronts, and never mentioned the 5.34 GiB build cache or the 2 GiB swap file our own installer created. It now covers the disk, and offers the large reclaimable items.
• "This backup can be restored" now means all of it was checked. The restore test proved one of the three things it reported on.
• Health, services and the file manager say what they actually did. Stopping PHP on one project's card stopped PHP for every project on the server; an action on a shared service reported itself as project-scoped; the file manager created entries owned by root inside project folders; the health page claimed a completeness it did not have; and doctor ignored which project you asked about while other commands exited with an error and no message.

The most important thing in this release: deploying your code, and rolling it back, did not change what your visitors saw. Found by an independent check of 1.4.15, along with three smaller things.

• Your deploy now actually reaches your website. PHP is told, for speed, to never re-read a file it has already loaded — which means the only thing that makes new code run is restarting PHP, and the deploy did not do it. So Deploy pulled your new code, ran your database changes, rebuilt the caches and restarted the background workers, and your site carried on serving the old code. Your queue worker and your website were running two different versions of your shop. Measured on our test server: a file changed on disk kept serving its previous contents on every request, indefinitely, until PHP was restarted. The same was true of rolling back — the thing you reach for when a deploy has broken your shop — which quietly did nothing to what visitors saw. And of activating your CodeCanyon licence: the panel wrote the activation, said it had worked, recorded it in your activity trail, and your admin panel stayed locked, because the running site never re-read the file. Uploading a zip was the one path that already did this correctly; now all of them do. If activation cannot restart PHP it now tells you so instead of claiming success.
• After an update, the panel tells you its real address again. On a server whose panel has its own domain, direct address-and-port access is switched off — and the closing lines of an update printed the address-and-port URL anyway, told you to open a firewall port you do not need, and warned about a certificate warning you will never see. Following it looked like the update had broken your panel. It now prints the domain you actually use.
• German, Spanish and Portuguese now say what a button will do. Three of the lines that appear before an action — "your project AND this panel go offline for 60 to 90 seconds, no orders are lost", and the two like it — had been reduced to bare labels in those three languages: "Server restart". So the warning and the reassurance were both missing at the moment you needed them. Arabic, Bengali, French and Indonesian already had the full sentence.
• Your server's files belong to your server again. Every file SixPanel installs was arriving owned by a user account from the machine the release is built on — a user that does not exist on your server — including SixPanel's own command line and installer. Nothing could be written by anyone who could not already write anything, so nothing was at risk; it was simply wrong, and it is corrected on updating servers as well as new ones.

One release, one subject: the thing that installs an update is now checked before it is allowed to run, and nothing can quietly change which key your server trusts.

• Your server now verifies the installer itself, not just the release. Every SixPanel release is signed, and your server checks that signature against a key it pinned when SixPanel was installed. But the small script that fetches and unpacks a release — the installer — was fetched over the network and run as root without being checked at all. It was trusted because it arrived over an encrypted connection, and an encrypted connection only proves who you are talking to, not that what they said is genuine. Signing exists for the day the download service itself cannot be trusted, and this was the one step it did not cover. The signed release record already carried the installer's fingerprint; your server now reads that record first, checks the installer against it, and refuses to run anything that does not match — printing both fingerprints so it can be reported.
• Nothing can replace your server's pinned key except a proper replacement. The installer used to overwrite that key with whichever one it happened to carry, every single time it ran. That meant anyone able to serve you a modified installer could hand your server a release signed with a key of their own and leave that key in place, so that nothing afterwards would ever object. Now the key on your server wins: a release is checked against it, and it is only ever replaced by a new key that arrives signed by the key being replaced. A first install has no key yet and still works exactly as before.
• An installer you saved a while ago still works. As a side effect of the above, an older copy of the install command no longer refuses to run after we replace a signing key — your server's own key is what decides, so the release still verifies. It tells you the copy is out of date rather than stopping.
• A first install no longer reports failure after succeeding. In one narrow case the installer's very last line could end a completely successful install with an error and advise a retry that was not needed.

One thing worth saying plainly: if your server is on 1.4.14 or earlier, it will take this update through the old, unchecked path — that is unavoidable, because the check ships inside the update it is checking. From 1.4.15 onward every update your server applies is verified before it runs.

A short release, carrying four fixes that missed 1.4.13 by minutes plus the one thing that could not be done in the field at all.

• The "restore everything" button on the Backups page could not be pressed. If you had visited one of your projects earlier in the session, the Backups page remembered it and sent the restore to that project instead of to the server — and per-project restore is not built yet, so it refused. The only way to find out was to type RESTORE into a red confirmation box and watch it fail. The button now does what it says. The dialog also tells you, before you confirm, what a restore actually puts back: a backup holds every project on the server, and restore puts back the main one. On a server with more than one project it says so, in all seven languages.
• The dashboard's app-error headline was blank. The card said "errors in the last 24 hours" and then showed nothing, on a server whose health check was counting eleven. The number was being dropped on its way to the page. It is the fix in this release most worth glancing at after you update: open the dashboard and the error card should show a real count, or a zero.
• Uninstalling SixPanel left services running. The uninstaller counted a service template — a blueprint, not a running thing — as a service it had switched off, and stopped short. Measured on our test server: it was reaching 31 of the 36 things it should have, and the five it missed included a database cache per shop and two services for a project nobody had opened since the machine last booted.
• Five phrases showed in English in every other language. They had been filled in with the English text so that nothing was missing, which is the right thing for a check and the wrong thing to ship — including the dashboard error card, which had been translated and went back to English. All seven languages have them properly now.
• The replacement of our release signing key can now actually happen. Every update your server accepts is checked against a key pinned when SixPanel was installed, and a key that can never be replaced is a key you are stuck with. Replacing one requires the new key to arrive signed by the old one, and three separate pieces of that were missing — the download service had no address for the signature, never published it, and the sixpanel server update --check command had no notion of a replacement at all, so it would have reported a perfectly good server as tampered with. All three are fixed and the whole path is now tested end to end against a throwaway key. Nothing changes for you: your server still refuses any release that is not signed by the key it already trusts, and it will only ever accept a new key that the old one has vouched for. Neither we nor anyone who took over the download service can hand your server a key it did not already have a reason to trust.
• Your website build no longer runs with a "continuous integration" switch set. It had been added to make build logs quieter, which is not what it does — it changes how the build tools themselves behave. Measured on the same project with nothing else different: with the switch on, a build missing part of its toolchain stops instead of repairing itself, and the build prints one extra advisory line rather than fewer. Nothing in 1.4.13 was harmed by it, and it is gone because a flag whose effects were not known has no business in the step that builds your shop.

If you run the 6amMart code exactly as it came from CodeCanyon, this release is the one that matters. Four things were broken specifically for you and worked only for people running our modified version of the code. SixPanel had never been tested against a plain CodeCanyon shop end to end; now it has.

• Your admin panel was locked and SixPanel never mentioned it. 6amMart checks its CodeCanyon licence before it will show any admin page. Signing in worked — and then every single admin page bounced straight back to an activation form, on a shop SixPanel had just reported as successfully installed. SixPanel now asks for your CodeCanyon purchase code and completes the activation for you, from the Deploys page. It says plainly what happened: activated, refused (with the address it was refused for), or "the licence server did not answer, so 6ammart has let you in for now and will check again within a day". Your code is kept on your own server, in a root-only file outside the app, so you can re-activate in one click when you move the shop to a new address — it never appears in a log, in the activity trail or in any page the panel serves. Your storefront is licensed separately by 6ammart, and if that one is not activated your shop's home page loads and shows nothing; the same screen activates it. Two smaller things went with it: activating a shop, or turning a module on in the admin panel, used to make SixPanel refuse every future update ("local changes present"), and an update or a rollback could throw the activation away and lock you out again. Both files are now kept safe across updates, rollbacks and zip uploads.
• Your storefront could only be installed from a git repository — and you have a zip. There was no way to get the customer website onto your server from the CodeCanyon download at all, so its address answered "502 Bad Gateway" forever. You can now upload the website zip on the Deploys page, and a newer zip later the same way. Upload the whole download if you like: it contains the site and a "changed files" folder next to it, and the panel takes the complete one and says which it skipped. Everything is built on your own server — there is nothing to build on your computer. And while the storefront is not there yet, its address no longer shows a bare error: it serves a short page saying the shop is not open yet and where to go next, which disappears by itself the moment the site starts.
• Your shop was running in the developer mode 6ammart ships with. The settings file that comes with the code is meant for a programmer's laptop, and SixPanel copied it as-is. On a real shop that printed the login page's security-code answer into the page for anyone to read, turned off certificate checking in one payment gateway, and — because of a mistake in 6ammart's own installer — put your payments on your gateways' TEST credentials while everything looked normal. A debug error page could also show your database password to whoever triggered it. New installs are now set up for production from the start. If your shop is already installed, open App .env: a banner at the top lists exactly what is wrong and fixes it in one click.
• Every add-on module's styling and buttons were missing. 6ammart's pages ask for their modules' stylesheets and scripts at an address that only works on the folder layout shared hosting uses. SixPanel serves your site the safer way, which put those files out of reach — so on a plain CodeCanyon shop every admin page was missing a stylesheet, and module screens lost their buttons and icons. They are now linked into place for whatever modules you have, including one you turn on later, and nothing else in the module folders becomes reachable. Updating applies this by itself the next time the panel starts.

Read this one. Several of the fixes below are about things that were quietly wrong on every server rather than visibly broken on any of them, and the first one needs a minute of your time after you update.

• Your backups did not contain your database. Take a fresh one after you update. SixPanel dumps your database, hands the dump to the backup tool, and tells the tool to skip the folder the dump is written into — a folder that also holds half-finished uploads and the scratch space a restore works in. The "skip" applied to the dump as well, so the backup tool stored the folder and nothing in it. Every snapshot still held your uploads, your settings, your web server configuration and your certificates, and the Backups page still said the backup had finished and told you how large the repository was. Measured on our own test server: six snapshots, one of them a database-only backup, 10,888 files each, and not one database among them. The dumps now live somewhere the skip cannot reach, and a check that holds the two lists against each other runs before every release, so this cannot come back silently. After updating, open Backups and press "Back up now", then press "Test my backup now" and read the result. The test is the part that matters: it loads the newest backup into a temporary copy of your database, counts the rows and deletes it again, and it is what found this.
• Your customer website was reachable on a plain, unencrypted port. The storefront listens on a port that only SixPanel's web server is supposed to reach, and it was accepting connections from anywhere instead. Anyone who knew your server's address and tried that port got your shop over plain HTTP — around the certificate, around the request limits, around the page cache and around the security headers. Nothing needed that; every part of SixPanel that talks to the storefront talks to it over the machine's internal address, which is what the install log has always said it was doing. It now listens only there. The update applies this by itself the next time the panel starts; you do not need to do anything.
• The file manager's "Compress" button never worked. The tool it runs was not among the packages SixPanel installs, so it failed with a line of programmer's shorthand. The package is installed now, on updating servers as well as new ones.
• A non-English panel opened in English. The first page load of every new browser session put the whole panel into English while keeping your own language's layout around it — right-to-left for Arabic, with English words inside it. Reloading fixed it, which is why it survived this long. Measured on clean browser profiles: 8 of 12 first loads were wrong before, 0 of 14 after. Three pieces of copy that had drifted are fixed with it, including a Spanish confirmation box that said the whole server would restart when the English one says your shop stays open, and a German backup schedule that showed times that were not the ones being used. The backup-password card no longer changes language halfway down.
• The optional "www" address a new project offers now uses the right hostname. On a Cloudflare domain the panel shortens names so they can stay proxied, and the create form was not doing the same shortening as the server. The result was a www address that had a certificate but no DNS record, and a DNS record with no certificate — so anyone typing it got an SSL error, and nothing anywhere reported a problem.
• The disk is described the same way everywhere. The dashboard, Server → Health and Server → Resources were giving three different answers for one disk, and the headline on Resources overstated free space by 4 GB. They now all use the same measurement. The "Database files" row was also missing from "where the space goes" entirely — it was being measured at a path from the Docker version of SixPanel — so on a 15 GB-used server the breakdown accounted for less than 4 GB and did not say the rest was unmeasured.
• The dashboard's app-error count is shown again, and labelled with what it actually counts. It was reading a field the server does not send, so the chip never appeared at all.

• "Check this server" no longer reports a failure you cannot fix. A project you have created but not yet installed an app into has a queue worker that correctly does nothing, and sixpanel doctor was calling that a failed service and telling you to start it — which could not work, because there is nothing to start until the app is there. It now says the project is waiting for its app, and sixpanel status says so too instead of reporting the worker as dead.

The panel and the installer now size your server the same way. They were supposed to already — both were written from the same measurements, and each carried a note saying to keep them matching. They did not match. Running both across 36 combinations of server size and project count produced 66 different answers.

• Settings → Auto-tune was offering changes your server did not need. On a server with one shop it always offered to change the database's open-table cache, whatever the server was already running. On a server with several shops it offered two or three times as many PHP workers as the install had chosen. And on a server with 10 GB of memory or more it offered to shrink the database's transaction log — a setting the installer had deliberately sized larger, and one that SixPreflight, our own server grader, would then have marked down. All three are gone: the suggested column is now the same calculation the installer used, so on a server whose hardware has not changed it says there is nothing to do.
• The PHP worker count on a multi-project server was settled by measuring it. The panel's reasoning was that a shop that is busy while its neighbours are idle should be allowed to use the whole machine. On a two-processor server with three shops, giving the busy one 16 workers instead of 4 served no more requests per second at all, made the slowest one page in a hundred 57% slower, and used 193 MB more memory. Four workers already keep two processors busy; the rest only take turns. The install's answer was right and the panel now agrees with it.
• The database's open-table cache on a single-shop server goes from 2048 to 4096. The generated tuning file was writing a smaller number than the baseline file SixPanel ships alongside it, and the generated one wins. This is the one setting that changes on a server that is already running; it costs about 2 MB and is applied by the normal update, which checks the file before the database is asked to use it and restarts the database only because a number really changed.
• Two database settings are now recorded where you can see them. The log buffer and the open-table cache were calculated and written into the database's configuration but never written into the server's settings file, so they were the only two the panel had to guess at when it showed you "current", and the only two a re-install could quietly lower.
• "Queue workers" is gone from the tuning table. It was left over from the Docker version of SixPanel, where it decided how many queue containers ran. Here each shop's queue is a single service and nothing on the server reads that setting, so the row offered a change that only ever edited a line in a file.
• If a tuning change would lower something, the job now says so first. The installer only ever raises these numbers, so anything the panel lowers stays lowered — worth knowing before you press the button, not after.
• Nothing else moves on a server that is already running. The PHP workers, database memory, transaction log, cache budget and listing budget your server was set up with are all kept as they are.

Updating now gives you the whole release. Until this version an update delivered the new panel and a small part of everything else. Three releases in a row shipped work that only a freshly installed server ever received, and each one was found by accident rather than by a test. This release closes the whole class and adds a check that refuses to build a release which reopens it.

• The sixpanel command line was never updated on a server installed from the published link. Not "sometimes" — never, on any of them, for as many releases as the server lived. The update looked for the installer in a place that kind of install does not have, decided there was nothing to run, and wrote a line in the log saying the command line was behind. It matters because the rescue commands — reset a password, reset the entry code, turn off two-factor, clear the allowlist, unlock — are all command-line commands, and they are what you reach for when the panel itself will not let you in. Now the command line is replaced during the update, and by the version being installed rather than the one after it.
• sixpanel version was reporting a number that was not the command line's. It read the version of the folder it points at, so a command line several releases old still printed the current number and the "these do not match" warning could never appear. It now reports its own, and says "unknown" rather than guessing.
• Your server's settings are brought up to this release too. An update now applies the web-server and PHP settings, the database tuning and its sizing numbers, the pool your site's PHP runs in, the shared location rules every site includes, the failure alerting, the panel's own service definition and the server-level tuning — all of which previously only ever arrived on a fresh install. A server that has been updated for months and one installed today now end up the same.
• It is careful about it. Anything a service has to read is checked before that service is asked to use it — the web-server config and the shared location rules are validated together and put back together if either is bad, and the database config is parsed before the database is restarted. The database is restarted only if something actually changed, so an update that changes nothing for it no longer costs you a database restart.
• An update will not upgrade software you already have. It installs only a package this release newly needs and your server is missing. Nothing already installed is touched, so an update cannot restart your web server or database for a reason the release did not ask for. It also never rewrites your database passwords.
• The old certbot renewal timer is switched off on servers that only ever updated. SixPanel has been the single certificate-renewal driver since 1.4.0, but the step that turns the distribution's own timer off ran only on a fresh install, so updated servers had both running.

Two rough edges on the cache work from 1.4.7, both found by driving the panel in a real browser rather than by reading the code.

• Services & Logs drew the cache row as "not created". The page asked for a row per project cache and the server never filled it in, so a running cache looked like one that had never been made — with a Start button that would have done nothing. It now shows its real state, with Live logs, Start, Restart and Stop, per project.
• The server dashboard stopped calling the cache a shared service. Its status strip listed one dot for "redis" alongside the web server and the database. There is no server-wide cache any more, so that dot was reporting the first project's private one as if it spoke for the whole machine.
• Stopping a project's cache now sticks. Stop it on Services & Logs and it stays stopped — through a panel restart, through an update, through an installer re-run — exactly like that project's queue worker and websocket service already did. A brand-new project still gets its cache turned on for it; nobody has to remember to.

Two things 1.4.7 left half-finished, found by updating a real server with it and then reading the server instead of the release notes.

• The old shared cache service was left running on servers that had nothing to move. 1.4.7 stopped it only where it actually copied something across — so a server with no shop installed yet, or one already updated, kept an unused cache service running forever, and a freshly installed server and an updated one did not end up in the same state. It is now stopped whenever nothing on the server is pointed at it, and left alone the moment anything still is.
• The product-listing memory limit did not come down on servers that were updated. The corrected limit was written by the installer's sizing step, and an update does not run that step — so a two-shop server updated to 1.4.7 was still carrying 117 MB of listing budget inside a 78 MB cache, which is the exact number 1.4.7 set out to fix. The update now lowers it, in the server's settings and in each shop's own settings file, and never raises it.

If you run more than one project on this server, update now. Your shops shared one cache, and sharing a cache turned out to mean sharing secrets.

• One project could read — and change — every other project's cache. All the shops on a server used one cache service behind one password, and that password has to sit inside each shop's own settings file for its own site to work. So anybody with access to one shop had the key to all of them. Measured on a real two-project server, starting from nothing but one project's Linux account: the other shop's mail password, Firebase credentials, Google Maps keys, SMS gateway key, reCAPTCHA secret and two payment gateways' secret keys were all readable, along with everyone's signed-in sessions — and writing was allowed too, which means the other shop's saved mail settings could have been replaced.
• Every project now has its own cache service. It listens on a file inside a folder only that project's Linux user may open, so another project is refused by the operating system before it can even offer a password — and it has its own password as well. Re-run on the same server afterwards, every attempt was refused, in both directions, even when the test was handed the target's real password on purpose.
• Updating does the move for you, and it is not disruptive. Your cache is copied across before the switch, so nothing starts cold, and nobody is signed out — verified on a live shop by holding a real browser session open right through the update. On the server this was measured on, 46 cache entries moved in 14 milliseconds.
• The cache no longer empties itself when you update 6ammart. 6ammart's own "update the software" step rewrites a setting the cache keys were built from, which quietly threw away the whole cache and signed everyone out every time it ran. The panel owns those key names now, so that stops happening.
• The memory limit is now per project, and the panel divides it for you. The server has one cache memory budget — six per cent of its RAM. Adding a project divides it instead of multiplying it, so a shop's cache can never promise memory the machine does not have; removing a project hands the share back. It is applied without restarting anything. On a 4 GB server that is 245 MB for one project or 81 MB each for three.
• A related limit was set wrong and is now right. The share of the cache the product-listing cache may use was allowed to be larger than the cache it has to fit inside — on a three-shop server, 64 MB of listings inside a 78 MB cache — which defeated the whole point of capping it: stopping a flood of search results from evicting people's logins.
• "Restart the cache" now restarts only yours. Services & Logs, Health, the dashboard, the command line and the automatic self-healing all speak of a project's own cache. Before, one shop's cache going quiet made the panel restart the cache for every shop on the server.
• The fifteen-project ceiling is gone. Projects used to be handed one of sixteen numbered slots in the shared cache, and the sixteenth project was refused. There are no slots any more.
• Nothing changes for the plain CodeCanyon 6ammart code, which keeps its cache in the database and its sessions in files. Measured rather than assumed: with that project's cache service stopped entirely, its pages answered in exactly the same time.

If you run more than one project on this server, update now. One fix, and one answer to a question about upload sizes.

• A project's background services were talking to the FIRST project's database. Every project has its own queue worker, scheduler and websocket service. Those three were being started with the first project's database name, user and password already in their environment — and the framework 6ammart is built on never lets a project's own settings file override something already set that way. So on a server with two or more projects, the second project's queued work (emails, notifications, exports, scheduled tasks) was reading and writing the FIRST project's data, and its own queue never ran at all. Measured on a two-project server before the fix: a job put in the first project's queue was picked up and run by the second project's worker, and the second project's own jobs sat untouched. After it, each project's worker answers with its own database, works only its own jobs, and leaves the other project's alone.
• It hit the plain CodeCanyon 6ammart code hardest — which is what most people run. Our optimised build caches its settings at deploy time and so never re-read the wrong ones; the unmodified code cannot cache them (that would kill live order tracking) and so read them on every single start. If you have been running more than one project, it is worth looking at the first project's failed jobs after updating.
• Nothing to do by hand. Updating applies it, and the panel restarts only the services whose definition actually changed. No data is touched, and the first project on a single-project server behaves exactly as it did before.
• The panel's own passwords are no longer handed to your shops. The same environment carried SixPanel's admin password and the database root password into every project's background services, where any queued job could read them. They are gone from there.
• "My image will not upload" now has a real answer. A report said the server was silently dropping anything over a couple of megabytes. It is not: measured on a live install, a 50 MB upload reaches the application intact, and the same is true on the unmodified CodeCanyon code. The ceiling is 6ammart's own rule — 2 MB as it ships from CodeCanyon, 5 MB on our optimised build — and no web-server or PHP setting moves it. The Troubleshooting page now says exactly that, with the one command that reads the number off your own server. Nothing about the serving stack was changed, because there was nothing there to change.

A second wall around your shops' PHP. Nothing to do, nothing gets slower.

• PHP can no longer read its way around your server. Until now, if something got into one of your shops — through a plugin, a theme, an upload — it could not touch any other shop's files, but it could still read a lot about the machine: the settings SixPanel writes for every site on it — which is the list of every domain on this server — SixPanel's own program files, the shared temporary folder with whatever other programs had left in it, and the command line of every other program running. No passwords were ever among them, but it is a map, and it was free to take. From this release PHP starts inside its own view of the server where the whole disk is read-only except the folders your shops actually write to, those files are simply not there, and its temporary folder is its own.
• And it costs nothing. The usual way to do this is a PHP setting called open_basedir, which some other panels use. It was measured on this exact application first: it makes every request 17 to 23 milliseconds slower, forever, because PHP stops remembering where files are and looks them up again on every include. The way SixPanel does it is set up once when PHP starts, so the measurements before and after are the same to within the normal run-to-run wobble.
• New shops are covered the moment they are created, including ones added months after the server was set up — proven by creating a shop after the change was live and watching it write. If you have moved a folder onto a second disk by hand, the Troubleshooting page has the one command that tells SixPanel to look again.
• phpMyAdmin, uploads, invoices, exports, queued jobs and logins all keep working. Each was exercised rather than assumed: a real image uploaded through the admin panel and fetched back from the site, a log line written from a live request, a queued job dispatched from the web and worked off, a cache rebuild, and a login followed by an authenticated page.
• Health has a new row that can see what the old one could not. "Storage folder writable" asks the question from a command line, which is outside the confinement — so it can say "writable" while the PHP serving your site is looking at the same folder read-only. The new row compares what PHP is actually running with against what this server needs, so if an update ever lands without being switched on, the panel says so instead of you finding out through a failed upload.
• What deliberately stays readable: the machine's user list, PHP's own pool directory, and this server's nginx configuration. Linux needs the first to turn a user id into a name, PHP needs the second to know what to run, and SixPreflight reads the third to report your upload limit and compression settings. None of them holds anything private, and all three are read-only.

A correctness fix in the response cache. Update this one.

• Shops with more than one delivery zone could be shown another zone's modules. The list of modules your app asks for changes depending on which zone the customer is in — and the server's cache was not treating those as different questions. So a customer in one zone could be handed the answer built for another: the wrong service list, briefly, until the entry expired five seconds later. Fixed, and proved with a before-and-after: the same request in two zones now keeps two separate answers where it previously returned one zone's bytes for both. This affected signed-out visitors as well, and it was there before the cache was widened in 1.4.2.
• Two pages were removed from the shared-response list. One of them changes its answer depending on filters the cache was not looking at. Neither was actually being cached, so nothing gets slower — but they should never have been on the list, and now they cannot be.
• The safety check is no longer something someone has to remember. A page can only be served from one customer to another if it provably returns the same bytes to everyone, and a release now refuses to build if that is not demonstrably true — checked against both the untouched 6amMart code and our optimised version, so a future 6amtech update that makes a page personal stops the release instead of quietly leaking.
• All 26 remaining shared pages were re-checked by fetching each one as two different signed-in customers and requiring identical bytes, including six that previously had no data behind them to compare.

Update this one even if you skipped 1.4.2 — it is what makes 1.4.2 real.

• Updates now switch on the settings they bring. A SixPanel update carries improvements to how your server serves pages, and until now those arrived on disk and were never applied: the server kept running the settings written the day it was first installed. So an update could report success, show the new version, and change nothing about your shop's speed. Updates now apply them, checking the new settings before switching over and putting the old ones back if anything is wrong — without dropping a single request.
• The panel now tells you when your server is behind its own build. Because an update is run by the version you already have, a server updating from an older release still has to be brought forward once. Health checks now say so plainly and give you the one command that does it, instead of leaving the improvements switched off and silent.

A speed release, and everything in it was measured on a real shop with 66,701 orders before it was shipped.

• The app is dramatically faster for customers who are signed in. Until now the server's response cache only helped visitors who were not logged in — the moment someone signs in, their phone sends a token with every call, and the cache stopped helping them. That was backwards: signed-in customers are the ones using your shop. The settings call every app makes on launch now answers in 0.6 ms instead of 16.9 ms, and 27 other pages — your terms, privacy policy, refund policy, zone and module lists, banners — are served the same way instead of being rebuilt for every single request. Anything that genuinely differs per customer is still built fresh for them, every time; that boundary is checked by a test that fetches each page as two different customers and refuses to ship if the answers differ.
• A way to knock your shop's cache out has been closed. Anyone could send requests with made-up location headers and push everything useful out of the cache, putting the load straight back on your database — a few thousand requests were enough, and nothing in the rate limits stopped it. A page is now only cached once it has genuinely been asked for twice, which costs nothing and makes the trick pointless.
• PHP's just-in-time compiler is on where the server has the memory for it, worth about 6% across the board. It was off pending a measurement; the measurement is now five paired runs on a real dataset.
• Servers with less than 2 GB of memory keep the compiler off — there the memory is worth more than the speed.

A correctness release. Nothing here changes what SixPanel does; it changes what it tells you, in four places where the panel was saying something the code did not back up — and it ships the manual, which 1.4.0 promised and did not carry.

• The customer manual now ships. 1.4.0's package carried an empty documentation folder, so every Help link in the panel quietly hid itself rather than opening a page. All 24 pages are in this release, readable in the panel and over SSH, and a release can no longer be built without them.
• Bot fight mode is now your choice, not a recommendation. Cloudflare cannot aim it at part of your site — not from this panel, and not with a rule you add yourself — so it also sees the calls your customer, store and rider apps make, and the call your payment provider makes to confirm a paid order. Those callers cannot answer the challenge it sends. "Set this up for me" no longer switches it on; the page explains what it would cost and leaves the decision to you.
• Your panel's own address is protected like everything else. It was being left out of the orange-cloud check, on a reason that stopped being true when the live job log started sending a keepalive. The one address on your server that answers with a login is now covered by the same rule as your shop.
• Alerts: the settings page names the address that actually receives them. It used to show your account address, which is not where alerts are sent — so changing it did nothing. It now shows the real recipients.
• The firewall page stops guessing about port 80. It warned every owner that closing port 80 would expire every certificate on the server in about 90 days. If your certificates renew through Cloudflare's DNS, that is simply not true. The page now reads your own certificates and tells you which case you are in.
• Setting up a dedicated address for live updates no longer asks you to create a DNS record by hand — the panel makes it for you, always behind Cloudflare's proxy.

The first no-Docker SixPanel release. SixPanel runs 6amMart directly on Ubuntu 24.04 — nginx, PHP-FPM 8.3, MariaDB 10.11, Redis and Node from the distribution archive, managed by systemd. There are no containers anywhere in the running stack, which is what makes it fast on a small VPS: nothing is virtualised, nothing is proxied through a container network, and the database talks to PHP over a unix socket.

• Several shops on one server. Each project gets its own unix user, its own PHP-FPM pool, its own database, its own queue worker, scheduler and websocket server, and its own hostnames. One project cannot read another's files.
• Domains and HTTPS without the guesswork. Type your domain and the panel plans the rest: it creates the DNS records on Cloudflare (always proxied, so your server's address is never published), issues real Let's Encrypt certificates — through DNS-01 when Cloudflare is connected, so it works even with the orange cloud on — writes the nginx configuration and renews daily.
• Install and update your shop from the panel. Install from git or from a zip, see exactly what a update would change before it runs, one-click rollback, and optional push-to-deploy.
• Backups you can actually restore. Encrypted snapshots to this server, S3 or SFTP, a scheduled test-restore that proves they work, and the backup password is yours to see, change and copy out at any time.
• The panel tells you when something is wrong. Health checks that ask the app whether it really answers, watch certificates, disk, queue and scheduler, and email you when something breaks — plus SixPreflight, the deeper check-up of the shop's own settings.
• Your panel, your address. Serve the panel on your own domain with its own certificate; direct IP access switches itself off once the domain works.

The three entries below are this product's own earlier development milestones: internal builds used in testing, never served to anyone and not installable now. Their dates say when the work happened and nothing more. SixPanel Docker is a separate product line with its own changelog and its own numbering; nothing in this file refers to it.

Development milestone, in testing only. The last of the pre-release rounds: the product was far enough along to be driven end to end on real servers rather than reasoned about, and what remained was proving it behaved the same way twice. This build was never published and nobody received it.

Development milestone, in testing only. The middle of the work, where the parts began to be tested together rather than one at a time. This build was never published and nobody received it.

Development milestone, in testing only. Early development: the shape of the product being settled and the first pieces made to run. This build was never published and nobody received it.