SixPanel release notes

A security fix, and a version check before an install. If you run any earlier version, take this one.

• New: SixPanel now checks your 6amMart version before it installs or updates. SixPanel supports 6amMart 4.0 and newer. Older code is a different application underneath — a different Laravel, a different websocket package, and a different set of database tables — so the panel now stops and tells you, instead of spending six minutes installing something it cannot run properly. Nothing on your server is changed when it stops: on a zip upload the check runs on the uploaded file before anything is written to your site, and on a git deploy it runs on the pushed code before it is merged, so a live shop keeps serving exactly what it was serving.

• New: your project's card now shows which script and which version it runs — for example "6amMart 4.1" — so you can see at a glance what is on each project.

• Where the version comes from, and why your admin footer may disagree. SixPanel reads it from your code, in app/Http/Controllers/InstallController.php, because that is the line 6amMart's own installer writes. It deliberately does not trust .env: a fresh 6amMart download ships an .env left over from the previous release, so a genuine 4.1 download says SOFTWARE_VERSION=3.9 in that file — and that is the value your 6amMart admin footer shows you. When the two disagree, SixPanel is reading the reliable one.

• Fixed: opening the panel in several tabs after a quiet spell made it slow. Each reader started its own full health sweep — about forty live checks, including a scan of your app's files and a PHP start-up — so three tabs meant three of everything at once, and each one made the others slower. Every reader now shares one sweep. Measured on a two-core server under full load: a sweep that took 11.8 seconds now takes 4.3.

• Fixed: on a very busy server the Health tab could come back with no rows at all. The page gives itself ten seconds and answers empty if it runs over, and a slow check could push it past that — hiding the very row that would have named the problem. Checks now stop waiting while there is still time to draw the page.

• Fixed: saving the Settings page restarted your background workers. If your server's timezone was stored under an older name, saving that page — even after changing only your alert email — was read as a timezone change: it set the system clock, rewrote every project's service settings and restarted the queue and scheduler. It happened on every save, and repeated for ever. Only a real change of clock does anything now.

• Fixed: a brand-new server showed its maintenance window twice, once in the panel's timezone and once in UTC, saying the same thing.

• Fixed: the maintenance window's first line now shows when it starts AND when it ends, in your own timezone, instead of only the start.

• Fixed: the "someone is scanning for your panel" email gave advice that did not fit. It said changing your entry code would achieve nothing — untrue if your panel still uses a short code from an older install, where changing it is the one worthwhile upgrade. It also offered the login allowlist as a way to stop an address reaching your panel, which that feature does not do; the address block, which does, is what it names now.

• Fixed: China's old timezone name mapped to another old name the panel did not recognise, so picking it left the country list unable to offer China's zones.

• Fixed: your timezone was shown under an old name. India reads Asia/Kolkata, not Asia/Calcutta — the same zone and the same clock, renamed in 1993. The panel displayed whichever spelling its configuration happened to carry, and the country list, which knows only current names, then could not offer your country's zones beside it. Both places that report the zone now give the current name. Nothing about your clock changes.

• Fixed: the maintenance window was shown in UTC first. Your server's window is stored in UTC, and the card led with that — so an owner in Asia/Kolkata read "Sun 03:30 → 03:50 UTC" and had to do the arithmetic to know when their own server goes down. Your panel's own timezone leads now, with UTC underneath for when you are comparing servers.

• Fixed: "Panel files unchanged since install" could describe a file that is not there. When one of the panel's compiled files had been deleted and a plain JavaScript file left in its place, the row said the plain file "sits beside the panel's compiled code" — beside something that was gone. It now says plainly that the compiled file was REPLACED, and tells you to treat the server as compromised if you did not do it yourself. Both cases were, and remain, a red row.

• Fixed: a check that was merely slow the first time was reported as a problem. On a two-core server the first health sweep after the panel starts pays costs no later sweep pays, so rows like "Cache & queue store (Redis)" and "Storage folder writable" said this check did not finish within its 2 second budget about services that answer in milliseconds. Measured here: four such rows on the first sweep, none on the next four. A check that runs late is now given a little longer to finish, and only a check that is genuinely stuck is reported — with how long it was actually waited for. Nothing was hidden and no budget was widened: a service that really is not answering still shows up.

• Fixed: a row that needed your attention could open by telling you everything was fine. The Home list shows one line per row, and "Panel files unchanged since install" led with 240 panel file(s) match the release exactly while it was amber because other files were present that the release did not install. The reason now comes first, so the line under an amber row says why it is amber.

• Changed: the email about a wrong panel address no longer tells you to change your entry code. That email means someone guessed your secret panel address wrongly 20 times and was locked out — the outermost gate doing its job, with no way to reach even the login page. It now says so, and explains that a panel hostname becomes publicly known through the certificate logs every HTTPS site is published in, so this happens without you sharing your address with anyone. Changing the entry code breaks every bookmark and saved tab you have and stops nobody, so it is now suggested only for the one case that warrants it: the code itself having been seen somewhere — a chat, a screenshot, a shared shell history.

• Fixed: a repository address of the form git@someone@127.0.0.1:repo.git was accepted, and reached this server. SSH reads the address after the LAST "@"; the panel checked the part after the first one. So the real destination hid in plain sight, the check passed, and git connected to it — proved with a real connection to this machine. Anyone who can start a deploy could do it, including a temporary login. Addresses are now read exactly the way SSH reads them.

• Fixed: two private IPv6 ranges were accepted again. A change in the previous release that closed one spelling of a local address opened another — addresses beginning fc00: and fe80: were converted to the wrong form internally and passed the check. Both are refused again, and public IPv6 addresses are unaffected.

• Fixed: the saved-address check covered your customer website but not your admin app. The previous release re-checked the stored address for one of the two repositories and not the other, so an address stored by an older release was still used on every admin update. Both are checked now.

• Fixed: the stored rule limit for a Cloudflare site now expires after a week. The panel remembers how many firewall rules your site allows so it can stop reporting rules that will not fit. If you later upgraded your Cloudflare plan, that remembered number kept the page quiet about rules your site could now hold. It is re-checked weekly, and immediately whenever a write succeeds or is refused.

A security and correctness release. Every repository address the panel accepts is now read the way the tools that use it read them, and a further set of faults was found by auditing the panel against itself — each one reproduced on a real server before it was fixed, and re-tested afterwards. Some of them could be triggered by somebody who had broken into ONE shop on a shared server, so if you host more than one shop on a box, this is a release to take.

• Fixed: every spelling of an address that points at this server is now refused. When you install a shop from git, the panel hands the address you type to git, which runs with full access to the machine. It checked only that the address looked like a git URL — so a file:// address made it copy a folder from the server into the shop's own files, and a http://127.0.0.1:… address made it fetch from a service running only on that machine. The same address can also be written many other ways, and each of these was proved with a real connection: an IPv4 address in IPv6 form ([::ffff:127.0.0.1]), a trailing dot (localhost.), the git@[…] form of an IPv6 address, ::127.0.0.1 without the usual prefix, and the short and numeric spellings of loopback (https://127.1/…, https://2130706433/… and the hex form). Addresses are now reduced to one canonical form before they are checked, by one shared check used everywhere — so a different spelling of the same address cannot pass. Local files are refused outright, and so is any address naming this server or a private network. Every normal address still works — GitHub, GitLab, Bitbucket, your own git server, a custom port, an address with a token in it.

• Fixed: the check was skipped entirely when updating your website's code. The address you type was only checked on the FIRST deploy of the customer website. Every deploy after that skipped it, and the address was saved for later automatic deploys too. Now checked every time, and a saved address is re-checked before it is used.

• Fixed: the panel said it had written fewer firewall rules than your site allows, for ever. After a partial write, the row stayed "different from the recommendation" on every page load, with no way to clear it — the note explaining why was recorded and then immediately overwritten by the panel's own read-back. The panel now remembers your site's real rule limit and measures the row against the room that exists, so a site configured as well as it can be reads as in sync.

