KStack

Security release. Update promptly.

Mail sent from phones and desktop mail apps now goes through the same sending limits as every other message, so one stolen mailbox password can no longer be used to send unlimited spam from your mail server.

Fixed

• Each message is counted once, whichever port it arrives on. A message passes through exactly one sending check, so limits mean what they say.

Security

• Mail apps on ports 587 and 465 are now rate-limited, cut off automatically and held to warm-up caps. The limits that already applied to port 25 and to webmail now apply to every authenticated mail client. A mailbox that suddenly sends far more than usual is deferred and then stopped, exactly as on the other ports.
• Sending is charged to the mailbox that signed in, not to the address the client typed. A client can put any sender address, or an empty one, on a message. Mail is now counted against the signed-in mailbox's domain, so an empty sender can no longer slip past the limit. When a domain is cut off, the event names the mailbox whose password should be changed.

Upgrading

Nothing to do. Mail nodes apply the change on their first cycle after their agent updates. Limits are set per mail domain, so a mailbox that trips its domain's cut-off stops that domain's outgoing mail until sending is resumed from the mail domain's page.

Why

Your mail server's sending reputation is shared by every customer on it. Until this release, mail sent through the submission ports that phones, Outlook and Thunderbird use was not rate-limited, could not be cut off automatically, and ignored the IP warm-up caps. That meant one phished password could put your sending addresses on blocklists.

The Studio tab on a website now describes accurately how coding agents connect and how changes go live.

Fixed

• The Studio tab says how Claude Desktop and claude.ai connect. The tab said their sign-in was not available yet, but it already worked. To connect, add the panel's address followed by /v1/mcp as a custom connector in Claude, sign in to the panel when it asks, and choose the website. This creates a connector that is listed on the tab and can be revoked there.
• The Studio tab says how a staging change goes live. The tab pointed to a promote button on the Backups tab, which does not exist. For a WordPress site, going live is Push back to production on the Apps tab. It shows what would change, takes a snapshot of the live site first, and needs a backup policy.

Incidents opened in a paired Standby close when the problem clears, every time.

Fixed

• A recovery always reaches Standby, so its incident closes. A site answering again, a node returning or mail sending again was sent to Standby once; if that one delivery failed, the incident stayed open there for good. Recoveries are now re-sent on every dispatch until Standby accepts them, and incidents left open before this update are closed on the first run.
• A problem that comes back is reported again. An outage that returned within an hour of recovering was dropped as a duplicate, so Standby showed it resolved while it was down. It is now always reported.
• A removed site or node closes its open incident. When something with an open incident is deprovisioned or retired, kstack now closes the incident in Standby instead of leaving it open.

Upgrading

Expect a one-off burst of catch-up recoveries to Standby on the first runs after the update; recoveries for incidents already closed do nothing.

Virtual servers now respect suspension and their owner's power choice, mail domains whose DNS lives elsewhere get their certificate, malware scans reach every server, webmail can be installed as an app, and a background repair that ran every hour for nothing has stopped.

Added

• Mail domains whose DNS is hosted elsewhere get a certificate. If a customer's DNS is with another provider, mail.<domain> now gets its own certificate, so mail apps and webmail connect securely under the customer's own name. Nothing is ordered until that name points at your mail server, and the domain's page says what it is waiting for. Webmail must be switched on for the mail server, because the certificate is verified through it.
• Webmail can be installed as an app. Each domain's webmail now offers itself as an installable app, named after the account's brand, so customers can add it to their dock or home screen and open it in its own window. Requires the matching webmail release (kmail 0.5.0).
• Old revoked API keys can be cleared out. A new retention setting removes API keys that were revoked or expired long ago (400 days by default), but never one that any record still points to. Records of accepted terms are kept for ever by default.

Fixed

• A suspended virtual server is stopped. Suspending an account (or a single virtual server) now stops its machine. Resuming starts it again in the power state its owner had chosen, so a machine they had turned off stays off. The virtual server's page says when it is stopped because of a suspension.
• A virtual server its owner turned off stays off. Turning a machine off from inside (for example with poweroff) is now respected. Before, it could be started again whenever anything else on the same server changed. It now starts only when someone presses Power on or Restart, or after the host server itself restarts.
• Malware scans reach every server, not only web servers. Scans of database, mail, DNS, backup and telemetry servers were failing because they asked for a folder only web servers have. Each server is now asked to scan what it actually holds.
• An existing mail certificate is found again. A mail domain could say no certificate had been requested while its mail address was serving a valid one. The platform now links such a certificate back to its domain so it renews, or restores one left behind by a deleted copy of the domain, without ordering a new one.
• An hourly repair that never finished has stopped. After a mailbox or DNS record was edited, the platform could think the change had not reached the server and re-send it every hour for ever (shown as "platform healed" in Activity). Changes are now recognised as applied, and records hosted with an outside DNS provider are left to that provider.
• Backup storage figures are kept up to date for every account. How much backup storage each account uses was measured unevenly, so a small customer's figure could be weeks old under "measured daily". Every account is now measured in turn, about daily.
• The website page gives a database address that works. The database host shown on a website's page is now the server's published name, which resolves from anywhere, instead of a short machine name that only worked on the server itself.
• A brand name containing a dollar sign no longer breaks webmail. A brand name such as "Cash$Flow" made the mail server's web configuration invalid. Such names now fall back to the domain name in the webmail page title.
• Dates and numbers display the same everywhere. Dates are shown in one consistent format (with the exact time when you hover), which also removes page errors caused by the server and the browser formatting dates differently.
• The DNSSEC check no longer stalls on a silent nameserver. Checking whether a domain is signed now asks all nameservers at once with one time limit, so one that does not answer can no longer hold up the page. A nameserver that did not answer is shown as not answering, never as unsigned.

