# SixPanel Docker (retired) release notes > Source: https://test-allsweb.allsweb.net/sixpanel/changelog/docker > Markdown for agents: https://test-allsweb.allsweb.net/sixpanel/changelog/docker.md > Publisher: AllsWeb (www.allsweb.com) The container runtime, retired on 29 August 2026. It ran the same panel with its stack in containers, on its own product line and numbering. No further work is done on it and no install command is offered; these notes stay published for anyone who ran it. Which build a particular server runs is read from that server (`sudo sixpanel version`, or Settings in the panel), never from this page. Version numbers on the 1.4 line are renumbered from time to time — several same-day releases merge into one entry — so no single number here is a fixed landmark. ## SixPanel Docker (retired) 1.4 — published on the Stable release channel, installable ### 1.4.7 — 2026-08-29 the last SixPanel Docker release Update with `sixpanel server update`. Nothing to configure and no manual step. **This is the final release of SixPanel Docker.** Development continues on SixPanel, the version that runs directly on the server without Docker. Keeping two products that do the same job meant neither got the attention it deserved, so from here there is one. **Your server keeps working exactly as it does today** — this release stays installable, `sixpanel server update` keeps answering, and the install address keeps serving. There is nothing you have to do and no deadline. If you would rather move to the other one, it is a fresh install on a new server plus a site migration, not an upgrade — ask us and we will walk you through it. ### Two things a shared temporary login could do, and can no longer - **A temporary login could read a copy of your passwords.** It was already refused the `.env` file that holds your database password, your app key, your mail login and every payment gateway secret. But your site keeps a compiled copy of those same values, under an ordinary filename, and that copy was readable — so refusing the first file was refusing the label rather than the secret. Those compiled files now belong to you alone. - **A temporary login could switch your scheduled backup off.** It could change the backup schedule, and saving an empty schedule turns backups off altogether — quietly, with nothing about your site looking any different, until the day you need a backup that was never taken. It could also start a backup run whenever it liked, which ties up the server, and start a backup test, which restores your data into a scratch database. All three are yours alone now. 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. ### Also 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. Only you could reach this, and nothing was at risk. ### 1.4.6 — 2026-08-23 the install address, the mark, and a changelog link that was showing you the wrong product Update with `sixpanel server update`. Nothing to configure and no manual step. ### What you will notice - **The install command has a new address.** SixPanel Docker installs from `https://installer.allsweb.net/sixpanel-docker/install.sh`. The old `/sixpanel/` address still works and will keep working — a copy of the command you saved months ago is not broken — but the one printed on the website and in the manual is the new one, and it is the one to use from here. Your server updates from whichever address it was installed with, so nothing on a running box has to change. - **"What changed in this release" now opens this product's release notes.** The link in Settings went to the other SixPanel's changelog. Both products number their releases 1.4.x, so it did not fail — it found an entry with your version number on it and showed you a different product's notes, with nothing on the page to tell you so. - **SixPanel Docker has its own mark.** The same hexagon as SixPanel's, with the core hexagon replaced by the Docker whale: the login screen, the sidebar, the browser tab and the phone home-screen tile all carry it. ### Under the hood - The download no longer carries the other product's logo files. Everything under `panel/` is packaged wholesale, so the sibling's eight brand files travelled inside every release alongside the six this panel actually loads. - The installer, the CLI and the panel all check that a signed release record names this product before they will act on it, and all three now expect `sixpanel-docker`. That check is what makes the shared installer edge safe to serve two products from: a release for the other one is refused rather than installed. ### 1.4.5 — 2026-08-19 the panel stops telling you things that are not so, and gets a logo Update with `sixpanel server update`. Nothing to configure and no manual step. Every page and every wizard was opened on a real server carrying a real shop — 66,701 orders — and read as an owner would read it. Most of this release is the panel's own honesty: places where it said something that was not true, or offered a button that did nothing, or hid the one button you needed. And SixPanel now has a mark of its own. ### What you will notice - **SixPanel has its own logo.** A hexagon with a rising tail — a six, built from a hexagon for stability around a small core hexagon for the server. It replaces the AllsWeb mark on the login screen, in the sidebar and in the setup wizard. The browser tab has an icon for the first time: there was no favicon at all before, so every tab showed your browser's blank-page placeholder. Adding the panel to a phone's home screen gets a proper tile too. The version now sits quietly at the foot of the sidebar, where it is a fact to look up rather than part of the logo. - **A finished job now says finished.** Update your panel and the live log would reach the end, the panel would restart to run the new build, and the status chip stayed on **running** — forever, on a job that had actually succeeded. There was no way to tell a finished update from a stuck one without leaving the page. - **The installer prints a username you can actually log in with.** On a slow first boot it printed `admin`, which is not the account it had just created, so the very first login attempt failed. The closing summary was rewritten too: your address, username and password first, then what to do if the address does not open. - **Installing your shop works on plain CodeCanyon 6amMart.** The recommended one-click install used a command that only exists in our own build of 6amMart; on untouched code it simply failed. The panel now checks first and, when it is not there, walks you through 6amMart's own installer instead. - **The dashboard stops crying outage.** A missing backup — nothing broken, nothing down — lit the banner with *"Something is wrong right now"* and *"that is what your customers are feeling"*. It is still shown, and still red, but that sentence is now reserved for something actually failing this minute. - **The Backups page no longer promises protection it does not have.** With storage set up and no backup yet taken it said *"This copy still protects you from a bad update or a wrong click"*. There was no copy. - **The backup wizard lets you confirm you saved the password.** The one screen that puts the key to every encrypted backup in front of you had no way to say "I have written it down", so the Health page kept nagging. (Nothing was ever lost: the password stays readable until you confirm.) - **The Firewall page stops ticking a box it cannot see.** It said, correctly, that the panel cannot see your provider's firewall — and then put a green tick beside *"Web traffic: Cloudflare addresses only"*, which told you your edge was locked down when nothing had been checked at all. - **A database import no longer blames the size of a file that is not too big.** Any problem with an upload came back as *"Payload Too Large — compress it to .sql.gz"*, about a file that could easily be nine bytes. - **The Health page stops vouching for a check-up tool that cannot read it.** The panel writes a small file of server facts once a minute so SixPreflight can report the truth instead of "no answer". The row went green on the strength of having written that file, without looking at whether anything could read it. On a shop whose SixPreflight is older than the panel, nothing can. - **The setup wizard can see Cloudflare**, and no longer offers to "skip" a step it has already marked done. - **Smaller things that were wrong on the page.** The Cron summary counted three panel tasks and called them all fine while two were off. The disk breakdown drew 1 GB wider than 8.8 GB. The Database page cut off the version number. SixPreflight showed the same Connect button twice. ### What you must do by hand Nothing. Your browser may hold the old blank tab icon for a while — a hard reload clears it. ### What changed under the hood Two machines that did not exist before, both kept in the build: - **Every page is now opened in a real browser** during testing — 19 pages, each checked for script errors, failed requests, empty content and two buttons that look like the same button. Endpoint tests could not have found any of the above: every request answered 200 with correct data, and the page still told you the wrong thing. - **A page may not describe something that is not there.** Five checks now assert exactly that against the pages' own source, each verified to fail on the code as it shipped in 1.4.4. One thing that looks like a defect and is not: your shop's name in the App .env page may read something like `6amMart1786172740`. 6amMart writes that itself during installation — it is in the original CodeCanyon code — and the panel deliberately never touches it, because Laravel builds the login cookie name from it. Your customer-facing name lives in 6amMart's own admin settings. ### 1.4.4 — 2026-08-18 a stranger can no longer push your shop's fast pages out of memory Update with `sixpanel server update`. Nothing to configure and no manual step. ### What you will notice - **Two more pages join the fast set.** The parcel cancellation reasons and the vehicle list were taking about **17 milliseconds each, for every customer**, and now take about **1.5**. They are small pages — the time was never the size of the answer, it was your shop building the whole answer from scratch every time somebody asked. - **Nothing else you can see.** The rest of this release is one line of configuration that closes a way the speed could have been taken away from you, described below because you should know it existed. ### What you must do by hand Nothing. ### What changed under the hood Your shop keeps a five-second copy of the pages that are the same for everybody. Which copy to use depends partly on headers the phone sends — the delivery zone, the module, the language — and anyone can send whatever they like in those. So a stranger could ask for the same page with thousands of made-up zone values, each one stored as its own separate copy, until there was no room left and your real pages had been pushed out. Your shop would have gone quietly back to full speed on every request, with nothing broken and nothing to see. Measured: 150 made-up values used to leave 150 copies behind, about 3 MB. Now they leave **none**. The fix is that a copy is only kept once the same page has been asked for a **second** time. A made-up value is asked for once and never stored. A real page is asked for constantly, so it is always kept — measured over twelve seconds of continuous traffic, the proportion of requests served from the fast copy was **99.1% either way**, before and after. Nothing was traded for this. No data was ever at risk from that: it was your shop's own public pages being pushed out of memory, never one customer's information reaching another. ### 1.4.3 — 2026-08-18 your shop can look up orders the fast way, and the panel stops asking things it already knows Update with `sixpanel server update`. Nothing to configure and no manual step. ### What you will notice - **Signed-in customers now get the fast pages too.** Your shop keeps a very short-lived copy of the pages that are the same for everybody — your settings, your policy pages, your zone and module lists, your banners. Until now that copy was only used for visitors who were not signed in. Anyone signed in on the app went the slow way on every single tap, which is most of your customers most of the time. Measured on a real shop, signed in, before and after: | page the app asks for | before | after | |---|---|---| | terms and conditions | 19.1 ms | **1.6 ms** | | privacy policy | 18.8 ms | **1.5 ms** | | top categories | 25.1 ms | **1.3 ms** | | the app's landing content | 24.1 ms | **1.3 ms** | | delivery zones | 15.7 ms | **2.2 ms** | Twenty-five pages got this, between 8 and 19 times faster each. Nothing to turn on, and it works whether your 6ammart code came from CodeCanyon untouched or from us — all twenty-six pages were checked against both. Anything that is about **one person** is deliberately left out and still goes the slow, correct way: your customers' own accounts, carts, orders, wallets, and the three listing pages that quietly change depending on who is signed in. Each page was checked by signing in as two different customers and confirming the shop sends them byte-for-byte the same thing before it was allowed to share a copy. - **Two ways the shared copy could have gone wrong, both found and closed before release.** One made it possible for a stranger to push your shop's saved copies out with junk web addresses, so your customers paid full price again — no data exposed, just the speed quietly undone. The other, briefly, could hand a customer asking for one page the contents of a different page. Both were caught by measuring the running shop rather than by reading the code, both are fixed, and the release now refuses to build if either can come back. - **"Your shop can be made faster" on the Database page, with a button.** A shop keeps shortcuts that let it find orders and products without reading through every row. Depending on where your 6ammart code came from, some of those shortcuts may never have been created — and the shop works perfectly well without them, right up until you have enough orders for it to matter. That is the trap: nothing looks wrong, and it gets slower as you get busier. Measured on a real shop with 66,000 orders and 113,000 order lines: one lookup the reports do took **27 milliseconds without the shortcut and 0.2 with it** — the same answer, 122 times the work. On the small tables there was no difference at all, which is why this never shows up on a new shop. The panel now checks, and if anything is missing it says so in one sentence with one button. If nothing is missing you will not see the card at all. It is safe to press on a busy shop: nothing is deleted or changed, orders keep coming in while it runs, and pressing it twice does nothing the second time. - **The install form fills in the branch by itself.** It used to guess `main`, which is wrong for a good number of repositories — and you found out several minutes into the install, after the download had already finished, on a branch you never chose. It now asks your repository which branch it uses, and offers the others in a list. If the repository is private, paste your access token and it will ask again. - **A failed install no longer asks you to retype everything.** The panel already remembered the repository address and branch from the attempt that failed. Now the form shows them, so retrying is one press. - **Your timezone and language are filled in from your browser.** The very first screen used to open with an empty timezone box and a list of some 420 zone names to type from memory. Your browser already knows both. You can still change either, and if your server should keep a different clock from your laptop, the box works exactly as it did. - **Small things that used to need a second attempt.** Choosing an email security setting now fills in the matching port. A Cloudflare token that needs an Account ID opens that box as soon as you paste the token, instead of refusing when you press Save. And the new shop's name starts as the project name you already typed rather than the generic "6amMart". - **A stuck background job can no longer switch off the panel's automatic repairs.** While a job runs — a deploy, a backup, an update — the panel deliberately repairs nothing by itself, so it never fights with work you asked for. But a job that got wedged and never finished held that pause open forever: scheduled backups quietly stopped, certificate renewal stopped, and every automatic fix stopped, with every page still green and your shop still serving. Nothing anywhere said so. Now a job still running after six hours releases the pause, automatic repairs resume, and the Health page tells you which job it is and what step it is on. **The job itself is not killed** — stopping something mid-way through is how a half-finished update happens, so that decision stays yours. - **`sixpanel server os-update` survives a dropped connection.** It ran as a child of your SSH session, so a closed laptop or a dropped wifi connection could kill it in the middle of installing packages and leave some half-configured — and if Docker's own packages were among them, the protection that stops your containers being restarted mid-update died with the connection too. It now runs detached, like `sixpanel server update` already did, keeps its output in a log under `data/`, and if it does fail it tells you the one command that finishes an interrupted install. - **Your apps get the shop's settings about twenty times faster once a customer is signed in.** Every 6ammart app asks the server for your shop's settings — its name, logo, currency, delivery rules — before it shows anything. The server already kept that answer ready to hand out instantly, but only for visitors who were *not* signed in. A signed-in customer's app sends its login token on every request, and the token made the server rebuild the whole answer from scratch each time. Measured on a real shop: a signed-out visitor got it in **2 milliseconds**, a signed-in customer waited **22 to 26** — for an answer that was byte for byte the same. Signed-in customers now get the same 1-2 milliseconds. This is the very first thing your apps do, so it is felt on every app open. Nothing personal is shared: only pages that are identical for everybody are treated this way, and each one is checked individually before it is added. Your customers' own pages — orders, cart, profile, the admin panel — are untouched and still built fresh every time. ### What you must do by hand Nothing. ### Under the hood - The index check decides by what an index can **serve**, not by what it is called. An earlier draft asked "is there an index named X?" and would have recreated an index this codebase deliberately removed — one whose columns a wider index already covers, so nothing could ever use it while every order written still had to maintain it. Names differ between installs; what an index can answer does not. - It only ever **adds**. Removing a redundant index is a real improvement, but from the panel there is no way to be certain some query on your particular code does not depend on it. An extra index costs a little on writes; a missing one costs an outage, so only the safe direction ships. - `sixpanel server update` output and every other behaviour is unchanged. ### 1.4.2 — 2026-08-17 your shop runs up to three times faster, and live order tracking survives an update Update with `sixpanel server update`. Nothing to configure and no manual step. ### What you will notice - **Up to three times faster, without doing anything.** Laravel keeps two generated files — a settings cache and a route cache — and without them it re-reads 39 settings files and re-registers 2,068 routes on *every single request*. Until now the only thing that rebuilt them was a successful "Update 6ammart" deploy, so a shop whose deploys were failing, or one that simply had not deployed since its last panel update, stayed slow indefinitely. Measured on a test server with a real 66,000-order dataset, same hardware, nothing changed but those two files: | | before | after | |---|---|---| | product search | 63.6 ms | **20.6 ms** | | store listing | 65.8 ms | **19.5 ms** | | app config call | 62.9 ms | **18.1 ms** | | requests per second | 28 | **90–97** | The panel now notices within about twelve minutes and rebuilds them itself, and a panel update rebuilds them on its way out. The Health page's "Performance caches" row will stop asking you to press a button. - **Live order tracking stays connected through a panel update.** Updating restarts the parts of your shop in groups so the site keeps answering, and the websocket — what the driver map on a live order uses — was in the wrong group. Measured from outside the server during a real update: the admin site was unreachable 13 seconds, the storefront 10, and the websocket **35**. Now 16, in line with the rest. - **A restarted service is ready sooner.** Containers that come back after an update now report themselves healthy in about two seconds instead of waiting up to a full minute, which shortens every update slightly. ### What you must do by hand Nothing. ### Under the hood - The panel repairs a missing settings or route cache by itself, and it decides **per app** whether the settings cache is safe to build: an app that still reads live settings the old way is given the route cache only, because caching its settings would silently blank the mobile apps' websocket credentials. - `install.sh --update` rebuilds the route cache that its own redis-password migration clears. - Websockets (`reverb`) now restart with the rest of the request path rather than behind the background workers. - Healthchecks probe every 2 seconds while a container is starting. - Three new automated checks cover all of the above, including one that measures the update outage from outside the server. ### 1.4.1 — 2026-08-17 the 2FA rescue, the rollback list, and two files this listing promises A same-day follow-up to 1.4.0. Nothing here changes how the stack runs; three things that were wrong are right. Update with `sixpanel server update`. Your `.env`, your data and your apps are untouched, and there is nothing to do by hand. - **`sixpanel panel 2fa off` now works in the case it exists for.** If you answered the enrolment screen with "Not now", there is no authenticator to forget — and the command returned without clearing the record of that skip, so the panel kept letting the next login in on the password alone, and the one command built to undo that could not. It clears it now, and tells you which state it repaired. - **Rolling back picks from a full list again.** Deploy history asked for the last ten entries and filtered them by repository afterwards, so ten could leave five to choose from — and those are the rows `deploy rollback last` picks its target from. Ten means ten now. - **`CHANGELOG.md` and `LICENSES.md` are in the download**, both named in the item description. `LICENSES.md` had been dropped by a rule that excluded every markdown file outside the manual, and there was no customer-facing changelog to drop. The build now refuses to package without either, so it cannot go quiet again. ### 1.4.0 — 2026-08-17 first stable release, published for everyone The first stable release, published for everyone: one command turns a bare server into a running 6amMart shop, and the panel keeps it running. **Nothing to do by hand.** Everything below 1.4.0 was an internal build that never went out, so there is no upgrade path to document — installing SixPanel installs this. ### What you will notice - Installing is one command on a fresh server, and it is the same command for everybody — no code and no checksum to paste out of an email. It works on Ubuntu 26.04 and 24.04 and on Debian 13 and 12, on Intel or ARM, and it refuses early and by name when something is wrong. When it finishes it prints your panel link, your username and your password, all generated for your server. - A six-step setup wizard opens by itself at your first login and takes about ten minutes: your basics, your own password, your domain, HTTPS, your 6amMart code, and a backup schedule. Every step has "Skip for now" and can be done later. - The install sizes the server for the hardware it finds — database buffer pool, Redis ceiling, PHP workers, PHP memory limit and queue workers all computed from real memory and processor count. Add memory later and the dashboard's Auto-tune card recalculates all of it on one press. - Free HTTPS from Let's Encrypt, and a shop can hold more than one name, each with its own certificate. Renewal runs on its own every night. Cloudflare is understood rather than fought: a name behind the orange cloud is recognised as pointing at your server and gets the right kind of certificate. - Deploying is a git push. Each repository gets its own webhook address and secret, and every install, update and rollback is recorded with its full log one click away. Rollback moves your code, not your database. - Backups are incremental and encrypted, and can go to four kinds of destination: this server's disk, S3-compatible storage, another server over SSH, or Google Drive. You can use more than one at a time. - The panel proves your backups instead of promising them. Every Sunday, on by default, it restores the newest backup into a throwaway database of its own, counts the tables and rows, then deletes the throwaway again. Your live database is never touched by the test. - A Health page runs a full check-up in one view — DNS, certificate expiry, every service, the database, the queue, the scheduler, disk space and more — and every failure carries a plain-language fix that names the page to go to. - A file manager for your shop's code, and only your shop's code. The stack's own files are not reachable through it at all. - An editor for 6amMart's own settings file that keeps the file's comments — they become the headings the editor groups settings under. Secrets stay hidden until you press Reveal, and the settings the server manages are shown but locked. - phpMyAdmin when you actually need it: not running until you start it, reachable only while you are logged in to the panel, alongside a database page with sizes, table counts, the biggest tables, slow queries, downloads and imports. - A `sixpanel` command-line tool for the times the panel itself will not open — with `sp` as a shorter name, Tab completion in bash and zsh, and a `man sixpanel` page. `sixpanel doctor` prints the same fixes the Health page shows. - The whole manual is inside the panel, on the server, behind your login — twenty-four pages, not a link to the internet. - More than one 6amMart shop on one server, each with its own PHP, queue, scheduler, websocket and storefront containers and its own database. Plan roughly 2 GB more memory and one or two more cores for each additional busy shop. - The panel repairs the handful of faults that take a shop offline, checking once a minute. Each repair has a daily ceiling and a cooldown, everything it does is in the audit log, and a service you stopped on purpose stays stopped. - Operating-system security updates and a reboot from the panel, with a preview of what will be installed — and updates to SixPanel itself from the same page. Neither needs SSH. - Cloudflare set up from the panel: paste one scoped API token and it reads your zone, says what every setting is now and what a 6amMart shop wants, and applies it. It only ever writes rules whose description starts with `sixpanel:`. - Access you can hand out without handing over your own password: a generated username, a 6-digit code from an authenticator app, temporary logins that expire by themselves, and a read-only demo login with secrets hidden from it rather than merely disabled. - The panel emails you when something needs you — a failed job, health turned red, the disk past 90 per cent, a lockout, a failed renewal — at most one message per topic every six hours, and an all-clear when it recovers. - A disk page that shows where the space went and a cleanup tick-list, with your customers' uploads and the database never touched. Plus scheduled tasks of your own, live order updates over websockets, a firewall page that hands you the exact rules to paste into your hosting provider's dashboard, and a transfer wizard for a shop that already runs somewhere else. - The panel is in eight languages: English, Spanish, Arabic, Portuguese, French, German, Indonesian and Bengali. ### Under the hood - Releases are signed, and the installer carries the key. It checks the signature before it runs a byte, and that check cannot be skipped — which is what actually protects a script running as root. The signed release also records the processor architecture it was built for, so a mismatched server is refused before anything is downloaded. - The manual is built and verified as part of the release. Every page is rendered into the artifact, and the build fails if the index promises a page the download does not contain. - Every health check must carry a fix, enforced by a test rather than by review. The eight panel languages are held at parity by another one, because a missing translation is displayed as its internal key. - The choice of operating system was measured, not assumed: three servers of identical hardware were each taken from bare metal to a live shop with the same real dataset, and no difference survived run-to-run noise. With speed a tie, what decides is how long each system keeps getting security updates — so Ubuntu 26.04 is the recommendation, with 24.04, Debian 13 and Debian 12 all supported. ## SixPanel Docker (retired) 1.3 — development milestones, never served to a customer ### 1.3.0 — 2026-07-27 (development milestone, not published) Development milestone, in testing only. The round that made the product provable: backups that restore, a stack that repairs itself, Cloudflare from the panel, and testing on real servers. ## SixPanel Docker (retired) 1.2 — development milestones, never served to a customer ### 1.2.0 — 2026-07-06 (development milestone, not published) Development milestone, in testing only. How the product reaches a server and defends itself once there: signed builds, the `sixpanel` command-line tool, a private panel address, and certificates that work behind Cloudflare. ## SixPanel Docker (retired) 1.1 — development milestones, never served to a customer ### 1.1.0 — 2026-06-22 (development milestone, not published) Development milestone, in testing only. Where the product started and became something you could run a server from: the stack a 6amMart shop needs, a panel to run it from, hardware-aware sizing, the health engine, every page live, eight languages, and more than one shop per machine.