Kontrol7

EmDash installs again on servers that cannot reach Google Fonts, and virtual-machine hosts can now take the Incus 7.0 upgrade like every other server.

Changed

• Servers that host virtual machines can be upgraded to Incus 7.0 LTS. They were held back in 1.263.0. They now upgrade in place, one at a time, like every other server, with their machines kept running.

Fixed

• EmDash installs on every server, including ones that cannot reach Google Fonts. Installing EmDash failed with "cannot fetch font file" when the server could not reach Google while building the site. EmDash's fonts now come with its own packages, so the build fetches nothing else, and your site still serves its fonts itself. If an EmDash install failed for you, press Reinstall EmDash on the website's Apps tab after updating.

Upgrading

After updating, press Reinstall EmDash on any website where an EmDash install failed.

Your servers can move to Incus 7.0 LTS, the long-term release of the container and virtual machine manager every server runs. Each server shows which incus it runs and where it comes from, and every site is checked whenever incus changes.

Added

• Upgrade a server to Incus 7.0 LTS from its page, or every server one at a time. Every site and container on the server is checked before and after. The upgrade stops at the first server that has a problem and says why. Running site containers keep running through the upgrade. On servers Standby looks after, the upgrade runs as a maintenance window, so customers are told.
• Each server shows its incus version, line and source. The server page always shows the installed incus, whether it is the 6.0 or 7.0 long-term line, where it comes from, and the last time it changed. A server that cannot take the upgrade says why (a kernel that is too old, or a virtual machine host not yet proven).
• Every site is checked whenever incus changes. Whoever changed incus on a server, whether the platform's own upgrade or a maintenance window, every site and virtual machine on it is asked whether it still answers. You are alerted if one stopped.
• Choose the incus line new servers get. A setting picks the long-term line new servers install: 7.0 by default, or 6.0.

Upgrading

• Nothing moves by itself. Existing servers stay on their current incus until you press Upgrade on a server or start the upgrade for all servers.
• Servers that host virtual machines are held back for now: moving a running virtual machine to the new incus has not been proven yet, and the page says so.
• Where it comes from: Debian 13 servers take Incus 7.0 from Debian's own backports; Ubuntu 26.04 servers take it from the incus maintainer's own packages (Zabbly).

Why

incus is what every website container and virtual machine runs on. Moving to 7.0 LTS brings servers onto the current long-term line, and you can now see and control it from the panel.

Updates and maintenance now work hand in hand with Standby. Customers can see a status page and are told before maintenance. Every restart of a site goes through one safety check. Mail keeps imported folders in the right place and can be shared between mailboxes. Object storage is billed. Database exports carry the whole schema.

Added

• Update now or Schedule, for the platform and for each server's operating system. On a server whose packages Standby looks after, Update now and Schedule ask Standby to update it at that moment or at the time you choose. You can do it per server, or for all of them at once. The platform's own update works the same way: it updates at once or at your chosen time, and Standby's maintenance list shows it either way. Standby's own monthly windows are shown alongside.
• A Status page for you and your customers. It shows the overall state, current incidents and upcoming maintenance from your status page. Each customer sees only what affects their own services. The sign-in page shows a short status line. Your servers stay hidden from the public status page until you choose to show them.
• Customers are told before maintenance that affects them. Customers are notified, in the panel and by email, when maintenance on servers that hold their services is booked, moved or cancelled.
• Shared mailboxes. A mailbox owner can let other mailboxes on the same domain open their folders, read-only or read and write.
• Inbox placement test, IPv6 sending and the warm-up ramp on the mail readiness card. The inbox placement test sends a test message to seed addresses and reports where it landed and how it was scored. IPv6 sending is used only when the server's IPv6 reverse DNS checks out. The warm-up ramp shows each sending address's daily limit.
• Object storage is billed and shown on the account page. Bucket usage counts towards the plan's allowance and appears in the usage feed. Buckets no longer also count against the account's disk. A full bucket is flagged.
• Managed or self-managed virtual servers. Managed machines are patched and backed up by the platform. Self-managed machines are the customer's own: the platform touches only power, network and snapshots.
• A second certificate authority as a fallback. When Let's Encrypt refuses or rate-limits a certificate, ZeroSSL or Google Trust Services can issue it instead, using your own account keys. It is off until you choose one.
• Software versions inside each site are shown. The PHP, Node, Python and web server versions running inside each site appear on the site and server pages.
• Customer backups get a second copy at Standby. When Standby offers an off-site backup target and it has passed a restore test, customer backups are copied there too.