Security

• Two panel dependencies updated for security advisories. The image library and the source-map library used by the panel were updated to releases that fix two high-severity advisories.

Upgrading

Nothing to do. After the update: virtual servers belonging to suspended accounts are stopped on their server's next cycle, and they start again when the account is resumed. A virtual server that its owner had turned off from inside may be started once on the first cycle after the update; after that it stays off until someone presses Power on. Mail domains whose DNS is hosted elsewhere get a certificate request automatically. The certificate is only ordered once the mail address points at your mail server; until then the domain's page says what it is waiting for. Installing webmail as an app needs the matching webmail release (kmail 0.5.0) on your mail servers.

Why

Several things that looked fine in the panel were not doing what they said: a suspended virtual server kept running, mail for domains with outside DNS had no certificate, and most servers were never actually scanned. This release makes each of them do what the screen promises.

WordPress sites get back core files a faulty download left out, the control panel's page views reach Zephyr's analytics without any setup, alarms can no longer go unannounced, and webmail is branded from the first visit.

Added

• Your control panel's page views are counted by your billing system automatically. When the panel is paired with Zephyr, Zephyr now tells the panel its own address and the panel counts its page views in Zephyr's analytics. Nothing has to be configured. The Integrations settings page says whether the panel is being counted and, if not, why not.

Changed

• Webmail is branded before its certificate arrives. Before a mail domain's certificate is issued, webmail was served without your branding, page title or security headers. It now looks the same from the very first visit.
• A cleaner browser-tab icon. The control panel's tab icon no longer has a black square behind it; it adapts to light and dark browsers, matching webmail's.

Fixed

• WordPress sites are no longer missing 23 core files. WordPress 7 installs made by the platform were missing 23 files from WordPress's new built-in AI library, with copies under cut-off names beside them, because the download was unpacked by a tool that shortens long file names. WordPress is now downloaded in a format that keeps every name. Check and repair restores the missing files on existing sites from your installed version, removes only the cut-off copies, and reports the result of WordPress's own checksum check. Your themes, plugins and uploads are never touched.
• Alarms are never recorded without being sent. An alarm, such as a certificate about to expire or a disk filling up, could be marked as raised without its notification ever being written if something failed in between. Then nobody was told and it was never retried. Both now happen together or not at all.

Upgrading

After your web nodes update, press Check and repair on each WordPress site once. It puts back the core files described below and removes the stray copies; the WordPress card then says the core files match WordPress's own checksums.

Webmail now serves your brand's font from your own mail server, so no visitor is sent to Google any more, and PostgreSQL databases show their version and collation.

Fixed

• PostgreSQL databases show their version and collation. The databases list showed a version and collation for every MariaDB database and nothing for PostgreSQL ones, and the database's Collation card said "not reported yet" indefinitely. Database servers now report both for PostgreSQL. The collation is shown read-only, because PostgreSQL cannot change it after creation.
• The kmail sign-in page applies the brand font reliably. The brand font used to reach the kmail client in a way the browser discarded; it only looked right because another stylesheet happened to be applied after it. The font now comes from the branding stylesheet directly.

Security

• Webmail no longer loads branded fonts from Google. When an account's branding names a font, webmail at mail. used to fetch it from Google Fonts, which sent every webmail user's IP address to Google. The mail server now serves the font itself, from the same address as the page, in Latin, Latin Extended, Cyrillic and Greek wherever the font has them. The webmail's security policy no longer allows any font host, and Google is off the sub-processor list.

Why

Loading a font from Google sends every visitor's IP address to Google. The control panel stopped doing this in 1.216.0; with this release webmail stops too, so neither the panel nor webmail contacts Google.

The panel no longer contacts Google for its fonts. Operational records that used to be kept forever now have a retention window you control. NodeBB no longer runs out of database connections.

Added

• Retention windows for operational records. Records that used to be kept forever now have a retention window and a daily cleanup: DMARC and TLS reports, abuse complaints, notification deliveries, AI usage, resolved security findings, site and VM checks, sign-in codes, server commands, and expired data exports. Each window is a setting under Settings → Data retention, and 0 keeps that record type forever, for example under a legal hold.

Fixed