• Fixed: a full rule list was reported as a bot-protection problem. On a paid Cloudflare plan, running out of rule slots produced a message about Super Bot Fight Mode refusing your payment callbacks — quoting a Cloudflare sentence that says nothing about bots — and sent you to the wrong settings page. Worse, it quietly stopped checking that the payment-callback exemption had landed. The panel now reads Cloudflare's actual refusal.

• Fixed: using an access token with an SSH-style repository address killed the job. If your project was set up with a git@… address and you later supplied a token, the deploy stopped mid-run with no explanation — and where the address had been saved earlier, it failed mid-deploy with an alert email rather than a plain message. It now tells you a token needs an https:// address, before the job starts, and leaves SSH-key deploys alone.

• Fixed: refusing your project's saved repository address refused nothing. The panel dropped the address and then fetched from the checkout's own remote, which is the same address it had just refused. It now stops and tells you which address to replace.

• Fixed: a health-page sentence could read "this undefined MB box" when the server did not report its memory size. It now says the size could not be read.

• Fixed: one panel message was still untranslated in all seven languages. The check meant to catch that was only looking at a third of the panel's text.

• Fixed: a Cloudflare firewall write could fail completely on a paid plan. When Cloudflare declined one part of the rule AND the rule list was full, the panel's retry put the declined part back — so nothing was written at all, on a site that had room for the rule that protects payment confirmations.

• Fixed: the panel said it had written more rules than it did. After a partial write it reported the full count and dropped the sentence explaining what was short and how to free a slot. It now reports what actually landed, with the explanation, and the row no longer shows as permanently out of sync — it says the site's rule list is full instead of asking you to fix something you cannot.

• Fixed: copying or moving files no longer records which files. The journal entry said "copied 2 of 3" and named no path, on every operation including the successful ones. Names are back. A bulk failure also produced an unreadable wall of text in one disappearing message, and the file list did not refresh when some files had landed — both fixed. A selection whose files are simply missing now reports "not found" rather than a server error.

• Fixed: a Cloudflare plan bought through a hosting partner was treated as the free plan. Cloudflare reports a resold plan as partners_pro (or partners_business, partners_enterprise), and the panel did not recognise those names — so a Pro site got the free plan's protection: one rate limiting rule instead of two, a 10-second window instead of a minute, a plain block instead of a managed challenge, and no managed WAF or Super Bot Fight Mode at all. It happened silently, with nothing on the page saying the protection had been reduced. A partner plan now gets exactly what that plan is entitled to. A plan name the panel genuinely does not know still falls back to the safe free-plan shape, as before, and if Cloudflare ever refuses the stronger rule the panel writes the basic one and tells you what Cloudflare said.

• New: the Health page tells you when your shops are allowed more memory than the server has. Each shop's storefront and queue worker get a memory limit sized from this machine. The panel already worked out when those limits add up to more than the RAM left over after the database, cache and PHP workers — and then did nothing with it. There is now a "Service memory budget" row that says so, with the numbers. It is a warning, not an error: these are ceilings, not reservations, so nothing is allocated up front and the shops usually run fine. What an over-committed server has lost is the safety net — if the shops ever peak together, the machine slows down or loses a service instead of one shop hitting its own limit. The row names the two real answers (fewer shops, or more RAM) and deliberately does not suggest lowering the limits, because they are already this server's sized values.

• Fixed: copying or moving several files told you nothing when one failed. The panel stopped at the first problem and answered with a single message naming no file — while some files had already been copied and one folder was left half copied. It now attempts every file, then tells you exactly which ones worked and which did not, and why. Nothing about a successful copy changes.

• Fixed: each shop's PHP could see the server's internal service settings. Alongside its own configuration, every shop's PHP was handed the housekeeping values the system uses to run PHP itself — including the address of another shop's PHP socket. Nothing in 6amMart reads any of them, and none of them let a shop do anything it could not already do, but they are the server's business, not the shop's, so they are no longer passed along.

• Fixed: a full Cloudflare firewall list left a shop with no rules at all. Cloudflare allows a limited number of firewall rules per site — five on the free plan, for the whole site. If your own rules (or another server sharing the site) had used most of them, the panel asked for all three of its rules at once, Cloudflare refused the lot, and the shop got none. The most valuable of the three is the one that lets payment confirmations through, and losing it can mean a paid order that never confirms. The panel now writes as many of its rules as there is room for, that one first, and tells you how many landed and how to free a slot for the rest.

• Clearer: what still protects your shop when those rules do not fit. That message used to say the scanner paths were "still blocked by nginx". Checked on a real server, that was only partly true: three of them are refused outright, while others reach the app and get a "not found". It now says which is which, so you can judge the risk yourself.

• Fixed: a value from the server could run code in your browser. This one matters most if you have ever pressed a "Fix this" button on the SixPreflight page. The SixPreflight page puts a fix's id into the button, reads it back when you press it, and used it to build the confirmation text — but the text was inserted into the page as markup rather than as words, so anything that looked like markup was treated as markup and ran. Proved end to end in a test browser: a crafted id executed. It also meant that dialogue never showed a real sentence, on any press. It now shows plain text, escaped.

• Fixed: a second server sharing one Cloudflare site deleted the first server's rules. The panel decides which rules are its own by asking its own host list, so another SixPanel server on the same Cloudflare site is invisible to it — and it claimed that server's rules as its own and replaced them. The other shop lost its payment-callback exemption, its never-cache rule and its login rate limit, and the run reported success. Rules that name another server are now left alone whatever else the panel thinks.

• Fixed: the panel could strip a protection off a rule you wrote yourself. When Cloudflare refuses one part of the panel's firewall rule, the panel retries without that part — and the retry rewrote EVERY rule in the site, yours included. If you had hand-written a rule to let your Shiprocket or Twilio webhooks past Super Bot Fight Mode, the panel quietly removed that exemption and said "1 of your own rules kept". It now only ever rewrites its own rules. On a Free site, where the panel never asks for that part at all, your rule could also make any unrelated Cloudflare error report itself as a bot-protection problem and send you to the wrong page — that too is fixed.

• Fixed: restoring a backup could write your settings file outside the shop. If something had left a shortcut where a restored file belongs, the restore followed it and wrote the snapshot's contents — database password included — wherever it pointed, and reported success while the shop itself got nothing. The restore now removes the shortcut and writes the real file.

• Fixed: a Cloudflare rate-limit page you could never clear. On a Free plan Cloudflare allows one rate-limiting rule, and if your own rule is using it the panel correctly leaves it alone — but then reported that Cloudflare had accepted its rule and dropped it, which never happened, and left the row as a job that could never finish. It now says your rule is using the slot, and where to free one if you would rather have the panel's.

• Also: Terraform and other tools keep their rule references. When the panel has to re-send a Cloudflare rule list, it used to strip the reference names such tools use to recognise a rule. The rules survived; their identity did not.

• Fixed: a break-in on one shop could become control of the whole server. When the panel updates a shop's settings file it writes a temporary file beside it first. That temporary name was predictable, and the folder belongs to the shop — so code running as that shop could leave a booby-trap there in advance and have the panel, which runs as the administrator, write wherever the attacker chose, with contents the attacker chose. A routine "Update" or a push from your repository was enough to set it off. The panel now creates that file in a way the system itself refuses to redirect.

• Fixed: one shop could read another shop's uploads-in-progress. Every shop's PHP shared one scratch folder, so a shop could list the files another shop was in the middle of uploading, and read anything that shop's code wrote there. Databases, passwords and settings files were never exposed — this was the scratch folder only. Each shop now has its own, readable by nobody else, and it is created on a fresh install and on an update alike: PHP does not fall back to anywhere else when the folder it is told to use is missing, so a shop that got the setting without the folder could not have written a temporary file at all.

