KStack

Changed

• Every release is now tested against real MariaDB and PostgreSQL servers. Importing, editing rows, copying a database, connection limits, password changes and suspending a database are now checked on both database engines before any release goes out.

Fixed

• A staging copy of an application site starts. When a live NodeBB, Wiki.js or Flarum site was copied into its staging site, the copied files were not handed to the staging site, so the application could not read its own settings and never started. The copy's files now belong to the staging site.
• Rows in PostgreSQL databases can be edited in the database manager. Saving an edited row in a PostgreSQL table failed whenever the row was found by a numeric key. Each value is now matched to its column's own type, on PostgreSQL as on MariaDB.

Fixed

• On nginx servers, a site with a visitor allow or deny list no longer stops every later change on that server. The list made nginx refuse the server's whole new configuration, so nothing changed for any site on it until the list was removed. Certificate renewal stays open past the list, as before.
• Hotlink protection works for PHP sites on nginx servers, WordPress included. On nginx it had not taken effect for PHP sites, so other websites could embed their images. The site's own pages, under every name it answers to, can still show its images.
• A staging copy of an application site starts its application. Copying a site into its staging website disconnected the copy's own folders from it, so an application such as NodeBB could not start on the copy.

Fixed

• NodeBB installs and updates no longer run out of memory while building. NodeBB built all of its parts at once on servers with four or more cores, and its build could be stopped for running out of memory even when the server had memory to spare. It now builds one part at a time, and may use more memory where the server has it free.

Fixed

• Sites on OpenLiteSpeed and Apache servers answer over IPv6. Each IPv6 address a server publishes gets a listener of its own, beside the IPv4 listeners, which do not change. Before release, each web server was switched to this while serving, with a visitor making requests throughout, and not one request failed.
• Preview addresses and parked domains show their pages on OpenLiteSpeed servers. OpenLiteSpeed had refused both on real servers, because the path to them passes through a link it was told not to follow.
• A web server configuration that fails is tried once, not over and over. The previous configuration keeps serving, and the failure is reported once. Before, the same failed configuration was retried every minute or so, and every site on the server dropped out each time.
• A staging copy of NodeBB, Wiki.js or Flarum starts its application, and keeps its own logs. The copy received the application and its data but nothing to run it. It also showed the live site's log, which made its own problems look like the live site's.
• Apache shows the platform's page for a preview address no site holds, as OpenLiteSpeed does.

Added

• Push a staging website live from Studio, for every site that is not WordPress. Step 3 on the Studio card first shows what would change, then pushes. The live site is backed up first. Only changed and new files are written. Nothing on the live site is deleted, and its own settings, uploads and data are never replaced.

Fixed

• Sites on servers that use OpenLiteSpeed as their web server no longer drop out again and again. v1.254.7 changed how OpenLiteSpeed listens, to add IPv6. On a server that was already running, the change left it without an IPv4 listener, so it kept being rolled back and retried, and every site on that server went offline for a short time over and over. This release puts back the listening that worked before. IPv6 for OpenLiteSpeed will return once a test proves a running server can make the switch without a single failed request.

Upgrading

Update straight away if a server uses OpenLiteSpeed as its web server and is on v1.254.7.

Added

• Studio opens a staging website and copies your live site into it, in two clicks. The Studio tab now starts with the staging website: open it, then copy your site into it. The coding agent you connect works on the staging copy only.

Changed

• A website's overview lists only the databases that website uses. Other databases on the account are one link away. The Databases page has a new Used by column that names the website each database serves.

Fixed

• A staging copy of NodeBB, Wiki.js or Flarum has its own database and never touches the live one. The copy gets a database of its own with your live data in it, and the application is set up for that database and the staging address, at the version your live site runs. Before this, a copy of these applications would have used the live forum's database.

Upgrading

Do not stay on this release if a server uses OpenLiteSpeed as its web server: its change to IPv6 listening made sites on that server drop out briefly, again and again. Update to v1.254.8, which puts the previous listening back.

Fixed

• A website's usage card shows the memory ceiling its container actually runs under. The card read the ceiling from an old snapshot, so a site that had been raised to 1024 MB could still say "of 512 MB". The memory and process ceilings are now reported every cycle.

NodeBB is given the memory it needs to run.

Fixed

• A site running NodeBB is given at least 1024 MB of memory. Under the default 512 MB NodeBB could be stopped by the memory ceiling every time it started, and the forum stayed unavailable. After NodeBB is installed or updated, the site's memory ceiling is raised to 1024 MB when it is lower, unless the account's plan allows less. The change is shown in Activity.

An application that does not come back after an install or update is restarted by itself.

Fixed