Changed

• Every restart of a site goes through one safety check. PHP, Node processes, site containers and mail, FTP and DNS servers are restarted only through the same check web servers already used. The site is asked before and after, a change that would stop it is refused or undone, and each action is listed on the site and server pages. Unchanged settings no longer cause needless reloads.
• The application card on a website is rebuilt, and update checks say what was really asked. Buttons line up on desktop and stack cleanly on a phone. Remove and Reinstall sit in their own group. The Update button appears only when there is an update, and Check again asks the application itself to check with its publisher at that moment.

Fixed

• Imported mail lands in your own Spam, Sent, Trash and Drafts folders. Folders from other hosts, in any common language, are mapped onto yours. Duplicates left by earlier imports can be merged from the mailbox page.
• Database exports carry the whole database. An export now includes PostgreSQL enum types, foreign keys and sequences and MariaDB routines and triggers, so it loads into a fresh database anywhere.

Upgrading

• Standby version: the maintenance and status features need Standby v0.16.166 or later on the paired Standby. Until it has that:

  • operating-system updates on Standby-managed servers cannot be started from here;
  • the Status page stays empty.

  The platform's own Update now and Schedule work as before either way.

• Mail configuration: every mail server's configuration changes once after this update, to enable shared mailboxes.

• Virtual machines: each existing machine is labelled managed or self-managed from the plan it belongs to. Machines on no plan are self-managed: they keep any backup policy they already have but are no longer backed up automatically.

Why

Updating kstack or a server's packages is now one decision: update now, or pick a time. Your customers are told in advance, and nothing restarts a site without checking that it still answers afterwards.

EmDash, the modern CMS for websites and blogs, installs in one click - with its database, and a private setup link so nobody else can claim a new site.

Added

• EmDash is in the app catalogue as a one-click install. Pages, posts, media and menus edited in the browser, on its own PostgreSQL database made for it. Uploaded media lives beside the application, so an update keeps it. New installs run on Node 24; Node 26 is offered too.

Fixed

• Our test system now always tests exactly the code being released. A cached build from another branch could be reused when it should have been rebuilt. Files are now compared by content, so only what changed is rebuilt and nothing stale is ever tested.

Security

• A new EmDash site can only be set up from your private setup link. EmDash signs its administrator in with a passkey, so there is no password to show. Instead the install gives you a private link to create your administrator, and the Apps tab shows it again whenever you need it. Until somebody has used it, anyone without the link is refused - checked on every install before the site is switched on.

Why

EmDash creates its first administrator in its own setup wizard, and on a fresh site that wizard is open to whoever reaches it first. Installed here, only the person holding the site's private setup link can create that administrator.

A Node.js or Python website's version can now be switched from its Advanced tab, and the community forum app runs on Node 26.

Added

• Switch a Node.js or Python website's version from its Advanced tab. A Node.js site lists the Node versions the platform offers, narrowed to the ones the application installed on it runs on, so you are never offered a version it cannot start on. The site's files, database and settings stay as they are; its container moves to the new version on the server's next cycle.

Changed

• The community forum app installs on Node 26 and can be moved between Node 26 and 24. It had been held on Node 24 although it runs on both. An existing forum stays on its version until you switch it on the Advanced tab.

Fixed

• A version an application cannot run on is refused before anything changes. Asking for, say, Node 26 on a site whose application only runs on 24 or 22 is refused with the versions it does run on, rather than leaving a site that stopped answering.

Why

A Node.js site had no way to move to a newer Node version from the panel, and the forum app was held on Node 24 although it runs on 26.

Corrections from a page-by-page walk of the panel after 1.259.0: empty backups, leftover staging databases, deliberate suspensions and FTP certificates are now described as they actually are.

Changed

• Smaller wording fixes. The Jobs filter names each kind of job in words. A domain whose records were purged no longer offers a restore.

Fixed