• Fixed: one shop could throw away every shop's compiled code. Servers keep a compiled copy of your PHP so pages do not have to be re-read on every visit. That store was shared, and any shop could empty it — for every shop on the server — even one whose files it could not read at all. Each emptying makes every site on the box slow until the code is compiled again. Shops can no longer reach it.

• Fixed: one file operation could take the panel down. Copying or renaming a file onto a broken shortcut crashed the panel outright, along with whatever it was in the middle of — a backup, a deploy, an install — with no error anywhere. An ordinary code checkout can contain such a shortcut, so this did not need an attacker. Both operations now refuse the shortcut and say so.

• Fixed: weekly maintenance repeated its backup and skipped the security updates. When the weekly window installed a panel update, the panel restarted and picked the window up again — and then took a SECOND full backup, which the code specifically set out not to do. If that duplicate failed (likely, since the first one had just finished with the same storage), the window stopped there and that week's operating-system security updates and reboot never happened. The mail said the backup had failed and said nothing about the updates being skipped. The resumed window now runs only the steps that were left.

• Fixed: self-repair could stop for good, while the panel reported it was fine. The once-a-minute checks that restart a stalled queue or a stopped scheduler had no time limit. One database query that connected and never answered was enough to freeze them permanently — no more checks, ever, until the panel was restarted — and the Health page still read "Automatic repairs are on and there has been nothing to fix". Every check is now time-limited, and that row now fails loudly when the checks have stopped running.

• Fixed: moving to a new server left the panel open to the internet. If you had restricted panel sign-in to your own IP addresses, that list did not travel with a whole-server move: the new server accepted sign-in attempts from anywhere, and the move reported success. The blocked-addresses list did travel, which is what made this easy to miss. It travels now, and so do the checks that are supposed to notice a setting nobody classified.

• Fixed: the "panel domain" escape hatch did not stay open. sixpanel domain none reopens the panel on its IP address when a custom domain breaks. It worked, but your "close the IP" preference survived it — so setting the same domain again silently closed the IP once more, on a name that had just proved unreachable, and the only way back in was SSH. Clearing the domain now clears that preference too.

• Fixed: certificates could be issued for a name Cloudflare cannot secure. Cloudflare's free certificate covers your domain and one level below it. The panel checks this for every hostname you type, but the www. version it adds for you was never checked — so on a shop like shop.example.com it quietly put www.shop.example.com on the certificate, which visitors of that address then cannot reach securely while the panel reports SSL as live. It is now checked like everything else, and the panel suggests the spelling that does work.

• Fixed: the same check could be fooled by a capital letter. The rule that decides whether a name is too deep for Cloudflare's free certificate compared text without tidying it up first, so a capital letter or a stray dot in the domain made it answer "this is fine" about a name that is not. Five of six ways of writing the same name got the wrong answer.

• Fixed: unused certificates were never reported. The check that asks "is this certificate still used by a site?" matched loosely enough that any name containing another name counted — and the panel's own naming style guarantees that. So an abandoned certificate that keeps failing to renew looked in use and kept sending mail, which is exactly the noise that hides a real renewal failure.

• Fixed: a demo login could stall the whole server. The panel blanks email addresses out of what it shows a demo login. That rule got dramatically slower as text grew — 2.5 seconds on a large answer, a minute at the largest the panel allows — and a visitor could trigger it at will with ordinary requests. On a 2-core server that is both cores taken from your shops. It is now instant.

• Fixed: the activity log could fill the disk. It kept the newest 5,000 entries, but nothing limited how LONG an entry could be, and part of each entry comes from the request — so a few thousand requests could write tens of megabytes onto the disk your shops share. Entries are now capped in length as well as in number.

• Fixed: a long-open panel tab made needless requests. Signing in again in the same tab — after a session expired, say — left an extra listener behind each time, so a tab that had signed in many times re-checked running jobs once per sign-in every time you returned to it.

• Fixed: one panel answer could tie up a processor core for 13 seconds. The panel blanks credentials out of what it sends back to a demo or temporary login. The rule that recognises a credential's NAME was written in a way that gets exponentially slower as the text grows: a large answer took 0.9 seconds to blank at 50 KB and 13.7 seconds at the size the panel allows. On a 2-core server that is a core taken from your shop's PHP and database for as long as it runs. The same answer now takes under a millisecond. This is the same problem as the job-log blanking fixed below, in the one remaining place that had it — the whole blanking path has now been measured end to end.

Corrections to the previous day's release, found by reviewing its own changes.

• Fixed: a long line in a job log could slow the whole server down. The panel blanks credentials out of every line of every job log — deploys, backups, installs. The way that blanking was written in 1.4.108, a single very long line (composer and npm both print them) cost seconds of processor time instead of milliseconds: 4.7 seconds for one 50 KB line. On a 2-core server that time comes straight out of your shop's PHP and database, so a deploy could make the site slow while it ran. One 50 KB line now costs 17 milliseconds. Two older rules in the same file had the same problem and are fixed with it.

• Fixed: two credential spellings were still shown in job logs. MYSQL_PWD and SSHPASS — the names the panel's own database and transfer commands use — were not recognised as credentials, so they appeared unblanked in a job log and in the alert email for a failed job.

• Fixed: a temporary login lost two things it is meant to do. 1.4.108 tightened what a temporary login may change, and went too far: deploying and updating the code, and starting or restarting services, are exactly what a helper is invited to do, and both are listed in the manual as things a temporary login CAN do. Both work again. Pulling another server's data over this one stays refused, as it always has been, and everything 1.4.108 correctly locked down — DNS, certificates, domains, scheduled jobs, database migrations — stays locked down.

• Fixed: test results were blanked out of job logs. The credential blanking added in 1.4.108 treated the word "pass" as a credential name, so a line like Tests: 100, pass: 98, fail: 2 was stored as pass: ****. Composer and test output is now readable again, while db_pass, MYSQL_PWD and the rest are still blanked.

• Security: two more places could be tricked into writing outside your project. 1.4.108 fixed this for saving a file and missed the same trick in two others: creating a zip archive, and an upload that has to cross disks. A shortcut left at the target name — something a downloaded theme or module could include — sent the content elsewhere on the server. Both now refuse it.

• Fixed: saving the same file from two tabs at once could lose your work. The new save path in 1.4.108 had the two saves fight over one scratch file: one editor's content could be published under the other's, and the second save answered an error. Each save now uses its own scratch file, and a failed save no longer leaves one behind.

• Fixed: the "send a test email" refusal named two ports that could never work, and three small corrections with no visible effect: a project-scoping rule that did nothing, two refusal messages that had stopped explaining themselves (a temporary login trying to create a root-level scheduled job now gets told exactly that again), and a comment claiming a check did something it did not.

• Security: a folder name could run commands as root. The weekly clean-up reclaims space from PHP's private temporary folder. It built the command it runs by pasting that folder's name into it, and a folder name can contain almost any character — so anyone with a login on the server, including the limited account your shop's PHP runs as, could create a folder whose NAME was a command and have the panel run it as root the next time the clean-up went round. Nothing had to be clicked: the clean-up runs by itself on Sunday mornings. The folder name is now handed to the command as data, and a name that is not one of PHP's own folders is skipped rather than used.

• Security: the file manager could be tricked into writing outside your project. Saving a file writes to a scratch file beside it first, and while the file you asked for was checked against your project's folders, that scratch file was not. A shortcut left in place at the scratch name — something a downloaded theme or module could include — sent your saved content wherever it pointed, and left your file replaced by that shortcut, so everything you opened afterwards came from somewhere else. The panel now refuses to follow anything already sitting at that name and tells you which file to remove.

• Security: passwords could appear in the alert email for a failed job. The panel blanks credentials out of job logs before it stores or sends them, but it only recognised them in CAPITALS. The lower-case and mixed-case spellings — the ones in your app's own settings file, the ones Laravel prints when it reports an error, the ones the backup tools use — went through unblanked, and the last few lines of a failed job are emailed to you. All spellings are now covered, while ordinary words like "passed" and "bypass" are still left readable.