• NodeBB and Wiki.js are restarted once if they do not answer after an install or update. A minute after the install or update finishes, the platform asks the site for its home page the way a visitor would. If it gets an error or no answer, it restarts the application once and says so in Activity ("An application was restarted because it did not answer after its update"). Previously a site could stay unavailable until somebody pressed Restart.

Check for updates asks the application's publisher, Update installs the newest release, and nothing ever goes backwards.

Added

• A setting to stay on tested versions. Settings, Hosting: "Install the newest release of NodeBB, Wiki.js and Flarum", on by default. Off installs and offers only the versions this platform was tested with.

Fixed

• Check for updates asks the publisher. For NodeBB, Wiki.js and Flarum it reported "up to date" against the version the platform was tested with, while newer releases were out. It now asks the publisher for its newest stable release and offers it.
• Update installs the newest release. Update to a newer version now has its own path: the new release is built beside the running one and swapped in, and the database, content and settings stay. Repair keeps the version already installed.
• An application never moves backwards. If the publisher cannot be reached and only an older version could be named, the version already running is kept, and an update is offered only when the offered version is newer.
• The update band no longer repeats itself. The line under Check again now says it checked, instead of repeating the sentence above it.

NodeBB, Wiki.js and Flarum install their newest release, sites behind LiteSpeed can empty their cache, and the application card's buttons line up.

Added

• A site served by OpenLiteSpeed or LiteSpeed Enterprise can empty its page cache. The Empty the cache button was only offered with the page-cache switch on, but LiteSpeed's cache works regardless. It is now always offered for those sites, and an application install empties the cache when it finishes, so a page cached halfway through an install is not served for an hour.

Changed

• NodeBB, Wiki.js and Flarum install their newest release. A new install asks the publisher for its newest stable release in the major version this platform has tested, instead of a version written in months ago. Downloads are still checked against what the publisher lists. If the publisher cannot be reached, the tested version is installed as before. A repair keeps the version already installed.

Fixed

• The application card's buttons line up. Explanations sit on the left and their buttons on the right, on desktop and on a phone, including buttons that wrap to a new line.
• Extra Hetzner addresses arrive with their MAC. When Robot's address list carries no separate MAC, the address's own MAC record is asked as well, and an address already added without one is completed.
• A mail domain with no mail yet is not a failed backup. Its backup now reports that there is nothing to back up yet, instead of failing every day.
• Two small wording fixes. The Reinstall dialog no longer shows a stray code instead of a dash, and an extra address arriving from your provider has a readable name in Activity.

Failed security scans are retried within hours, mail domains on a blocklisted address say so, and notifications explain themselves.

Changed

• The Hetzner Robot setting explains that it also brings extra addresses in. Its description now says extra addresses routed to your servers are added to their pools, ready for a VM.

Fixed

• A failed security scan is tried again after six hours. A scan that failed used to keep a site or server out of the scan rotation for a whole week. It is now retried after six hours.
• A mail domain whose sending address is on a blocklist says so. Domains read "Delivering" while their mail server's address was listed on a blocklist. They now read "Sender listed", naming the address and the list, and point to Reputation for getting it removed.
• Notifications explain what went wrong. A notification without its own sentence now shows the reason the server gave. An application install that has only been asked for now reads "install was started" rather than "installed".

Extra addresses on a dedicated server arrive by themselves, sites reach a database on their own server, backups stop claiming protection they do not have, and buttons line up.

Added

• A dedicated server's extra IP addresses are added by themselves from Hetzner Robot. When Robot web-service credentials are saved, every extra address Robot routes to one of your servers is added to that server's address pool, with Hetzner's separate MAC and the gateway, ready to give to a VM. Blocks you added yourself are never changed. With other providers, add the address under Addresses as before.

Fixed

• A site can reach a database on its own server. When one server held both websites and databases, a site's application could not connect to its database and installs failed with "Connection timed out". The firewall now lets that server's sites reach its database ports; each database's own users and passwords still decide who gets in.
• Backups whose store can no longer be opened start again by themselves. A backup repository that had lost its configuration could never be opened or created again, so every backup of the sites in it failed. After an hour without changes it is now moved aside (kept, not deleted) and the next backup creates it anew.
• Backup coverage counts backups that exist. The dashboard said everything was protected as soon as a backup schedule existed. It now counts only backups with a recent snapshot. The Backups page shows a backup that cannot run as FAILED with the server's own reason, and no longer calls schedules without a snapshot "protected".
• A failed backup of the control plane says why. The warning now carries the reason the last backup failed, with any password in an address hidden.
• Buttons line up. Install buttons in the application catalogue sit at the same height, and a button in a row of buttons no longer sits lower than its neighbours.
• A busy PHP pool behind OpenLiteSpeed or Apache is no longer reported as down. On a server where OpenLiteSpeed or Apache answers the web ports itself, a site's PHP pool that was busy serving visitors was reported as "not answering" and blamed on nginx. It is now reported as busy, and every message names the web server actually in use.