• A site with FTP accounts now gets a certificate for its ftp address, however FTP was turned on. Turning FTP on from the FTP card didn't add ftp. plus the domain to the site's names, so FTP clients were shown a certificate for another name. Existing sites are corrected when you update, and their certificates are re-issued automatically.
• The Restore link on Backups opens the right page for every kind. A mail domain's Restore link opened the Databases list, and a database's opened the list instead of that database. Each one now opens its own Backups tab.
• A mail domain with no mailboxes no longer reads as a restore problem. Its restore check said its server did not answer. It now says there is nothing to restore yet. Compliance, the facts reported to your monitoring platform and the dashboard's backup coverage now count such domains separately, instead of as never tested or unprotected.
• A deleted staging copy's database no longer reads as "made by hand". The databases-nothing-uses list now says which staging copy the database belonged to, and that the copy was deleted.
• Suspending a site is no longer listed as something that went wrong. Activity treated a suspension you chose as a failure. Traffic now also notes that a suspended site's 503 responses come from its holding page, instead of colouring them as server errors.
• The firewall fact sent to your monitoring platform covers every machine. A machine with nothing on it yet, such as a VM host with no VMs, was left out of the count.

Why

Several pages described things that were fine as failures, and in one case a name people connect to was left without a certificate.

vir-forum now updates itself, and kstack's Update button simply asks it to. Your forum keeps the version it chose, rolls itself back if a new one does not start, and the Apps tab shows its own messages while it works.

Added

• Keep the forum's update token on the site. Paste a token made in the forum once. It is checked with the forum before it is kept, stored with the site's other secrets, and removed with the application.

Changed

• vir-forum updates itself; the Update button on the Apps tab asks it to. The button starts the forum's own update and follows it to the end, showing what the forum says at each step. A failed new version rolls back on its own and the site keeps serving. Without a token, the tab links to the forum's own Updates page.
• Repair works in the version the forum runs. It no longer fetches a version of its own choosing or moves the forum to one. It reinstalls what is missing in the running version and checks that it answers.

Fixed

• The forum's folder belongs to the site, so it can write its own new versions. kstack also no longer removes old versions from under a forum that is updating itself, and a forum process that exits after an update is always started again.

Security

• The Update button only ever talks to the server that hosts the site. It connects to the site's own server by address and uses the domain only to check the certificate, so a domain pointed somewhere else cannot redirect the request or its token.

Upgrading

To use the Update button on an existing vir-forum, create an API token with the update permission in the forum's Admin, API tokens, and paste it once on the site's Apps tab. Without a token, the Apps tab links to the forum's own Updates page. Press Repair once on an existing forum to hand its folder to the site, so it can write its new versions.

Why

An application knows best how to move itself to a new version and back again. kstack used to fetch and swap vir-forum's versions behind its back; now the forum owns its updates and kstack gives you one button to start one.

The panel now tells the truth about deliberate actions and about security: a site you suspend reads as suspended everywhere, the Security page shows how old each machine's virus signatures really are, and an empty mail domain no longer reads as a failed backup.

Changed

• The panel names things in plain words. Machine pages, Activity filters, Backups and the job list say "certificates", "backup policies" and "mail domain" instead of internal names. An update's routine re-apply is no longer described as a repair. Compliance names what is backed up, and Standby is named by its address.
• Object storage plans show how much each bucket holds, and dates on the Databases page use the panel's one date format.

Fixed

• A site you suspend reads as suspended everywhere, not as broken. The Websites list files it under its own Suspended filter in grey. Its health page says who suspended it and when, and stops blaming a memory limit or a stopped cache for a stop the suspension made. Its usage card and "Is it answering?" no longer show readings from before the suspension, and the suspension is not counted as recent trouble.
• The Security page shows how old each machine's virus signatures are now. It used to show the signatures the last weekly scan saw, so machines updated that morning looked days out of date. It now uses the age the machine itself reports every few minutes, and each machine's Security tab says where the age came from.
• A mail domain with nothing in it yet is not reported as a stale or failed backup. Backups and Compliance treat "nothing to back up yet" as exactly that, and an old restore check that failed only because there was nothing to restore is cleared.
• One refused change is one notification, not one a minute. A web server error repeated with a new timestamp on every attempt is now recognised as the same failure.
• A deleted domain's page opens and says it is no longer hosted, instead of failing to load.

Why

Each of these sent an operator looking for a problem that did not exist: a suspended site under "Broken", signatures that looked five days stale when they were updated that morning, and a backup "failure" for a mail domain with nothing in it.