• NodeBB no longer runs out of database connections. NodeBB opens two connection pools, and a repair starts a second copy beside the running one, so a database at a plan's usual limit refused it with "too many connections". Each pool is now capped, and NodeBB's database is given enough connections for an install and a repair, including installs made before this release.
• The default backup retention setting is labelled in days. It always meant days, not a number of snapshots, and now says so.

Security

• The panel serves its own fonts and never contacts Google. Every font the panel uses is served by the panel itself, including the font a reseller chooses for its brand. Visitors' IP addresses no longer go to Google, and the panel no longer depends on Google being reachable. Latin, Cyrillic and Greek are included where the font supports them, each downloaded only when a page uses those characters. Webmail still loads its branded font from Google for now.

Upgrading

The first daily cleanup after this update deletes records older than their window. Node commands and login codes are kept for 30 days; notification deliveries and site and VM checks for 90; DMARC and TLS reports, complaints, resolved security findings and AI usage for 400. AI usage is never trimmed below 366 days. To keep any of them for longer, change its setting under Settings → Data retention before updating; 0 keeps that record type forever. The audit log, open security findings and anything still in progress are never removed.

Why

Privacy: every visitor to the panel used to load fonts from Google, which sent their IP address to a third party nobody chose. Records with no retention period cannot be described honestly in a data processing agreement.

A platform can now choose to receive release candidates before a release reaches everyone else. Security headers keep includeSubDomains when you save them, and sites that lost it get it back.

Added

• A release-candidate update channel. Settings has a new update channel, stable or release candidate. A platform on the stable channel is never offered a release candidate. A test server on the release-candidate channel can take each release first, so the platform your customers use only updates once the release has been proven.

Changed

• The package-source card says when a source serves no role on that server. For example, a PostgreSQL source declared on a server that holds no database role now says that nothing installs from it there.

Fixed

• Saving a site's security headers no longer removes HSTS includeSubDomains. The Security card had no includeSubDomains control, so every save turned it off. The card now has the control, and a save that does not mention it keeps what the site had. Sites whose last change from the panel stripped it get it back automatically. A value set deliberately through the API is left alone.

Removed

• The old per-role node install scripts are gone. Servers join from the one-line command the panel gives you, and their roles are chosen in the panel. The old scripts were no longer used and depended on a storage image that no longer exists. The cluster set-up guide describes the current way.

Upgrading

Nothing to do. The release channel defaults to stable, so nothing changes until you choose otherwise. The channel setting takes effect from the update after this one.

Why

Release candidates let a platform test each update on a test server before the server its customers use takes it. The HSTS fix closes a gap where saving a site's security settings quietly weakened them.

The panel and the catalogue now say which products are generally available and which are still in preview. A server that comes back after going quiet is recorded as back, so the alert it raised can close. Every release is now checked by the full test suite before it ships.

Added

• Products and features are labelled GA or Preview. Shared hosting, reseller hosting, databases and DNS are generally available. Virtual servers, email and object storage are in preview, and so are Cloudflare DNS, AI endpoints, the Ask assistant, Zephyr on a virtual server, and private networks. Each preview carries a one-line reason. The label shows in the plan editor, the plans list, the ready-made plans and on each preview feature's page. The catalogue that billing reads carries the same label.
• A Network cards panel on each server's Network tab. It shows each physical network card, its driver, whether the platform's workaround for cards that stop sending is in place, and when the card last hung and was reset.

Changed

• No idle OpenLiteSpeed server on hosts whose sites run in their own containers. Each site's OpenLiteSpeed runs inside its own container. A copy on the host served nothing and used memory, so it is no longer installed there, and one already running is stopped and disabled. Nothing is removed. Servers without per-site containers are unchanged.
• Malware scans send each path once. Scans requested through Standby no longer repeat their last path. That repeat was a workaround for a bug in older Standby agents, and every server now runs the fixed version.

Fixed

• A server that comes back after going quiet is now recorded as back. Until now only the 'went silent' event was recorded. The matching 'returned' event never was, so the alert raised when a server went quiet never closed by itself, here or in Standby.

Upgrading

Nothing to do. Web servers that run each site in its own container stop an unused OpenLiteSpeed server on the host, if one is running, on their next cycle; nothing is uninstalled.

Why

This release is part of the work towards general availability. It makes the product honest about what is finished, and it closes gaps in how servers report their own state.

kstack now installs on Debian 13 and Ubuntu 26.04 LTS with two lines: your licence key, and one command.

Added

• Two-line install on Debian 13 and Ubuntu 26.04 LTS. Set your licence key, run one command, answer three questions (panel domain, certificate email, admin email). The installer sets up the database, HTTPS, the firewall and the services itself. See the install guide.

Changed

• Updates on Debian and Ubuntu work exactly as on Alpine. Use Updates in the panel or run kstack-update on the server. Updates never install by themselves.

Fixed

• The node agent runs on every supported server system, whatever the panel server runs. The agent your panel hands to new servers is now built to run on Alpine, Debian, Ubuntu and Rocky alike.

Upgrading

Nothing to do on existing installations. New installations: follow the install guide (INSTALL.md).