A page left open across an update now says so, Flarum installs again (as Flarum 2.0), and a server running Apache is named as Apache.

Fixed

• A page left open across an update tells you to reload it. A bar appears on any page that was open while the panel was updated, with a Reload button. Its buttons belonged to the previous version and could fail with "An unexpected response was received from the server". If a button does fail that way, the panel now says what happened and that nothing was changed, and reloads the page once by itself. If it still fails after a reload, it tells you something in front of the panel, such as a web firewall, is refusing the request.
• Apply on a server's roles no longer stays stuck when it fails. The dialog lets you try again instead of staying busy.
• Flarum installs again, as Flarum 2.0. Flarum 1.8 can no longer be installed by anyone: every version depends on a file-storage library with published security advisories, and the installer refuses it. New Flarum sites get 2.0, which needs PHP 8.3 or newer. Its LiteSpeed cache and Redis add-ons are installed in the version matching your forum. A Flarum install that failed can be run again with Reinstall.
• A server whose web server is Apache or OpenLiteSpeed is named that way. A server's own page said nginx in its site checks and its installed list even when Apache answers the sites. It now names the web server actually answering, and nginx's tuning card is shown only where nginx serves.
• The backup storage machine says why it leaves a half-made backup store alone. Its log now records when it keeps a backup store that never finished being created, and why, so a store that does not heal can be traced.

A backup machine whose storage was moved onto a volume accepts backups again.

Fixed

• A backup machine whose storage was moved onto a volume accepts backups again. After the move, the backup store could still read what it held but refused every new backup with an internal error, including the control plane's own. It now writes to the volume, and restarts by itself whenever its storage moves.

Alert emails now say what happened, to what, why and what to do, in an email dressed in your brand. A backup store that was left half set up repairs itself, and the Security and Traffic pages read more truthfully.

Added

• Every email carries your brand: logo, colour and your panel's address, with a plain-text copy for mail apps that show only text. Settings, System email now previews each message as it arrives.
• Activity shows why each failure happened, under the row.

Changed

• Alert emails say what happened, which item and machine, why, and what to do next, with a button to the item's page. The reason is the one the event recorded, such as the node's own message. Times are written as "26 Oct 2026, 11:19 UTC".
• Several failures of the same kind at once arrive as one email listing each item and its reason. A new template, "Alert, several at once", can be edited like the others.

Fixed

• Backups that never ran because the account's backup store was left half set up now repair themselves. The backup machine clears a store whose setup stopped half-way, and the next backup creates it properly. A site with no backup yet now says so instead of showing an error.
• Traffic's error rate counts server errors only. An empty site's "nothing is published yet" page and bots asking for pages that do not exist were counted as errors, so healthy sites showed rates above 50%. Those requests stay in their own 4xx column.
• Malware scans no longer fail when two sites on one machine are scanned at once, and large sites have three hours to finish.
• The Security page keeps showing the last posture score when Standby is slow to answer, and shows the full reason when there is none.

The control plane backs itself up to your backup machine, and backup schedules are chosen as "every day" or "every 6 hours" instead of a number of minutes.

Changed

• Backup schedules are picked as a cadence. Settings, Backups, a site's first backup, a plan's backups and the control plane's own backup offer every 15 minutes, hour, 4, 6 or 12 hours, day or week. Schedules you already set are unchanged.

Fixed

• The control plane's own backup moves from its local disk to your backup machine. If the control plane's backup was set to its own disk because the backup machine was not ready yet, it now switches to the backup machine by itself once that machine is ready. Your off-site copy and retention settings are kept.
• Saving the control plane's backup target with the field empty uses your backup machine and keeps the rest of the form. It used to clear the off-site copy settings too. When the backup machine is not ready, it now says so and changes nothing.

Security

• The backup machine's access password is no longer shown in the backup settings form or copied into the activity log.

Ask now says whether its advisor model was consulted, the AI settings keep showing what you saved, and a few settings that read as blank now show their defaults.

Added

• Each Ask answer says whether the advisor model you chose was consulted. The line under an answer now reads "advised by" and the advisor's name, or "not consulted". When an advisor is chosen, Ask is told to consult it on anything that needs judgement.

Fixed

• Profile, AI keeps showing your saved model, effort and advisor after Save. The pickers used to jump back to their first options, even though your choice had been stored.
• The ceiling label on usage charts no longer sits under the legend.
• The blocklist setting shows its default, and the two resolver fields can be cleared. On a server that had never saved a choice, Settings, Mail showed no blocklist ticked, and saving either resolver field empty was refused.