Alerts say who did something, and something you chose to do is no longer an alert; every date in the panel reads the same way; form fields have a visible edge; and two libraries move past their security advisories.

Changed

• Every date in the panel reads the same way. Twenty pages showed dates in the browser's own format, such as "10/29/2026, 11:56 PM", beside "29 Oct 2026, 23:56 UTC" elsewhere. Every date now reads the second way.
• Activity names more events in plain words. Application updates and repairs, the off-site backup copy and plan changes now have a sentence of their own, and any event without one starts with a capital letter.

Fixed

• Suspending, resuming or removing a service on purpose is no longer an alert. When a person or a connected billing system suspends, resumes or removes a service, it is recorded in Activity as what it is - a decision - instead of sending an alert email, ringing the notification bell and opening an incident in Standby. The same action taken by the platform itself is still an alert.
• An alert says who did it. An alert with no reason of its own now names who made the change, instead of saying the event recorded no reason. Standby is sent the same name, so an incident never has to ask who triggered it.
• A suspended website is no longer reported as broken. A suspended PHP website was reported by its server as "every dynamic request will fail". It is now checked for its holding page only, which is what it serves on purpose.
• Form fields have a visible edge. Text boxes and lists in Settings and across the panel were almost the same colour as the page, so an empty one looked like plain text. They now have a clear border in every theme.
• Compliance facts read correctly. Counts agree with their words ("1 operator", not "1 operators"), and the control panel's backup facts say whether they are about its main copy or its off-site copy.

Security

• Two libraries move past their published security advisories. The DNS resolver library and the async runtime the platform is built on are updated to the releases that fix their advisories.

Why

Found by walking the live panel after 1.258.0: a site suspended on purpose came back as an alert email and an on-call page that could not say who had done it.

One bad website configuration no longer stops a server applying anyone else's changes, mail can move in from another provider without losing a message, buckets can be locked and emptied, VPS traffic is counted, cancelled accounts are cleaned up after a grace period, and the control panel's off-site backup is kept and tested by Standby.

Added

• Mail can move in from another provider without losing a message. While a domain moves in, mailboxes already copied receive their mail here and everything else is passed on to the old provider. When the domain's mail records point here, a final copy runs and the old provider's details are forgotten. If the domain's DNS is hosted here, the switch moves the records itself; otherwise the page says which records to set.
• Plan changes and add-ons have their own page. A subscription page shows the current plan, what a different plan would change and anything that would block it, and adds or removes extras - all said before anything is confirmed.
• Buckets can keep objects for a set time, hold single objects, and be emptied. A bucket created with object lock can have a default retention (governance or compliance, in days), and single objects can be put on hold. "Empty the bucket" asks for the bucket's name, refuses while anything is held and says until when, and shows its progress. Buckets now show on the website they belong to and on the customer's home page.
• A cancelled customer's services are removed after a grace period, each after a final backup. An account whose plans have all ended keeps everything for the grace period and is told the date once; it can come back until then. Afterwards every protected service is backed up one last time, and nothing is removed until that backup exists. Closing an account now also removes its buckets.
• The control panel's off-site backup is kept by Standby and tested. When the platform is paired with Standby, the control panel's off-site copy goes to storage Standby provides, with no setup. Every backup drill now restores both the main and the off-site copy, and the dashboard says when each was last copied and tested. A location typed in Settings still wins.
• Mail servers ask the blocklists themselves. Each mail server runs its own DNS resolver, so blocklists answer it, and checks its sending addresses every 15 minutes. The mail readiness card shows clear, listed or unknown for each list, with the reason; a list that refuses to answer reads unknown, never clear.
• Each website has its own page while nothing is published. A website with no content shows its own holding page rather than one shared by the whole server, and it can be switched to a development-environment page from the website's Security tab.
• Colleagues complete from the organisation's directory in webmail. Typing a name in To, Cc or an invitation now offers people on your own domain - and only your own domain.

Changed