• Security: a temporary login could change things it should not. A temporary login is a helper you invite to look at a problem. It was blocked from a long list of actions, but that list had to name each one, so anything added since it was written was allowed by default: rewriting your Cloudflare DNS, re-issuing or removing a certificate, adding or removing a domain, creating a scheduled job, running a database migration, installing code, and stopping services. Reading stays open, so a helper can still do the job — everything that changes your server is now yours alone.

• Security: three payment credentials were shown in full. The App settings page masks anything that looks like a password or a key, and reveals one value at a time on request so there is a record of it. Three real names slipped past the check and were shown in plain text: SSLCommerz's store password, the licence code when spelled the American way, and Flutterwave's signing hash.

• Security: the "send a test email" button could probe your private network. It is meant to dial a mail server, and it checked the address but not the port — so it could be pointed at anything else on your network and would hand back whatever answered. It now dials mail ports only, and says which ones. Sending your real email is unaffected, whatever port your provider uses.

• Fixed: pages with tabs did not remember which tab you were on. Opening Settings or Security left the address bar naming the page but not the tab, so the tab you were reading could not be bookmarked, shared, or returned to by reloading. Browsing into a folder under Advanced ▸ Files bounced you back to the first tab for the same reason, and a Cloudflare link for a project that had since been renamed did the same.

• Fixed: switching tabs left the previous tab still working. Each tab refreshes its own readings while you look at it, and the tab you left never stopped. Ten switches between Health and Firewall left ten sets of refreshes running at once, all asking the server for the same things — enough for the panel to start refusing its own requests. Only the tab you are on now does any work.

• Fixed: the Server ▸ Info tab could read "NaN MB". When a memory or disk figure was missing, the panel printed that instead of a dash.

• Fixed: the Cloudflare page could come up completely empty. On most sites the panel hit an internal error while building the rate limiting row, and because that row is built alongside all the others, every one of the 33 settings disappeared with it — the page looked blank and "Set this up for me" answered an error. The row now also shows the exact limits YOUR plan would get (a free site and a Pro site get different numbers), instead of one fixed sentence.

• Fixed: restoring a backup could overwrite a different shop's database. The check meant to ask "does this database belong to another project on this server?" could never actually answer yes. If two projects had somehow ended up naming the same database, restoring either one would have written over the other's live shop while the log said the import succeeded. Both are now refused, and the message names the other project and where to fix it.

• Fixed: a deploy that failed left your shop's background work stopped. The panel pauses the queue and scheduler while it updates your code and starts them again at the end. If any step in between failed — a bad database migration being the common one — that last step never ran, so for ten minutes your shop sent no order notifications and ran no scheduled task, with nothing saying so. They are now always started again, whatever happened.

• Fixed: an update that stalled could freeze every other job for six hours. If your git host accepted the connection and then went quiet, the panel waited for ever — and because it runs one job at a time, the nightly backup and the database maintenance queued up behind it. It now gives up on a transfer that has moved less than 1 KB/s for a minute, which tells a stalled connection apart from a genuinely slow one: a large download that is still making progress is never interrupted.

• Fixed: a half-finished database import was reported as a live shop. When setting up a shop from an untouched CodeCanyon copy, if the database import stopped part-way the panel carried on and said "the shop is live" over a shop missing tables — and every retry then skipped the database, so the only way out was the command line. It now checks the import really finished, against the number of tables that code's own file creates, and tells you how to start over if it did not.

• Fixed: you were told the disk was nearly full and never told it was fine again. The "disk critically low" email had no matching all-clear, and worse, it blocked a second warning for six hours — so if the disk filled again that afternoon, you would not have heard about it.

• Fixed: a "certificate is working again" email about a certificate that was never checked. The check that notices when a renewed certificate has not been picked up was asking the wrong address and could not see anything at all. It now asks correctly, and when it cannot get an answer it stays quiet instead of sending reassurance it has not earned.

• Fixed: the websocket status said "nothing is listening" when the service was crash-looping. Those are different problems with different fixes — one is a port or firewall, the other is a process that cannot stay up — and the status now says which.

• Fixed: pressing "Apply" on the database indexes, then being told they were still missing. The Health page could keep showing the old count for up to five minutes after a successful apply.

• Faster. The nightly database index check read your whole database layout again after every single index it built — around 86 times over on a first pass. It now reads it once. The Health page's copy of that check is cached rather than re-read every minute, and the Settings → Performance page no longer measures the disk twice per load. On a real shop's 192-table database: 63ms down to 0ms for the cached read.

• Also: the sixpanel domain command accepted some names the panel then refused; the Database page could hang indefinitely on a database that stopped answering mid-question; and a server configuration warning listed the same item twice.

• The "deploy failed" email now tells you what to do about it. When a deploy stops because files were edited on the server, the alert used to say only "commit, stash or revert them" — three things the panel does not offer. It now gives you the two commands for your project, ready to paste: one to see what changed, one to discard it. The manual's copies of those commands were missing the project name too, so on a server with more than one project they could not run as printed; both are corrected.

• Fixed: the command the manual gives you for a refused update crashed. When a deploy stops with "local changes present", the manual tells you to run sixpanel exec php git status --short to see which files were edited. On a server running more than one project that command failed with an internal error instead — it looked for a user that only exists on single-project servers. It now means the project you have selected, tells you to name one if you have not, and says plainly when a project has no such service rather than reporting an internal bug. It could also have shown you the panel's own files instead of your shop's; it now refuses rather than looking in the wrong place.

• Fixed: the snapshot list could tell you that you have no backups when you do. On a server with both a local and an off-server destination — the pair the panel itself recommends — sixpanel backup list read the local disk, which is usually empty because the real backups go off-server, and printed "the repository is initialized but holds no snapshots" without saying which repository it had looked at. Measured on three servers whose off-server destination held two complete backups each. The listing now reads the destination that actually has backups, and naming one with --target still wins. Backups themselves were never affected, and where new backups get written has not changed.

• Fixed: turning on "block traffic that skips Cloudflare" made the panel warn you about your own server. After arming that protection, the Health page reported one of its own setting files as changed by hand, with advice ending "treat this server as compromised" — about a file nobody had touched. Measured on three servers: the file's contents were identical on all three and two of them were still comparing against the older, switched-off version. The panel now records that change like every other change it makes, so the warning means what it says. If you saw that warning about origin-lock.conf, this release clears it — and it really does clear: the panel is meant to take your server's current settings as the new baseline when an update lands, and the first thing it wrote after an update used to stamp the new release onto the OLD readings instead, destroying the signal that triggers that baseline and making the wrong reading permanent. Nothing on your server was ever wrong. A file you really did edit yourself is still reported, both before an update and after it.

• New: the panel now removes a "config cache" that is quietly switching off your live settings. Some versions of the 6ammart code read a handful of settings — the websocket keys your phones use for live order tracking, and on some shops the payment credentials — in a way that stops working the instant that cache is built. The app reports no error: the admin panel looks perfect while the phones receive an empty key and the map never moves. 6ammart's own installer and its updater both build that cache, so a shop can end up like this without anybody doing anything unusual. The panel already showed it on Health → Config cache safety and told you which command to run; now it does the repair itself, once a minute, and reloads PHP so the change actually takes effect. Nothing is lost — the cache is derived from your settings file, and the panel builds it back as soon as a future update of your app no longer needs this. It leaves your cache alone if it cannot read your app's code to be sure.
• Fixed: installing the untouched CodeCanyon code could leave the shop serving the installer. After the panel finished 6amMart's own install steps it switched the site to its normal pages, but PHP kept running the installer pages it had already loaded into memory. The install now rebuilds the caches and reloads PHP at that point, so the shop serves its real pages immediately.
• Fixed: repairing a half-finished install could ignore the admin account you asked for. On a project whose database already had rows — which is exactly when you use that repair — the email and password you typed were silently not created, and the panel then printed a login address for an account you did not have. It now creates the account you asked for, and says plainly when the shop also has admins of its own.
• Fixed: four smaller things on that same install path — the admin password no longer appears in the server's process list while it is being hashed; the login page addresses are written the way 6ammart itself reads them (a wrong order here could move your admin login or duplicate the setting); a database import that fails on its first line now reports the import error instead of a panel error; and "N storage entries" counts what the install added rather than everything already in the folder.