Why

Debian and Ubuntu are the long-term choice for a hosting platform: years of security support, the same system as your web servers, and the best performance for kstack's database and services. Installing used to mean downloading and unpacking a release by hand, on Alpine only.

Malware scanning that actually runs: on servers Standby monitors, Standby now scans the whole machine with ClamAV, and kstack shows whether that scan really happened.

Changed

• The Security page counts a machine as scanned only when its whole-machine scan really ran. Where Standby is responsible for that scan, the page says so and shows how long ago it last finished, or that it never has.
• kstack no longer installs its own malware scanner on servers Standby looks after. One owner per scanner avoids two systems configuring the same engine on the same machine.

Fixed

• Machine scans on servers Standby monitors are no longer refused every week. kstack now asks Standby to scan only the website folders it is allowed to ask for. The rest of the machine is scanned on Standby's own weekly schedule.
• Scan refusals are explained correctly. A refused scan now says which folders were refused and why, instead of pointing at an unrelated, long-fixed problem.
• The control plane's health check answers from outside. /healthz used to be redirected to the panel's sign-in page, so external monitors never received a healthy answer. After this update it reaches the control plane and returns 200.

Upgrading

Nothing to do. The health-check route is added to nginx by the updater, which validates the change and restores the previous configuration if nginx rejects it.

Why

Until now a server could show ClamAV as installed while no whole-machine scan had ever run on it. kstack's weekly request asked for folders it is not allowed to ask Standby for, so it was refused every time, and the security page gave the wrong reason.

A server whose network card stops sending now heals itself in minutes, and tells you what happened, instead of staying dark until someone reboots it by hand.

Added

• Servers with affected Intel network cards are protected automatically. On servers whose network card uses Intel's e1000e driver, kstack turns off the card feature that triggers the freeze and keeps it off, including after reboots and driver resets. Nothing to configure.
• A server whose network card freezes recovers by itself. If a server has been unable to reach the control panel for five minutes and its own system log shows the network card is stuck, the server resets the card and restores its network settings. It never does this while the panel is reachable, so an outage of the panel itself can never make your servers drop their network.
• You are told when it happens. Activity and alerts show when a network card stopped sending, when the server reset it, and when it is sending again. The alert is delivered by email or webhook like every other alert, and to Standby if you use it, where it opens an incident with a step-by-step runbook.

Upgrading

Nothing to do. Servers pick this up when their agent updates. A server that has never shown the problem changes nothing visible.

Why

Some Intel network cards common on dedicated servers can freeze while the machine keeps running. Every website, mailbox and virtual machine on the server disappears from the internet, and nothing can report why, because the server can no longer send anything. One of our own servers spent four hours like that before a manual reboot.

DMARC reports are now collected and shown for every mail domain automatically. Mail servers refuse names they do not host, webmail picks up changes again on servers with older nginx, and moving, exporting and archiving mail log in correctly on every mail server.

Added

• DMARC reports are collected and shown automatically. Every mail domain's DMARC record tells providers to send their daily reports to dmarc@ that domain, and until now nothing received that address, so the reports were refused and the DMARC card stayed empty. Mail servers now receive dmarc@ for every domain they host, read the reports every 30 minutes and show them on the domain's DNS & security tab, with when the last one arrived. No mailbox is created and nothing counts against the plan. A dmarc@ mailbox, forwarder or catch-all you already have keeps receiving the reports too.

Fixed

• Webmail on servers with older nginx picks up changes again. Webmail's configuration turned on HTTP/2 in a form nginx understands only from version 1.25.1, so on Debian 12, Ubuntu 24.04 and Rocky Linux 9 nginx rejected it and no webmail change took effect. HTTP/2 is now turned on only where the server's nginx supports it.
• Moving mail, exporting a mailbox and collecting archived mail log in on every mail server. On mail servers that created their own master password (every server installed since the installer stopped asking for one), moving a mail domain to another server, exporting a mailbox, importing mail over IMAP and collecting mail for the compliance archive looked for that password in the wrong place. Each created a second password the mail system did not know, and was refused. They now use the password the mail system knows.

Security

• A DMARC report can only speak for the domain it was sent to. Reports are kept only for the domain whose dmarc@ address received them, or, when submitted through the API, for mail domains the submitting account holds. Before, a report forged for another customer's domain could be stored first and cause the real one to be discarded as a duplicate. Very large compressed reports are refused instead of being unpacked.
• A mail server no longer shows a customer's webmail for a name it does not host. As web servers have since 1.209.0, a mail server now refuses a request for a name it has no webmail for at the start of the connection, instead of answering with the first domain's webmail page, certificate and branding.

Upgrading

Update as usual. Each mail server starts receiving dmarc@ for its domains on its first check after updating. Reports appear on each mail domain's DNS & security tab within a day, as providers send them.

Why

A DMARC record that sends reports to an address nobody receives gives you nothing to act on. With the reports read and shown, you can see who sends mail as your domain and whether it passes.