• Every change to what a server serves is checked, and the last working configuration is kept. nginx, Apache, OpenLiteSpeed and LiteSpeed Enterprise changes are checked by the server itself, loaded, and confirmed to still serve; if not, the last configuration that worked is put back. A website whose configuration is refused is held back on its own and reported once, while every other website's changes go through. Before, one website's mistake could stop a whole server taking any change.
• Compliance verdicts come from Standby. The platform sends Standby what it measures - backup drills, certificates, isolation, firewall, mail authentication, DNSSEC, audited access and dependency advisories - and Standby decides what passes. The Compliance page links to Standby and lists the facts reported.
• A certificate held back by the request limit says so, and until when. When a certificate order waits because the domain has used its request allowance, the diagnosis and the certificate card say so with the time it will be asked for again.
• Settings are easier to read. Fields line up, empty fields say "not set", units sit beside the value with a plain reading under large numbers, help is cut to its first sentence with More for the rest, changed values are marked, and option names replace codes. The nameserver table shows each nameserver's machine, its addresses and whether it resolves now.

Fixed

• A server behind nginx is asked once more before a visitor sees an error. When Apache, OpenLiteSpeed or LiteSpeed Enterprise behind nginx restarts, a page request it drops is sent to it again instead of showing the visitor a 502. Form submissions are never sent twice. OpenLiteSpeed that stops answering after a restart is now noticed and started again.
• A missing page behind nginx shows your error page, not the server's own. With nginx in front of Apache or OpenLiteSpeed, a missing page showed the server's built-in 404. It now shows the website's own error page, or the platform's. An application's own 404 page is still passed through untouched.
• A new bucket key always works before it is shown. The new secret key is set on the storage server and tried before the panel reveals it; if that fails, the old key keeps working.
• VPS traffic is counted. Traffic for virtual servers was never measured. It is now counted, shown on the VPS page with a traffic and a firewall card, included in the monthly usage export, and flagged once when a plan's allowance is passed.
• The usage figures billing reads now include bandwidth. The account usage read reported bandwidth as "not measured" on every install. It now reads the same figures the monthly export bills, for websites and virtual servers.
• Roundcube's database is set up on Debian 13. The setup step Roundcube relied on is missing on Debian 13, so its database was never created and sign-in failed. The packaged schema is now loaded directly.
• An installed application's own files are left alone. A website running an installed application no longer gets the platform's placeholder app put back when it is removed, and the Overview and the Apps tab now agree on whether the application is running.

Security

• Websites can no longer reach each other over IPv6. Traffic between website containers is now refused over IPv6 on every address, as it already was over IPv4. A neighbour could otherwise have handed the websites on a server an address of its own choosing.
• Password guessing on Roundcube webmail is slowed down. Repeated failed sign-ins on Roundcube are now paced the way they already were on the other webmail engines.

Upgrading

Cancelled accounts are now removed after a grace period: Settings → Hosting → "Remove a cancelled customer's services after (days)", default 30; 0 keeps them for ever. The clock starts when this version first sees an account, so no account that is already cancelled loses anything sooner than 30 days after the update.

Why

This release finishes the platform's outstanding work list in one update, with every web server, database engine, DNS server, webmail and backup store tested before it shipped.

New websites get their certificate reliably, an app whose process name has a hyphen no longer stops its server applying changes, and websites on the same server can no longer reach each other.

Fixed

• A new website's first certificate waits until the website can answer for it. The certificate was requested before the server had set up the new site, so the certificate authority's check failed and the site kept a placeholder certificate. The platform now checks first, without spending one of the domain's attempts, and asks once the site is ready.
• An application whose process name contains a hyphen no longer stops its server from applying changes. Installing vir-forum made the server's web configuration invalid, which held back every change on that server until fixed.
• vir-forum shows the version it is installing from the start. The Apps tab briefly showed an old version number until the install had fetched the release.

Security

• Websites on the same server can no longer connect to each other. Each website's container could open connections to its neighbours' services on the same server. All traffic between them is now refused; each website still reaches the internet and its own services.

Settings is easier to read: sections down the left, one row per setting, and the glue records your registrar needs, by nameserver name.

Changed

• Settings sections are listed down the left instead of six rows of tabs. Each setting is now one row: what it does on the left, the field on the right, with its unit beside it ("seconds = 1 week"). Long explanations open under More, and a setting you've changed says so.
• The nameserver page lists the glue records by nameserver name. Each nameserver (ns1, ns2) is shown with the machine behind it, its IPv4 and IPv6 address, and whether it already resolves there. It warns when two names share one machine.
• Clearer DNS setting descriptions. Every DNS setting has a short explanation and a unit on its number.