The big one here is for anyone installing the 6amMart code exactly as it comes from CodeCanyon, which is most people.

• New: the panel now finishes the 6amMart installer for you, on the untouched CodeCanyon code too. Until now, a fresh install of the code as CodeCanyon ships it stopped halfway: the panel put the files in place, set up the database, the certificates and the services — and then handed you a browser link and asked you to complete 6amMart's own six-step install wizard by hand. If you did not, you had a server where every page answered with an error, and nothing said which half was missing. The panel now runs those steps itself: it loads the database 6amMart ships, creates your admin account, sets your business name, unpacks the shop's default images, and switches the site out of installer mode. One install, nothing left for you to finish. (Our own optimised code was always installed this way; this brings the CodeCanyon code up to the same standard. Your CodeCanyon purchase code is untouched — the panel drives only the steps that come after it.) The built-in manual describes this too: the "Install your 6ammart code" page now says what the panel does in place of 6amMart's six-step wizard, instead of warning that your copy of the code might not support it.
• New: "Finish install" repairs a shop that was left half-installed. If you have a project sitting in that state — files on the server, no database, every page an error — the Deploys page's Finish install button now completes it instead of refusing and pointing you at a browser. The manual covers this as well.
• Fixed: the certificate list contradicted itself. sixpanel ssl status would list a valid Let's Encrypt certificate for your panel's domain and then, three lines below, warn that the domain "has no certificate yet" and send you to re-issue one — which Let's Encrypt refuses as a duplicate. The warning now asks the same question the certificate list answers.
• Fixed: the panel's port had five separate definitions inside the panel. Nothing was wrong on your server, but two of those five decided different things — which port the panel listens on, and which port the web server sends visitors to. If they had ever disagreed, the panel would have been running and unreachable at the same time. They are now one setting, checked automatically. Your panel's port is unchanged, and a new install still picks a random one.

• Fixed: the restart was missing from the record of the window that performed it. A window that restarts your server wrote its history without the restart step in it, so the Maintenance card, the Activity row and the summary email all showed one step fewer than actually ran — the very step that took your shop offline. The restart itself was always correct; only the record of it was wrong. It is now recorded like every other step, together with why it restarted, so when you read the history later you can tell a restart the operating system asked for from one your own "Every window" setting caused.
• Fixed: the Maintenance card could say "Ready" for a window that was going to refuse. Maintenance takes a full backup before it changes anything, and it refuses to start at all when there is nowhere to put one. But the readiness line did not ask that question — so a server with no backup destination showed a green Ready line with a "no backup destination" warning directly underneath it, and then quietly refused every window, week after week. The readiness line now asks the same question the window does, in the same words.

• Fixed: on the Maintenance tab, the restart row could say the opposite of the setting right below it. The checkbox read "Restart the server when one is needed", and described itself as restarting "only when the operating system says a restart is required" — while the Restarting dropdown three lines below it was set to Every window. Both halves of the page were describing real behaviour; only one of them was describing your server. On the one step in the window that takes your shop offline, that is the worst place for the page to disagree with itself. The row now says what the step does, and the sentence underneath is filled in from the setting you actually chose — so the two can no longer drift apart. Your servers restarted exactly as your dropdown said throughout; what was wrong was the description, not the behaviour.
• Fixed: if maintenance could not read your backup destinations, it told you that you had none. Before touching anything, the maintenance window takes a full backup, and it refuses to run at all when there is nowhere to put one — the message being "no backup destination is set up, so there is nothing to back up to". A fault while reading your destinations produced that same message, which would have sent an owner to the Backups page to add a destination they already had. It now says what actually went wrong. No backup was ever skipped or sent to the wrong place because of this.
• The maintenance window's choice of backup destination is now tested, all six ways it can pick one. When a server has several destinations, maintenance picks the one you scheduled first, and prefers off-server over local when it has to break a tie. That order had never been exercised — it is now, along with what happens when a schedule names a destination you have since deleted, and what happens to a window that was interrupted by SixPanel updating itself: it does not repeat the backup it already took, it puts your own choice of steps back afterwards, and a window left mid-flight by a server that was switched off for a day is abandoned rather than started at lunchtime.

• Internal tidy-up, no change you can see. The check that finds a package your system left half-installed was written out three separate times inside SixPanel, and two of those copies had already started to differ from each other. Nothing behaved wrongly because of it, but a rule written down three times is a rule that will eventually disagree with itself — so there is now one copy, and the other two ask it. Your server behaves exactly as it did before.

• The repair is now proven on a real server, not only in tests. We put a server's boot-loader package into exactly the broken state a customer would see — the package unfinished, its recorded boot device meaningless, and the system refusing to install anything at all — and let the shipped repair fix it: the boot-loader was written to the correct disk, the package finished, and installing worked again, with the server's shops serving normally throughout.

• The panel now finishes a package your system left half-installed, instead of telling you to. If a package never finished installing — an interrupted update, or a server image that shipped that way — your system's package manager refuses to install anything until it is dealt with, and says nothing useful about why. That one package silently breaks server updates, SixPanel's own updates, and every future install on the box. SixPanel now finds it, finishes it, and checks afterwards that it really is finished, before it starts any other work. It only repairs what it can be sure of; anything else it names for you rather than guessing. Measured on our own server: a boot-loader package had been left unfinished by the server image itself, and every update had been failing on it with an error that pointed at the wrong thing entirely.
• Fixed: the update could fail on a step that had nothing left to do. It checked that three small tools were installed. They already were — but the request still failed, because of the half-installed package above, and the message blamed the three tools. It now checks what is actually missing before asking for anything.
• The install address is now installer.allsweb.net/sixpanel/. Shorter, and it is the address on the website and in the manual from here on. Nothing on a running server changes — your box keeps updating from whichever address it was installed with, and the older addresses (/native/, /sixpanel-native/) still work if you have one saved.

• Fixed: the maintenance window reported a step as failed when it had worked. The step that updates the panel finishes by restarting the panel — which is also what stops the window watching it, so the window recorded "the job disappeared" and emailed you a failed summary for an update that had installed correctly. The window itself always carried on afterwards; only the report was wrong.
• Fixed: server updates could fail with an unexplained error, every time. If your server has a package the system never finished installing, the update tool refuses to run at all — and the message it prints does not say which package, so the panel could only pass it on as "the server command failed". The panel now checks for that before it starts, names the packages, and tells you the one command that clears them. Nothing is attempted until it is clear.
• Fixed: two more places that restarted your database without pausing its background workers first. A worker whose database vanishes for a moment stops with an error and emails you an alert — for maintenance you asked for yourself. It always restarted on its own, so nothing stayed broken; the cost was an alarm you had no reason to trust. The auto-tune step and the timezone setting both pause them properly now, as updating and restarting already did.
• SixPreflight's own documentation is no longer readable from your shop's address. Its README and change history were served like any other file. They hold no data of yours, but there is no reason for them to be public.