Backup machines added with their role already chosen now start their backup store, and a few backup and storage edge cases are fixed.

Fixed

• A backup machine added with the backup role ticked in the Add server wizard now starts its backup store. Choosing the backup role while adding a server skipped creating the store's access keys, so the store never started and the server showed "not answering". Servers already in this state repair themselves after the update.
• A website that was removed and added again can have its backups turned on. Turning on backups for a re-added website could fail with "this target already has a backup policy". The new policy now gets its own name, and if anything else goes wrong, the error names the actual problem.
• Moving an unused role onto a storage volume works. Moving a role to a volume failed when that role had no data yet, for example on a server that had just been added. The role's folder is now created on the volume and linked in its place.

Choose which Claude model answers in Ask, how hard it thinks, and whether it may consult a stronger model.

Added

• Pick Ask's model from your provider's live list. Profile, AI now lists the models your Claude key can use, fetched from the provider each time the page opens and on Sync models - so a newly released model appears without waiting for an update. Each shows its context size. On this platform's key, a model only becomes choosable once it has a price here.
• Choose how hard Ask thinks. An effort setting from low (quickest, cheapest) to max (slowest, most thorough), limited to the levels the chosen model supports. Medium stays the default.
• Let Ask consult a stronger advisor model (beta). Pick an advisor, and the model answering may ask it for guidance on a hard question - a cheaper model with a strong advisor can answer like the strong one for less. Only advisors Anthropic allows for the chosen model are offered, at most three consultations per answer, and the advisor's use is billed separately at its own rate.

Changed

• Prices for the current Claude models are on the rate card. Claude Opus 5.5, Sonnet 5.5, Haiku 5.5, Fable 5 and Opus 4.8 now have their published prices, so usage on this platform's key is metered correctly.

Fixed

• A model the provider retires is said, never swapped. If the model you chose stops being offered, Ask tells you which one to replace and you get one notification; it never quietly answers with a different model. Saving the AI settings also no longer clears the chosen model.

The Ask side panel notices when Ask has been set up.

Fixed

• The Ask side panel no longer says "nobody has said where this account's AI should come from" after you set it up. The side panel checked once whether Ask was set up and remembered the answer, so after adding a Claude key it went on saying nothing was configured until the page was reloaded. It now checks again as you move around and whenever it is opened, until Ask is ready.

Website and mail certificates no longer run out during a long panel outage.

Added

• Servers renew their own website and mail certificates when the panel has been gone two days. Certificates were only ever renewed by the panel, so a panel away for longer than a certificate's last few weeks let it expire. Now, once the panel has been unreachable for two days, a server renews any of its certificates with less than a sixth of their life left. It first checks that each name really reaches it, so it never wastes an attempt on a name pointed elsewhere. Wildcard certificates still wait for the panel. When the panel is back, the server hands each renewed certificate over, and the panel takes it only after checking it is genuine and the right one.

A server that was cut off from the panel for a long time reconnects by itself.

Fixed

• A server whose connection certificate expired while it was cut off can renew it and reconnect. Each server's certificate for talking to the panel lasts a year and renews itself in its last month. A server that could not reach the panel for that whole month used to come back with an expired certificate and be locked out until it was enrolled again by hand. It can now renew it for up to 90 days after expiry - the panel checks the certificate was genuine and lets it do nothing but renew.

Domains signed with DNSSEC keep resolving even through a long panel outage.

Added

• Nameservers re-sign their DNSSEC zones themselves before the signatures run out. A DNSSEC signature lasts 30 days, and only the panel used to refresh them. If the panel was unreachable for three to four weeks, every signed domain would stop resolving for anyone whose resolver checks signatures. Each nameserver now watches its own zones and, when a signature has less than half its life left, signs the zone again with the keys it already holds. With the panel running this never needs to happen; it is the safety net for when it is not.

Your servers keep their sites running and their backups on schedule even while the panel cannot be reached.

Added

• Servers keep working while the panel is unreachable. Until now a server that could not reach the panel stopped all of its scheduled work: after a reboot its site containers and virtual machines stayed stopped, applications that crashed stayed down, and backups waited. Each server now keeps a sealed copy of its last instructions and, while the panel is away, carries on from it - it brings its sites and virtual machines back after a reboot, restarts what should be running, and takes its backups on time. It never changes its configuration from that copy. When the panel is back, Activity says once what the server did meanwhile.

Security

• The copy a server keeps holds only what its backups need, sealed to the machine. The copy keeps a backup's own passwords and nothing else - no certificate keys, no mailbox or admin passwords. It is encrypted with a key held in the machine's TPM where it has one, and in a file only the system can read where it does not. A server the panel refuses deletes its copy.