Idle LiteSpeed sites now really drop to no PHP process, and a server's page names Node.js and Python websites correctly.

Fixed

• The platform's own health check no longer keeps an idle site's PHP awake. A site running lsphp is checked through PHP every 30 minutes instead of every minute. In between, the check uses a path that doesn't start PHP, so a site nobody is visiting holds no PHP process for most of the time.
• Node.js and Python websites are named as applications on a server's page when OpenLiteSpeed is the front door. They read "it may be a static site" on servers using OpenLiteSpeed in front.

OpenLiteSpeed and LiteSpeed Enterprise websites on PHP 8.1 and newer now run LiteSpeed's own PHP, and an idle site holds no PHP process at all. vir-forum joins the app catalogue as a one-click install with its licence.

Added

• LiteSpeed's own PHP (lsphp) for OpenLiteSpeed and LiteSpeed Enterprise sites on PHP 8.1 to 8.5. PHP now talks to the web server over LiteSpeed's native connection, using LiteSpeed's own builds with ionCube, imagick, redis and the other extensions. Your PHP settings and .user.ini apply as before. Sites on PHP 8.0 and older, and sites served by nginx or Apache, keep PHP-FPM.
• PHP starts on the first request and stops when idle. An idle LiteSpeed site holds no PHP process at all: the first visitor starts PHP, and it exits after 5 minutes without requests. PHP-FPM no longer runs next to it, which frees most of the memory an idle site used.
• Every site moves to lsphp only after it is shown to serve, and goes back by itself if it fails. A site switches only when its own check says it serves, and is watched for 15 minutes after. Two failures in a row put it back on PHP-FPM, with the reason shown on the server's page.
• vir-forum, a self-hosted community forum, installs from the app catalogue with its licence key. The key is checked with the update service before anything is created. A wrong key, or one for another domain, leaves the site untouched and shows why. Every release is checked against our signing key, and the licence is kept as a site secret. Until you set SMTP in the forum's admin, its sign-in emails go to its log.

Fixed

• The update log's timing table names each step properly. It read "downloading v" and "verifying v"; the version no longer cuts the step's name short.

Update the cluster now always updates the secondary nameserver before the primary, and a Node.js or Python website is named as an application on its server's page.

Fixed

• Update the cluster takes the secondary nameserver before the primary. When your nameservers' names weren't in the published list, the order fell back to machine names and could put ns1 first. The number in the nameserver's name now decides, so ns2 is always updated before ns1.
• A Node.js or Python website is named as an application, not "maybe a static site". A server's page now says the site is an application served by its own process, and gives the address that process answers on.

One button now updates the software on every server, one server at a time. Each database is backed up first, each server is checked afterwards, and the run stops at the first server that does not come back the way it was.

Added

• Update the cluster: every server's packages updated one at a time, from the Updates page. The secondary nameserver goes before the primary, so your zones keep answering throughout. Then database, web and mail servers. The card shows the order before you start and each server's progress while it runs.
• Every database is backed up right before its server is updated. The backup is taken through the database's own backup policy. If a live database has no policy, the update stops before that server changes anything. Staging copies are refreshed from live and don't need a backup.
• Each server is checked after its update, and the run stops at the first one that fails. Every role on the server must be ready and serving. Every site that answered from outside before the update must still answer. If anything doesn't come back, you get an alert naming the server and what failed, and the servers after it are left untouched. A Stop button is there while it runs.
• Pinned packages stay at their version. List packages to hold back. They are kept at their current version through the cluster update and through each server's own Update packages, then released again, so automatic security updates still reach them.

Added

• The platform's own software on the Updates page Every machine now reports its service packages - nginx, OpenLiteSpeed, LiteSpeed, Apache, Redis, MariaDB, PostgreSQL, PowerDNS, Postfix, Dovecot, Rspamd and the rest - with the version installed, the version its sources offer, and whether that is a security update. The Updates page lists each newer version per machine. It is read from each machine's own package sources every half hour and changes nothing on it. Updating the whole cluster one machine at a time builds on this.

Fixed

• A prepared site download clears itself A download prepared on a site's Files tab - a complete copy of the site, its database included - is removed by the server after a day if nobody throws it away.
• Nothing to back up is not a failed restore A mail domain or site whose backup has nothing to protect yet no longer shows a failed restore drill on the Dashboard or the Backups page, even where an older drill had failed.