• A temporary login can no longer turn your scheduled backup off. Sharing a temporary login let the holder change the backup schedule — and saving an empty schedule switches backups off altogether, quietly, with nothing about your site looking any different until the day you need a backup that was never taken. The same login could also start a backup run whenever it liked, which ties up the server. Both now belong to you alone. A temporary login can still SEE whether your site is being backed up, and when the last one finished, because that is part of knowing the site is healthy.
• Fixed: the health report claimed your server was running old settings when it was not. One of the web-server settings is now sized to your disk, so the value on your server correctly differs from the one in the release — and the check that compares them read that as "out of date". It said the improvements in this release were not switched on, on servers where they were, and the repair it offered would have changed nothing and left the warning in place.
• Fixed: "check this project" pointed at a command that refused to run. The health report ends by naming your other projects and printing the command to see each one. On a server with more than one project that command answered "this panel's health report has no per-project sections" and did nothing. It works now.
• Fixed: compressing a file whose name begins with a hyphen. It was read as an instruction rather than a name, and the archive was not written.

• Fixed: a server address containing an unusual character could confuse the copy-a-site tool. An address or username beginning with a hyphen was read as an instruction rather than a name. Only the owner could reach this, and nothing was at risk, but it now cannot happen.

• The fix that stops your panel address being written to the log reaches servers that already exist, too. The panel's own web-server entry is normally rewritten only when you change your panel address, so on a server that was already running the old file would have stayed and the address gone on being logged. Caught by checking the server itself rather than trusting the release. The panel now re-writes that file when it starts, exactly as it already did for your shops' own files, and reloads the web server only if something actually changed and the new configuration is valid. It also refuses to make that change if the result would lose your panel address's certificate — a certificate that had expired and been tidied away, or was removed, or that a restore left out, must never turn your panel address into an unencrypted "not found" — and it says so in its log when it decides to leave things alone.

• A temporary login can no longer see your secret panel address. The address you use to reach the panel is a password, and your web server was writing every panel request into its own access log — which a temporary login could read on the Logs page. Two things changed: the panel's own requests are no longer logged at all, and anything a temporary login reads now has that address removed from it first. Nothing about how you reach the panel changes, and the error log, which is what diagnoses a fault, still records everything.
• A temporary login can no longer read your database password. It was already refused the .env file. But your site keeps a compiled copy of those same settings, under an ordinary name, and that copy was readable. It and the site's other compiled caches are now yours alone.
• A temporary login can no longer pull another server's site over this one. That does the same thing as importing a database, which it was already refused.
• More things now belong to you alone, each one already listed as off-limits in the manual: clearing the server's logs, the self-healing actions, the first-run settings, the licence code, the monitoring key, the SixPreflight password, starting phpMyAdmin, the database clean-up, adding or removing database indexes, testing a backup, and which Cloudflare account this server uses. What a temporary login is FOR is unchanged — deploying, updating, rolling back, restarting a service, reading logs and files, and the database pages.
• Fixed: your shop's background workers could start up in the middle of a move or a restore. Both jobs pause a shop while they copy, and the safety net that restarts a paused shop assumed the pause would be short. On a shop with real data it is not, so the workers came back while the copy was still running — writing orders after the copy had been measured, or starting up against a half-restored database. Both now hold for as long as the work takes, and if the net does fire, the job says so instead of reporting a clean finish.
• Fixed: two "Get HTTPS" presses in a row could undo each other. Asking for a certificate on two addresses of the same site, within a minute, left the second one recording the first as not secured — and the next time the panel started, it stopped serving HTTPS on that address. Each certificate now records only the addresses it is actually about.
• Fixed: a move interrupted by a restart blocked every later move. If the panel restarted while a project was being moved, the panel went on believing that move was still running — for ever — and refused every move and every server migration after it. Such a move is now recorded honestly as interrupted, with the step it had reached.
• Fixed: a move could finish "successfully" onto a broken server. If the other server could not finish setting the site up, the move noted it and carried on, because the copy itself was perfect — so you were told to point your domain at a server whose every page was an error. It now stops, with your shop still running here and nothing switched over. A move also asks the other server up front whether it is new enough, instead of failing halfway.
• Fixed: scheduled backups could pile up. If a backup took longer than the gap to the next one, each run queued another, and the queue grew until the panel appeared to ignore every button. A scheduled backup now sees that one is already running and lets it finish — your data is in that run either way.
• Fixed: maintenance could start in the middle of a move. The weekly window can update the system and restart the server, and it could not see that a project was being moved to another server, so it could restart the box mid-copy. Each now waits for the other, and the Maintenance page tells you what it is waiting for.
• Fixed: a migration or import could run while a backup was being taken. The guard covered one direction only, so a job already waiting in the queue could start in the middle of a database change — and the backup it produced would match no version of your site.
• Fixed: database indexes that failed to build left no trace. If none of them could be built, the Database page still showed the last successful pass. It now shows the failure and names them.
• Fixed: a setting you type by hand in the panel's own settings file is now read. Two ways of writing the same line — both accepted everywhere else — were understood by some parts of the panel and ignored by others, and a change made from the panel could then add a second line for the same setting.
• Fixed: the temporary file used while changing your backup password is always removed, even if the panel restarts mid-change.

• A move now checks every table, not a sample. The check that compares both servers before a shop is called moved was looking at eight tables out of roughly

1. A difference in any other table would have passed unnoticed. It now compares all of them, and refuses to report a comparison it could not complete.

• A move that cannot read one side now says why. "The database could not be counted on both sides" used to hide the actual reason — an unreachable panel, a permission problem, a timeout. The reason is now in the log.
• Fixed: the "same page online" link at the foot of each manual page. It pointed at an address with a version in it, which the site only handled by redirecting you to the real page. It now links straight there.
• Your panel now tells search engines to stay away. The panel's web address contains your private access key, so it should never appear in a search result. Every page, file and API response now carries a no-indexing instruction, the phpMyAdmin area included. Nothing about how you reach the panel changes.

• The duplicate move entries already on your server are hidden too. The previous release stopped creating them; this one tidies away the ones that were already recorded — without removing older moves that only have that one entry, so nothing disappears from your history.

• Fixed: a completed move was listed twice. Every successful move appeared twice under Recent moves, the second time as an empty entry with no start time and no log to open. One entry per move now, carrying what was checked on both sides.

• Fixed two things on the Migration page. A linked server's name and its SixPanel version were printed with no space between them, and the version shown could be out of date while looking current — it is the version SixPanel saw the last time it checked, so it now appears next to when that was.

• New: empty a shop's error log from the panel. Once you have fixed what was going wrong, Logs → App errors → Empty this log clears the record so the page shows only what happens from now on. Your shop, its data and its settings are untouched, and new errors are still written as they happen.

• A migration now checks the other server first. If the server you are moving to runs an older SixPanel than the one you are moving from, you are told so before anything is copied — with what to do about it — instead of the migration stopping part-way with a technical message. Nothing is copied until that check passes.

• Fixed: linking another server with a password did not work. SixPanel offered a password as a way to link a server, but the tool it needs to use one was not installed — so the link was accepted and then failed later, when it was used. That tool now ships with SixPanel, including on servers that simply update to this release, and a server that somehow lacks it says so straight away instead of storing a login it cannot use. This mattered most for moving to a brand-new server, where a password is usually the only login you have.

• New: move everything to a new server. Give SixPanel a brand-new, empty server and its SSH login, and it installs itself there, sends your settings, and moves every shop across one at a time — comparing every table's row count and every uploaded file before it calls each shop moved. Your DNS is never touched, so customers keep reaching the old server until you point the domains yourself, and nothing on the old server is deleted: every shop stays there with its data, workers stopped, so you can go back at any moment. A shop that fails to move does not stop the rest, and the result says "partly done" rather than pretending otherwise. The new server keeps its own panel address and password — see Move everything to a new server in the manual.
• New: a Migration page in the panel. Linking another server, moving one shop, and moving the whole server are now all on Migration, instead of being available only from the command line.

• Fixed: a moved project's uploaded files landed in the wrong place. The images and other uploads arrived on the receiving server one directory too high, so the shop would have had none of them. SixPanel noticed by itself — the move compares both sides before switching anything over, so it stopped and left the project running on the original server. Files now keep their structure, and the storefront's own configuration goes to the storefront rather than to the admin application.