When a virtual machine is down, its Health card now names the cause in the server's own words and says when a server restart stopped it, instead of guessing that the next check will fix it.

Fixed

• A virtual machine's Health card names why it is down. When the network bridge a server's virtual machines connect through was missing, for example after the server restarted, the Health card listed the stopped machine and its missing address as two separate faults and said the server would fix them on its next check, which it could not. The server now reports whether that bridge exists, the error that stopped it from making one, and what its DHCP server said. The card shows that as the cause, in the server's own words, and marks the stopped machine, its address and the outside check as following from it.
• A virtual machine stopped by a server restart is described as such. The card said a stopped machine had shut itself down and would stay down until powered on from the panel. A machine that was running before its server restarted is now described as stopped by the restart, which the server starts again on its own. If that start is refused, the card shows the reason. When a machine is not running, the outside check now says so instead of pointing at the network or a firewall.

Upgrading

Update as usual. The new explanations appear once each server has updated itself after the control panel; until then a virtual machine's card says that its server does not report the reason yet.

Why

A health check that guesses sends people to look in the wrong place. One that quotes the server tells them what to fix.

Web servers now refuse requests for names they do not host instead of showing another customer's website. Websites support HTTP/2, HTTP/3 no longer drops connections, and web servers running Alpine Linux load their websites. A database server can be sized from its own memory with one press. Virtual machines and website containers stopped by a server restart start again on their own.

Added

• Websites support HTTP/2. Websites were served over HTTP/1.1 only, although on servers with HTTP/3 turned on their DNS records already told browsers they supported HTTP/2. HTTP/2 is now on for every website, on servers whose web server supports it (nginx 1.25.1 and later). A server with older software keeps HTTP/1.1 rather than being given a setting it would refuse.
• A database server can be sized from its own memory with one press. A database server's Services tab has a new Size from memory card. It recommends memory settings for MariaDB and PostgreSQL together, from how much memory the machine has. A quarter of the memory, and at least 1 GB, is kept for the operating system; the rest is shared between the two databases instead of each being sized as if it had the machine to itself. The card shows each recommended value beside the current one and where the current one comes from. Pressing "Apply these values" sets them on that server only, keeps every other setting chosen by hand, and is recorded in the activity log. Buffer sizes take effect when the database next restarts, and nothing is restarted for you. Nothing changes on its own, even when a server gets more memory; the card says when the machine has grown since the last press.

Fixed

• HTTP/3 no longer fails one connection in five. On web servers with HTTP/3 turned on, about one browser connection in five over HTTP/3 waited several seconds and then failed, because the web server's worker processes were not set up to share incoming HTTP/3 traffic. They now are. In testing, 120 connections out of 120 succeeded over IPv4, IPv6 and a dedicated IP address.
• Web servers running Alpine Linux load their websites. On Alpine Linux the web server reads its configuration from a different folder than on Debian and Ubuntu, so an Alpine web server loaded none of the platform's website configuration, webmail or tuning. The platform now follows what each server's own web server configuration says.
• The check that a website is answering asks a dedicated IP address directly. The check went to the server's local address. For a website with its own IP address that reached the server's default page instead of the website, so the check could report the website as working when it was not. It now asks the address the website is served on.
• Virtual machines and website containers come back after a server restart. After a server restart, the platform did not rebuild the internal networks its virtual machines and website containers connect through, and did not start the ones that had been running, because nothing in their settings had changed. They stayed stopped, and the websites in them stopped answering, until something on that server was next changed. The networks are now checked and rebuilt every minute or so, and a virtual machine or website container that was running before the restart is started again. A virtual machine its owner had stopped stays stopped, and a suspended or turned-off website stays down.

Security

• A web server no longer shows a customer's website for a name it does not host. When a request arrived for a name a web server had no website for, the server answered with whichever website it had loaded first, including that website's certificate. Preview addresses send every name under the preview zone to every web server, so a made-up name there, or the preview address of a deleted website, opened another customer's website behind a certificate warning. A web server now refuses such a request: over HTTPS it ends the connection without presenting any certificate, and over plain HTTP it closes the connection without answering. Websites, their redirects and certificate renewals behave as before. A server whose web server software is too old to refuse a connection this way (nginx before 1.19.4) keeps the previous behaviour for HTTPS; each server is checked rather than assumed.

Upgrading

Update as usual. After the update, each server goes through all of its websites and virtual machines once from the beginning. That also starts any virtual machine or website container still stopped by an earlier server restart. Database memory settings change only when you press "Apply these values" on a database server's Services tab.

Why

A web server shared by many customers must never show one customer's website under a name somebody else chose. A server restart must not leave customers' machines and websites offline until somebody notices.

Deleting or moving a website, deleting a mail domain or removing a preview address now updates its DNS records at Cloudflare as well. Names are also protected between customers: a website can no longer take a name another website answers to, and customers can no longer use the platform's own names or create a zone inside another customer's domain. There was no separate 1.208.0 release; the changes prepared for it are included here.

Changed