Added

• A site download that moves anywhere "Prepare a download" on a site's Files tab now carries its database as well as its files, for every application (WordPress, Joomla, Ghost, Flarum, NodeBB, Wiki.js) on MariaDB or PostgreSQL, dumped with the database's own tools. Only the version that runs travels, without packages that can be fetched again. No password is in the archive, nor in the configuration files inside it. Upload it on the Import tab of a new site on another kstack: the site gets its own database, the data is restored, and the application is set up for the new address. Earlier archives still import.
• A stuck PHP site recovers by itself When every PHP worker of a site has been stuck for ten minutes and pages that need PHP stop answering, the server restarts that site's PHP - at most once an hour - and the notification says what each worker was waiting on, so the cause can be found.

Changed

• Notifications say what happened, in one sentence A failed build no longer pastes its whole log. An alert that later recovered says "resolved" and leaves "Needs a look". A changed platform file is named. A failed application update appears in the feed and says the site kept running its version. A mail domain with nothing to back up is no longer reported as a failed backup.
• Every page says what it counts The Dashboard names the backups without a recent snapshot and what a failed restore drill was of. Security lists the platform's own library advisories and names machines whose antivirus signatures are stale. Applications counts failed updates apart from failed installs, and sites behind a newer release. Backups shows its snapshot count. Databases calls a staging copy's database "Staging copy", not "No backup". Domains labels staging copies. Plans says prices live in Zephyr once, why a kind is Preview, and that the plan decides over a platform default such as Redis. Users offers two-factor next to an account without it. Ask shows its own spend.
• Tidier pages Settings sections are grouped under five headings. A website's Domains tab is in three parts. Virtual machines are added from a button at the top. Branding's sign-in page is one form with its own Save. Help describes the Staging tab, dev websites and publishing. More blocklists can be watched: UCEPROTECT level 1 and Mailspike.

Fixed

• New PHP sites no longer hang behind an OpenLiteSpeed or LiteSpeed front Keep-alive between the web server and PHP is off by default; a site's own setting can still turn it on.
• After an application update, the new version is the one that runs NodeBB and other Node applications are started fresh once the update is in place, instead of carrying on with the previous version.
• Old application versions are removed An update keeps the version now running and the one it replaced. Sites already carrying several old versions are cleaned up within the hour, which frees their disk.
• mta-sts. answers only its policy The address sending servers use to fetch your MTA-STS policy no longer shows the webmail sign-in, and tells search engines not to index it. Webmail sign-in pages also ask not to be indexed.
• The ftp name only where FTP is served The ftp. record is published only for a site that serves FTP, and switching FTP off takes the name out of the site's certificate.

Security

• Known advisory without a fix RUSTSEC-2023-0071 (rsa, the "Marvin" timing attack) has no fixed version yet; why it does not expose this platform is written up in docs/security/rsa-marvin.md.

Dev websites are a choice on the New website form, and the form is laid out properly. Application updates now keep a site's own themes and plugins, and new releases are noticed without anyone pressing Check.

Added

• A dev website is a choice on the New website form. Choose A dev website and type only a name; the site is made on the platform's dev domain with no email, FTP or www, so its certificate arrives straight away. The websites list marks it DEV.
• Applications are checked for new releases every six hours. NodeBB, Wiki.js and Flarum are compared with their publisher's newest release on their own, so an update shows on the Apps tab without anyone pressing Check.

Changed

• The New website form is laid out in sections across the whole card. Address, Application and Server, with the domain first, one line of help per field, and Create on the right. The button says it is working and cannot be pressed twice.

Fixed

• Updating NodeBB keeps the site's own themes and plugins. An update built the new version from NodeBB's own package list only, so a site's theme went missing and the update stopped. The new version now takes every theme and plugin the running one has.
• An update that does not finish no longer marks the application as failed. The running version keeps serving, and the Apps tab says in one sentence why the update stopped, instead of showing a build log and offering Reinstall.

Staging now has its own tab. A website built on the staging domain can go live on a real domain in two presses. Pushes to live bring a theme's images and fonts, and the check after a push no longer reports a false difference.

Added