• Fixed: the last step of a project move could not load the database. The import connected to the receiving server's database the wrong way and was refused by it, so a move got as far as copying every file and then stopped. It now connects the same way everything else on the box does. A move that stopped there changed nothing: the original server kept its data, and the half-built project on the receiving side was removed automatically.

• A project move now insists on being told which project. If the project was not named — a mistyped field in a script, for instance — the request was taken to mean the server's main project. It is now refused instead, and the main project is refused by name with the reason: every server already has one, so it can never be moved across one project at a time. Nothing was ever at risk of being overwritten; a move refuses to write over an existing project either way.

• Fixed: the second half of a project move could not run at all. Every step that ran on the receiving server — importing the database, counting the rows, checking the copied files, repairing ownership, cleaning up after a failure — was passed which project it was about, and that value was being dropped before it arrived. Each of those steps then stopped with a "usage" message naming the very thing it had been given. Nothing was at risk: a move stopped rather than doing the wrong thing. Fixed in one place, so all five steps read it the same way.

• A move that fails now cleans up after itself, so you can just try again. Previously a failure part-way through left a half-built project on the receiving server, and because a move refuses to write over an existing project, every later attempt for that shop was then refused — with nothing obvious to do about it. SixPanel now removes what it created there itself. It only ever removes a project it created for that move: one you made on that server, or one with a shop installed, is never touched.

• Fixed: moving a project failed while copying its files. On a server SixPanel reaches as ubuntu rather than root — which is most cloud images — the copy had no permission to write into the receiving project's directory and stopped with "Permission denied". It now copies with the same elevation it uses for every other command, and then hands the received files back to the project's own user, so the shop can read its own uploads. Nothing on the original server was affected by the failure: it kept its data and its safety backup.

• Fixed: moving a project could hang before it started. The move took a safety backup first and then waited for it — but the panel runs one job at a time, so the backup was queued behind the move and the move was waiting for the backup. Neither could finish. The move now runs alongside the panel's job queue instead of inside it, and reports its progress step by step.

• Linking a server now works when it does not allow root logins. Most cloud images — AWS and Google among them — refuse an SSH login as root and give you a user like ubuntu instead. Give SixPanel that user; it elevates each command itself. A server you reach as root is unaffected.

• Link two servers, and move a project between them. Settings → Server links pairs this panel with another SixPanel — you give it the other server's SSH details once, and the pairing stays. From then on you can move any project across, one at a time, and the projects you do not move keep running exactly where they are. Both servers stay live.

A move copies the project's configuration, its uploaded files and its database, and the other server creates the project itself, so it gets its own database user, its own PHP pool, its own Redis instance and its own ports — nothing collides with what is already running there.

What it checks before it starts: that the other server answers, that SixPanel is installed on it, that the project name is free there, and that it has enough disk space. Any of those failing stops the move before anything is copied.

What it checks afterwards: it counts the rows in your database on BOTH servers and compares them, and it fingerprints every uploaded file on both sides and compares that too. If anything does not match, the move fails, says what differed, and your project stays live on this server.

A backup is taken first, on this server, and verified — so there is something to come back to.

Your domain is not moved and nothing is deleted. When the move finishes, the project is still here with all its data, only its background workers are stopped. You point the domain at the other server when you are ready, check the shop yourself, and delete the old copy by hand when you are happy. The panel never makes that decision for you.

The full page is Move a project to another server in the manual, reachable from the Help link on that tab.

• A backup test that had nothing to test no longer reports a pass. On a server whose app is not installed yet, the weekly test found no database to restore — and said "PASSED", which the Server → Health page then reported as "the whole database restored from the backup and read back correctly." Nothing had been restored. Zero databases were loaded and zero rows were counted.

That row is the one thing that tells you your backups are real before you need them, so it now says plainly that there was nothing to prove, and what to do: install your app, take a backup, and test again. An amber row, not a green one.

The Health page also no longer claims "the whole database" when the test did not record how much it read back. A test that proved nothing was making a BOLDER claim than one that proved 190 tables.

If your app IS installed, nothing changes — that path already restored the database into a throwaway copy, counted its tables and rows, and failed if they were short.

• sixpanel block prints a table again. It was printing raw JSON, one line per blocked address, instead of the Address / Blocked / Reason columns. The panel's own Blocked addresses page was never affected.

• The address box on that page was too narrow to show its own example.

• You can block an address. Panel → Security → Blocked addresses takes one address (203.0.113.5), a whole range (203.0.113.0/24) or one IPv6 address, with a note saying why, and shuts it out of the panel completely. The list shows every blocked address with the day you blocked it and your reason, and an Unblock button beside each one.

It is stronger than the login address list above it in two ways. It takes effect at once, even on somebody signed in from that address right now — they stop being able to reach the panel mid-session. And it covers the whole panel rather than the login page, so a blocked address cannot even see that the panel is there.

It covers the panel only. Nobody is blocked from your shop or your apps.

Two things the panel refuses to block: your own address, which is named on screen so you can see what it is, and 127.0.0.1 — the web server in front of the panel reaches it over that address, so a rule covering it would refuse every visitor to the panel rather than one, you included, on every device.

From the server, sudo sixpanel block shows the list, sudo sixpanel block <address> adds one, and sudo sixpanel block clear [<address>] lets one or all of them back in. That last command is why blocking is safe to use at all: the block lives in the panel's own settings, so it can always be lifted from the server itself, even when the panel is the thing refusing you.

• Monitoring is now its own card on Home, with a range you choose. The three charts under the meters have become a card of their own, and you can ask for the last hour, six hours or 24 hours — the panel keeps a full day of history now, where it used to keep four.

Each chart carries a red dashed line at 90%. That is what makes a small chart answerable: 40% and 95% look identical on a thin line with nothing to compare against, and the question you actually have is "is this close to trouble". The number beside each label is where it is right now.

At the foot of the card, Per-service usage right now opens a table of which service is using what — the database, the web server, PHP, the panel itself. It is read only when you open it, so a closed card costs the server nothing, and neither does the longer history: the panel still takes one sample a minute, the same as before.

• The panel's own files are locked down tighter. Everything in the panel's data directory is now readable only by root, including the login history. Nothing could read those files before either — the directory itself was already closed — but each file's own permissions disagreed with it, and one directory setting was the whole protection. This puts both in agreement.

• You can now choose the panel's port when you install. The panel never sits on 80 or 443 — those serve your shop — so it takes a port of its own, and by default the installer picks a random one and prints it at the end. That is the safer default: a panel on a predictable port is one every scanner finds.

But most cloud firewalls are written before the server exists — an AWS security group, a Google Cloud rule — and a random port means installing first, reading the port off the summary, then going back to edit the rule. So you can name it:

  sudo PANEL_PORT=31149 bash install.sh

Write it in that order. PANEL_PORT=31149 sudo bash … looks equivalent and is not: sudo clears the environment it is handed, so the installer would never see it and would quietly pick a random port instead.

The installer refuses an unusable port before it changes anything, and says which problem it is: below 1024 (reserved, and 80/443 belong to your shop), the port this stack uses for live order updates, out of range, or something already listening on it.

An already-installed server is never moved by this. If you re-run the installer with a different PANEL_PORT than the one your panel is on, it keeps the port you have and tells you the command that can change it (sudo sixpanel port <number>), which restarts the panel and re-renders the web server together. Moving it silently would break your bookmark and your firewall rule in the same second.

• Fixed: a warning inside the installer could abort the install. One branch — the one that runs when the build does not name a Node.js version — called a warning helper that had never been defined. The installer runs with "stop on any error" set, and calling something that does not exist counts as an error, so a path whose whole purpose was to warn and continue would exit instead.

• SixPanel is ready to be published for arm64 servers, and can no longer install the wrong one. The panel is shipped as compiled code, which only runs on the processor type it was built for. Until now the update service held a single build, so there was no way to offer amd64 and arm64 side by side — and, more seriously, a server could be handed a correctly-signed build for the wrong processor and end up with a panel that could not start.