• Preview addresses are issued on request and can be removed. A preview address is issued when you ask for one on the website page. It now gets its DNS record straight away. Until the website's certificate covers it, the link uses http instead of an https address that would show a certificate warning. It can be removed from the same page and is released when the website is deleted. The settings and help pages now describe it this way. They used to say every new website got a preview address that worked over HTTPS before the website's own DNS was set up, which is not how it worked.

Fixed

• DNS records the platform removes from a zone Cloudflare serves are removed at Cloudflare too. Deleting or moving a website, removing its preview address or deleting a mail domain removed the records from the platform but left them published at Cloudflare. There they went on pointing at servers that no longer served the website or the mail, and the next sync listed them on the zone page as if someone had added them by hand. They are now removed at Cloudflare within about a minute. A record that is replaced, such as a moved website's address, is updated in place at Cloudflare instead of being deleted and created again. The platform still never removes a record that was added directly at Cloudflare unless you delete it on the zone page.
• A zone's serial number changes whenever records are removed from it. The automatic clean-up of records left behind by deleted websites changed a zone without changing its serial number, so a secondary nameserver copying the zone kept the old records. Every removal now changes the serial.
• Website names are checked the same way everywhere. Every way of creating or renaming a website now applies the same rules to its name. The most-used path accepted a name with no dot, an empty part or an underscore, which could then fail at the web server or when the certificate was ordered. An API order with such a name is now refused before its account and subscription are created. Before, it created both, plus a website that could not work.

Security

• A website can no longer take a name another website answers to. A name is now checked against every name any website answers to: main domains, aliases, redirects, parked domains and preview addresses. This applies when creating a website, adding a domain to one, changing its main domain, making a staging copy or restoring a deleted website. Only main domains used to be checked, so a website could be given another website's alias or preview address and receive its visitors. A restored website gives up any extra name another website has taken since it was deleted, and says which.
• Customers can no longer use the platform's own names or create a zone inside another customer's domain. Some names are now reserved: names inside your preview zone and inside the zone your servers are named in, your nameservers' names, and the control panel's own address. Accounts below the provider cannot use them for a website, an extra domain, a staging copy, a custom panel domain, a mail domain or a DNS zone. The provider account is not restricted, so its own test sites in the preview zone keep working. A DNS zone can also be created inside another zone only by an account that holds that zone. Before, one customer could create a zone for a subdomain of another customer's domain and have the platform serve it, and creating a website for such a subdomain did this automatically. Existing zones are not changed.

Upgrading

If any of your DNS zones are linked to Cloudflare, records the platform removed before this update may still be published there. The zone page may also list them as ordinary records, for example the address of a deleted website or a moved website's old address. They are not removed automatically, because they cannot be told apart from records added at Cloudflare by hand. Review the records of each Cloudflare-linked zone on its zone page and delete the ones that no longer belong there. Deleting a record on the zone page also removes it at Cloudflare. Nothing else needs to be done when updating.

Why

A DNS record the platform publishes stays its responsibility until it is removed, at Cloudflare as much as on its own nameservers. A record left behind goes on sending visitors or mail to a server that no longer serves them. On a platform many customers share, each name must belong to exactly one website. The checks behind that now cover every kind of name a website answers to, everywhere a name is given.

DNS changes are answered by your nameservers as soon as they are applied, a new platform offers its applications from the first minute, and the control panel's web framework is updated past a critical advisory.

Fixed

• A DNS change is answered straight away, not up to a minute later. After a nameserver loaded a changed zone it could go on answering from its cache: for up to 20 seconds with the old records, and up to a minute for a name that did not exist before. A record you had just added could look missing, and certificate checks that wait for DNS took longer than they needed to. Nameservers now clear that cache every time they load a change. This reaches each nameserver with its next agent update; nothing needs to be done.
• A new platform offers its applications immediately. The application catalogue (WordPress and the others) is now filled in when the platform is first set up, instead of after the service next restarts. Setting the platform up twice at the same moment can also no longer create two provider accounts.

Security

• The control panel's web framework is updated past a critical advisory. Next.js is updated to 16.3.8, past an advisory for remote code execution in its image-generation component (GHSA-vcvr-r3jv-pc5j). The control panel does not use that component, so it could not be reached here, but the code is no longer shipped.

Why

The time between saving a DNS record and the world seeing it should be the time DNS itself takes, not a cache on our side. This release also comes out of a new test run on Linux, the platform every server runs, which is where the DNS delay was found.

Malware scanning now covers every server as well as every website, and the Security page shows what was actually scanned in the last seven days instead of which servers have a scanner installed.

Added

• Servers are scanned on a schedule, not only when asked. The weekly malware sweep now scans each server's own directories (home, temporary and website folders) as well as every website, a few servers an hour with the least recently scanned first. Previously a server was scanned only when someone pressed the button.

Changed

• The Security page shows what was scanned in the last seven days. It counts websites and servers actually scanned in the window. Everything that was not is listed with the reason: due next, its server is not reporting, or its last scan failed (with the error).
• A scanner that has never run says so. A server whose antivirus engine is installed but has never scanned is marked "installed, never ran" instead of being counted as protected.