• A dev website can be published to a domain of its own. A website built on the staging domain gets Publish to a domain on its Staging tab:

  1. Type the domain. A new website is made on the same server, with its certificate and backups.
  2. Copy the dev site into it: files, all its data and the application.

  The dev site then becomes the new site's staging copy, so later changes go live with the ordinary Push to live.

Changed

• Staging has its own tab on every website. The Staging tab is where you:

  • open a copy of a website;
  • copy the live site into it;
  • push it live.

  The Studio tab now holds only the coding agent connection and the git remote.

Fixed

• A theme pushed live brings its images and fonts with it. On a NodeBB forum, a theme pushed from staging reached live, but its logo and fonts were missing. They come with the push now.
• The check after a push no longer reports a false difference on Flarum. Flarum builds the site's own address into its scripts, so the check said live still differed from staging even when they matched. It now compares those files with the address taken into account.

Push to live now takes a staging website live as it is (files, the application's theme, plugins and settings) and shows when it is done. Ghost and Joomla staging copies get their own database. Sites made before their server had containers get their own Redis.

Added

• Push to live takes your application's settings with the files. When you push a staging website live, the theme, the plugins or extensions switched on, and their settings go live too. Supported applications: WordPress, Joomla, NodeBB, Flarum, Ghost and Wiki.js.

  • New tables a plugin made on staging are created on live.
  • Content stays the live site's own: posts, comments, users, orders and members.
  • The application is then restarted, or runs its own update steps, so the change shows straight away.
  • Choosing a theme in the admin changes no files, and is now pushed too.

• Push to live says what it did, and checks it. The Push staging live button is always visible on the live site's Studio and Advanced tabs. The staging copy's own page links to it.

  1. Pressing it compares the two sites and shows what would change.
  2. You confirm the push.
  3. The card follows the push to the end: files written, settings taken, and whether the live site now serves what staging serves, with how many seconds that took.

  The buttons are disabled while a push is running.

Fixed

• Ghost and Joomla staging copies have a database of their own. Until now, a Ghost or Joomla staging copy still used the live site's database, so a change made in the copy's admin changed the live site.

  A staging copy now gets its own database filled from live, and its configuration is rewritten for the copy. A copy that cannot be made safely is refused with what to do.

• Sites made before their server had per-site containers now get their own Redis. Within about 15 minutes of updating, each such site gets its own Redis. The application on it (Flarum, Joomla or WordPress) is then switched to use it. A site created with Redis off, or whose Redis was turned off, is left alone. The Redis card on the Advanced tab says why a site has no Redis.

• A database restore that worked is no longer reported as failed. Restoring a larger PostgreSQL backup could finish correctly and still be reported as failed. It is now reported as done.

Why

Test a plugin, a theme or a template on a staging copy, press one button, and see it on your live website seconds later. Your visitors' posts, orders and accounts on the live site stay as they are.

PHP websites on OpenLiteSpeed or LiteSpeed can now choose how the web server connects to PHP.

Added

• A PHP website on OpenLiteSpeed or LiteSpeed can choose whether its PHP connections stay open between requests. The PHP connections setting is on the website's Advanced tab.

  • On (the default): the web server keeps its connections to the site's PHP open and reuses them for later requests.
  • Off: each request opens its own connection and closes it once the page is sent, the way Apache and nginx always work.

  Each open connection holds one PHP worker for as long as it stays open. If a site's pages hang while its What it is doing right now card shows every worker waiting with no request, try turning this off. The API takes POST /v1/resources/{id}/fcgi_keepalive with {keep: true|false}.

Changed

• A PHP request stuck waiting for its own upload is named as such. "What it is doing right now" now tells apart a worker waiting on its web server for the rest of the request - a form or upload whose body never finished arriving, so the application has not started on it - from one waiting on a database or another server.

Fixed

• The Security page opens straight away and shows Standby's posture score. The page now shows the last posture score Standby gave at once and refreshes it in the background, so it never waits on Standby. When Standby could not be reached, the card says so and shows its last score. Standby is named by its own address everywhere on the page.

Changed

• "What it is doing right now" says what each PHP worker is waiting on. Each worker now shows where it is waiting in plain words - a file lock another request holds, a network answer, a program it started, the disk - so a stuck request points at its cause. A worker that is idle shows how long its previous request took, labelled as such.