Three things changed. The update service now holds one build per processor type; your server asks for its own and says which one it asked for. The panel refuses a build for another processor before downloading anything, and says so plainly — the installer has always done this, the update button had not. And a build with no processor recorded is treated as amd64, which every release before today was.

Nothing to do on your side. An amd64 server keeps updating exactly as before.

• The install page no longer promises arm64 support that is not published yet. Its requirements table said "x86_64, or arm64", which was true of the installer and false of the release: an arm64 server was refused. It now names x86_64, explains why, lists the common arm64 machine types (AWS Graviton, Ampere, Hetzner CAX) and says what to do if you already have one. The installer's own refusal also stopped claiming the missing build was "a one-command rebuild at our end", which it was not.

• Your server can now look after itself, once a week, at an hour you pick. Left alone, a server drifts: security updates pile up, SixPanel goes stale, a certificate creeps toward expiry, and a restart the operating system asked for never happens. Settings ▸ Updates and restart now has a maintenance window — Wednesday 02:00 to 02:20 UTC by default, shown in your own timezone as well — and when you turn it on, that window does the lot in an order chosen so that a failure is always recoverable:

1. It checks that starting is safe at all: enough free disk, the server not already busy, no other job running. If not, it skips the week and emails you why. Skipping changes nothing.
2. It takes a full backup — before anything else, every time. If the backup does not succeed, the window stops there and your server is untouched. It will not even start without somewhere to back up to.
3. Database care, then any certificate that is due, then SixPanel itself, then your operating system's security updates.
4. A restart, only when the operating system says one is needed — and never after a step that failed.

Every step is the same job you could run by hand, so it appears in Jobs with its own log, and Activity says the maintenance window did it rather than pretending somebody signed in at 2am. There is a "Run maintenance now" button for when you would rather not wait for Wednesday.

• New: Server ▸ Info — everything you might be asked for, on one page. Your public IPv4 and IPv6 addresses as copy-and-paste fields (the values an A or AAAA record needs), the processor and how many cores, memory and swap, which Ubuntu or Debian this is, the exact PHP, MariaDB, nginx, Redis and Node.js versions, how long the server has been up and how busy it is. One button copies all of it as plain text for a support ticket.

It also tells you two things nothing in SixPanel used to: whether your server is using swap — memory kept on disk, which makes everything on the box feel slow and usually means it is short of RAM — and whether the address the internet sees is different from the one configured on the server, which is what being behind your provider's NAT looks like and is a common reason a domain points at the wrong place.

• Updating your app no longer logs an error in your app's own log. While an update rebuilds your app's caches, the per-minute scheduler kept starting your app anyway — and for a minute or two the file it needs was not there, so your own log filled with routes-v7.php: Failed to open stream on a shop where nothing was wrong. It also made the Scheduler row on the Server page look broken, because that row is driven by the scheduler's heartbeat and the failed tick never wrote one.

SixPanel now pauses the queue and scheduler while the app is mid-change and starts them again when it is done. Queued jobs are not lost — they wait in the queue. And if an update ever fails halfway, those workers are started again on their own within ten minutes rather than staying paused.

• Restarting the database no longer reports its own queue worker as failed. A queue worker whose database goes away exits immediately, so restarting MariaDB — from the Services page, or as part of a SixPanel update — took the workers down with it and emailed you that a queue worker had FAILED. The workers always came back on their own, so nothing was actually broken; the problem was the alert, arriving for maintenance you had just done yourself. Queue workers are where orders, notifications and payment callbacks are processed, so that is the last alert that should ever cry wolf.

SixPanel now pauses those workers before the database moves and starts them again afterwards. Queued jobs are not lost — they wait in the queue and are picked up when the worker returns. Stopping the database on purpose still leaves the workers stopped, which is what you asked for.

• A scheduled backup could get stuck and quietly stop everything behind it. If the database dump hit a filesystem error at the wrong moment, the backup stayed on "running" for ever instead of failing — and because SixPanel runs one job at a time, everything queued behind it never started. On the server this was found on, that meant the offsite backup and both nightly database-care passes had silently not run, while every page still looked healthy.

Two changes. The dump now always finishes one way or the other, and says why if it failed. And any job that stops responding is cleared automatically after six hours with an explanation on it, so the queue keeps moving even if something new ever gets stuck. Six hours is deliberately long — nothing normal comes close, so honest slow work is never cut short.

• A failed SSL renewal that was not actually a failure. When two renewal runs overlap, one of them is refused by certbot's own lock — it does nothing and reports an error. That was being shown as "ssl-renew failed" on servers whose certificates were all perfectly current. SixPanel now waits for the other run to finish instead of treating "something else is doing this right now" as a problem. A real renewal failure is still reported immediately, and is never retried.

• Two health rows pointed at versions that do not exist. One offered an update "from 1.5.23 onwards" and another said a feature "arrived in 1.5.5" — version numbers from the Docker edition, not this one. Both rows now describe your server and point at the update button.

• Your database was storing the same thing over and over, and the nightly care pass now removes it. 6amMart saves a copy of the ordered item inside every order line, and that copy included the whole "module" record — the module's description text and its translations — even though nothing ever reads it back. On a real shop with 66,701 orders that was 87 MB of the database taken up by 42 distinct blocks of text repeated 113,231 times: 16% of everything stored.

Removing it took that shop's database from 539 MB to 434 MB — 19.5% smaller — and its backup from 42 MB to 36 MB. Nothing was lost: order lines still show the item exactly as it was ordered, and the "Database care" card tells you how much is waiting to be reclaimed before it runs.

This runs on any 6amMart install, including a completely stock one from CodeCanyon. On stock code the app keeps writing those copies as new orders come in, so the nightly pass is what keeps them out — verified on an untouched v4.1 install, where the duplicate is 38% of each order line.

Disk space comes back on the Sunday rebuild, as with everything else the care pass removes.

• A slow money report got faster. The day-wise earning report was looking up every order twice to read one column, on every load. It now reads each order once: the earning totals went from 419-487 ms to 252-336 ms, and from 210 ms to 48 ms when you filter to a single month. The figures it reports are identical to the paisa — that was checked before and after, not assumed.

• The panel itself opens faster. Signing in was asking the server the same two questions twice each, and waiting for two independent answers one after the other instead of together. Nine requests instead of eleven, and the panel appears in about 3.3 s instead of about 3.8 s on a server behind Cloudflare. Where you are in the world affects this more than the server does — each request has to cross the internet, so what matters is how many there are.

• 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 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 as well. 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.

• A release that cannot start can no longer be published. The build now refuses to package any release whose compiled tree does not boot and serve its own login page first — so a missing file that the panel reads at its own startup is caught here rather than on your server.

The panel always knew only one job runs at a time; now every page does too.

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

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

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.

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 running website service had the same problem, from the same cause: 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.

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. It matches whole paths when it decides that — an earlier attempt asked whether the release ships …/deploy.js and got "yes" because that text appears inside …/deploy.jsc, which made every stray look like a shipped file and removed nothing, silently. A test now creates a tree with three strays, a shipped loader and an innocent file, and counts what survives.
• 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 by an earlier build the same day, 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.

Also in this release

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

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

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 an earlier version, it will take this update through the old, unchecked path — that is unavoidable, because the check ships inside the update it is checking. From this release onward every update your server applies is verified before it runs.

• 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. No shop 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.

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

• The old shared cache service is stopped once nothing is pointed at it. A server with no shop installed yet would otherwise have kept an unused cache service running for ever, so a freshly installed server and an updated one did not end up in the same state. It is left alone the moment anything still uses 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.

Also for servers running more than one project: 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 predates the widening of the cache described above.
• 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.

This is what makes the speed work above real on a server that updates rather than installing fresh.

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

• The customer manual ships with the panel. All 24 pages are readable in the panel and over SSH, reached by the Help link beside each feature, 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.