Security

• An unmaintained certificate-parsing library was replaced. Certificate and key files are now read by a maintained library. Uploading a certificate with the certificate pasted into the key box, or an empty key box, still says "that does not look like a private key".

Why

A scanner that is installed but never runs protects nothing, and a server that is never scanned can hide what was left on it. Measuring the scans that ran, and naming what was missed with the reason, makes the security page something you can act on.

A server's Storage tab now shows which filesystem each role's data is on, and which one that role should use.

Added

• The Storage tab recommends a filesystem per role. Each role's data shows the filesystem it is on. Website data is recommended to be on XFS, because that is what lets the platform enforce each site's disk allowance; a website role on another filesystem is marked with the reason. For every other role either filesystem is fine, and the tab says so.

Fixed

• The storage move confirmation names the target volume. Before a volume was chosen, the confirmation for moving a role's data read "to undefined".

Website disk allowances can now be enforced by the filesystem. On a server whose website data is on an XFS volume with project quotas, each site has a hard limit and cannot use more than its plan allows. A server can be given such a volume from the panel: attach an empty disk, format it with one confirmed click, then move the website data onto it.

Added

• Website disk allowances are enforced where the server supports it. Each site gets a hard limit equal to its allowance, so it cannot use more than its plan allows or fill the server for its neighbours. At the limit, applications report "No space left on device". The site's health check explains that this is the site's own limit, not a full server.
• Sites already over their allowance keep working. When enforcement starts, a site that already uses more than its allowance is held at its current size instead of being cut off. It can still delete and rewrite files; it just cannot grow. Raising its allowance or freeing space ends the hold.
• Prepare a volume for quotas from the panel. A server's Storage tab lists attached disks that are empty. One confirmed click, with the disk name typed to confirm, formats a disk and mounts it permanently. The existing Move then puts website data on it. The server checks again that the disk is empty at the moment of formatting.

Changed

• Disk usage is read from the filesystem where quotas are on. On servers that enforce quotas, each site's disk usage comes directly from the filesystem instead of scanning every file. Busy servers do less work to report it.

Fixed

• Restores, domain renames and staging copies work on quota volumes. Moving files into a site with its own quota needs special handling. Restoring a backup, renaming a site's domain and copying WordPress between live and staging all do it, and a restore's previous copy no longer counts against the site's allowance.

Upgrading

Nothing changes on servers whose website data is on an ext4 disk, which includes most cloud servers' default disk. Each server's Storage tab says whether allowances are enforced there and, if not, why. To enforce them:

1. Attach an empty volume to the server, without formatting it.
2. On the server's Storage tab, choose Format for site quotas and type the disk name to confirm.
3. Use Move to put the web data onto the new volume.

Formatting destroys what is on a disk. The server checks the disk is empty before formatting, and refuses if it isn't.

Why

Until now a site's disk allowance was only measured and flagged, so one customer could fill a server's disk and affect every other site on it. Enforcement closes that gap without deleting anything and without breaking sites that were already over their allowance.

Databases now work the way websites do when they are deleted. A deleted database can be restored, deleted permanently, or removed automatically after a retention window you set. Databases that no application uses are listed with the reason. Their owner is asked about them once. Any database can be marked Keep so it can never be deleted by accident.

Added

• Recently deleted, for databases. The Databases page lists deleted databases. Each can be restored with everything it held, or deleted permanently, which removes the database and its logins from its server. Backups are never touched.

• A retention window for deleted databases. Set how many days a deleted database keeps its data. After that, a daily sweep removes it for good. The default keeps deleted databases indefinitely.

• See which databases no application uses, and why. A new list names every database that no installed application is connected to, with the reason:

  • its website was deleted
  • its application moved to a fresh database
  • its server copy's machine is gone
  • it was made by hand and nothing here is connected to it

  Nothing on this list is deleted automatically.

• Owners are asked once about databases left unused. When a database has gone unused for 30 days (configurable), its owner is notified once. They can Delete it (it goes to Recently deleted and can still be restored) or Keep it.

• Keep protects a database from deletion. A kept database is removed from the unused list and never mentioned in a reminder. It cannot be deleted until Keep is lifted. The database's own page shows when it was kept and by whom.

Fixed

• Deleting a database works again. Deleting a database on a server failed with an internal error and changed nothing. It now works: the database's logins are locked and its data is kept, so it can still be brought back.

Upgrading

Nothing is removed on upgrade. Deleted databases are kept indefinitely until you set Settings → Hosting → Keep deleted databases for. Owners are asked about databases unused for 30 days; change or turn this off under Ask about unused databases after (0 = never ask).

Why

Until now, a deleted database's tables stayed on the server indefinitely, and nothing said so. Database servers filled up with data nobody could name. Now every database has an owner decision behind it, and the platform never removes anything unless someone has chosen to.

Nameservers report their health reliably, and a node's DNS page keeps working when the telemetry server is down.

Fixed

• A nameserver's report is no longer lost over records shared by every nameserver. When a DNS node reported on a record that all nameservers carry, the control plane could fail to process the whole report, so that node's latest health and what it was serving went unrecorded. Reports are now processed in full.
• A node's DNS page keeps working when the telemetry server is down. If the server that keeps DNS history did not answer, the whole DNS tab for a node failed, including the node's own last five minutes of answers, which need no telemetry server at all. The live figures now always show, and the history chart says the telemetry server did not answer.

Why

A full run of the platform's test suite found two faults that could affect a running platform, both on the path a DNS node uses to report what it is serving. Both are fixed; the rest of the run's findings were in the tests themselves and are corrected so the suite can be trusted before every release.

The dashboard's numbers now match the rest of the panel on larger platforms, and the compliance report counts every machine holding your data.

Fixed

• Dashboard totals count everything, not the newest 200 items. Websites, mailboxes, databases and backup policies are each counted in full, so the dashboard agrees with the Websites and Backups pages however large the platform grows.
• Backup coverage includes mail domains and virtual machines. Their backups were counted without counting them, which could overstate coverage.
• A backup failure only shows as an incident while it is still failing. The dashboard counted every restore check that had ever failed. It now counts only backups whose most recent check failed, so a problem that has since been fixed no longer reads as an open incident.
• The firewall check covers the backup and telemetry servers too. The compliance report checked only the machines hosting your sites, databases and mail, and left out the servers holding your backups and traffic history. Those are now included.

Why

Totals on a dashboard are only useful if they agree with the pages they summarise. On a platform with many DNS records, the dashboard was counting from a partial list and showing fewer websites, mailboxes and databases than exist.

Cloudflare-hosted domains get every record they should, backups are proven far more widely, and a stale copy of a domain stops being served.

Added

• New mail domains are backed up automatically. With automatic protection switched on, a new mail domain now gets a backup the same way a new website does. Mailboxes hold correspondence, and they were the one thing a new site arrived with that had no backup.

Changed

• A publishing problem with Cloudflare is reported once, with the reason. Instead of an entry every five minutes, the activity feed and alerts say once when records start failing and once when they recover, and the domain's page lists which records Cloudflare refused and why.
• The activity feed says what an automatic repair actually did. Instead of just "platform healed", the entry now names what was repaired and how many times.

Fixed

• Mail-app setup records now reach Cloudflare. For a domain whose DNS is served by Cloudflare, the records that let Outlook, Apple Mail and phones set themselves up (SRV), plus CAA, TLSA, HTTPS and similar records, were refused by Cloudflare and never published. They are now sent in the form Cloudflare requires, and Cloudflare's own spelling of them is no longer mistaken for a change.
• A domain moved to Cloudflare stops being served by the old nameserver. The nameserver a domain had originally been placed on kept answering for it after the domain was linked to Cloudflare, with an out-of-date copy. It now stops, like every other nameserver.
• Restore checks reach every backup, not a sample. The weekly restore check took one backup per server per run, so a server holding many databases could go months without any of them being proven. Each run now takes the backups checked longest ago, however they are spread across servers, so every backup is proven inside the window you set.
• The domain page no longer offers to link a domain that is already linked. While the page was loading, it could briefly claim the platform's own nameservers served a Cloudflare domain. It now says it is reading, and says so plainly if it could not read.
• The preview zone cannot be deleted while new sites rely on it. Deleting the zone that gives every new site its preview name is now refused, the same way deleting the zone that holds the nameservers' own names already was.
• A busy OpenLiteSpeed site is no longer reported as down. On a site served through OpenLiteSpeed, a health ping that had to wait for a busy PHP worker was reported as a failure while visitors were being served normally. It is now reported as inconclusive, and the request through OpenLiteSpeed decides.
• Old failures for deleted sites leave the Jobs attention list. A failed job for something that has since been deleted is cleared automatically, so Needs attention shows only things someone can act on.

Upgrading

Nothing to do for the update itself. Mail domains created before this release are not given a backup automatically: open Backups and press Protect on any that are listed as unprotected.

Why

A live audit of a running platform found places where the panel reported success for something that was not happening: DNS records that never reached Cloudflare, restore checks that reached only a fraction of backups, and a nameserver still answering for a domain that had moved. Each of those is fixed here, and the platform now says so when it happens again.

Busy nodes run more quietly: fewer needless restarts, quicker recovery, and less load on DNS and databases.

Fixed

• A change restarts a service once, not once per site. Work that applies to the whole node now runs once for the node, instead of being repeated for every site on it.
• A PHP service that fails to restart is tried again. If php-fpm does not come back after a restart, the next reconcile cycle restarts it instead of leaving the site down until someone notices.
• DNS is asked far less often. Each zone is looked up once per cycle rather than once for every record in it.
• Health checks no longer use the database connections your sites need. Monitoring now keeps its own connections, so it never competes with your sites for the connection limit.

Why

A node hosting many sites should do each piece of housekeeping once. Doing it once per site made every change louder than it needed to be, and let a failed restart go unnoticed.