Skip to main content
news Version 0.9.5.0 Released (18th September 2026) - v0.9.5 — The "Always Bring Your Servers Back" Update: an aborted maintenan…

Product release · v0.9.5

AASM v0.9.5: The “Always Bring Your Servers Back” Update

Ark Ascended Server Manager v0.9.5 is a stability pass built entirely from community bug reports: an aborted maintenance cycle always brings your servers back up, a stale “Running” record no longer blocks Start, Linux survives an unreadable process, backups are finally capped, and the most common licence problem is now a one-click self-service reset — on both Windows and Linux.

Direct answer: AASM v0.9.5, released 18 September 2026, is about a manager that never leaves you worse off than it found you. A maintenance cycle that aborts now restarts your server before it exits; Start re-checks a stale “Running” record and proceeds; one unreadable process can no longer freeze the Linux process scan; cluster and pre-update backups are capped at the newest 20 and 10; and HWID resets are self-service from inside the app — including from the “activated on another machine” force-quit screen itself.

What changed in v0.9.5

The theme of this release is follow-through: AASM should never leave you worse off than it found you. Every fix in it started as a community bug report, and every one of them closes a way the manager could leave your fleet dark, blocked, or quietly out of disk.

Maintenance that finishes what it starts

A maintenance cycle whose final verification could not confirm the install state used to abort without restarting your server — you came back to a dark server and no explanation. Now every abort path brings the server back up before it exits, and if verification is inconclusive, AASM retries on a bounded budget before giving up. On top of that, the Start button re-checks a stale “Running” record: if the process verifiably died out-of-band, the record is corrected and your server starts, while a genuinely-alive or unverifiable process is still refused — no double-starting. And on Linux, one unreadable sibling process can no longer freeze the whole process scan (the old failure left servers stuck in STARTING forever); the scan now continues, records what it could not read, and decides at the end — fail-closed, still refusing rather than risk masking a second copy of your server.

Backups that stop growing forever

Cluster and pre-update backups sat in the never-pruned set and accumulated without bound. They are now capped per class — the newest 20 cluster and newest 10 pre-update copies — with manual and player backups still never pruned, and the cap mathematically unable to delete everything. Pre-update backups also carry their own pre_update_backup_ name instead of posing as automatics. And APPLY TO SERVERS no longer silently drops your Backup Location: a new opt-in “Also copy the Backup Location” checkbox (off by default, reset on every open) makes copying the location explicit instead of accidental.

A dashboard that tells the truth

The Timed Update countdown now ticks on the dashboard card itself (⏱ Timed Update in Xm Ys) instead of hiding in the Maintenance tab. Cards no longer stick at Running/Stopping after the process is gone: on a stop-wait timeout one final fail-closed verified-exit check runs before the force-kill path — and it still refuses to write STOPPED unless the process is verifiably gone. The bulk-update confirm now reads “Update Now” / “Schedule Update” instead of falling through to “Restart Now”, every card shows exactly one status indicator in every state, and the two-line “Loading (mods/map)…” label is now a single “Loading…” with the detail in the tooltip.

One-click HWID reset — self-service

The most common support ticket: your licence is bound to a different machine, usually after a Windows update changed how your PC identifies itself. Until now the fix was a ticket and a wait. From v0.9.5 it is self-service: a Reset My HWID button on the Licence screen opens the reset portal (email + licence key → reset → fully close AASM including the tray → relaunch and validate). And critically, the button is also on the “activated on another machine” force-quit screen itself — the one that exits 30 seconds later — so you are never locked out of the fix when you need it most.

Worth knowing — still open, told honestly: scheduled maintenance can fire about an hour early on some timezones (observed on a Windows Server 2019 box). The scheduler’s time math is DST-correct in the obvious path, so this needs a live DST-observing machine to pin down; v0.9.5 ships new diagnostics that log the computed fire time in UTC, local and timezone offset — if maintenance fires at the wrong hour on your box, send us those log lines. A stuck Running/Stopping card under heavy fleet load is also still under investigation, with the failure point now logged. Neither is claimed fixed in this release.

Reliability and community-reported fixes

  • Aborted maintenance restarts the server: both “install state unverifiable” aborts skipped the restart; every abort path now restarts before it exits (reported by reconin).
  • A stale “Running” no longer blocks Start: liveness is resolved at the guard; confirmed-dead records are corrected and the start proceeds (reported by xalcons).
  • Linux: stuck in STARTING on an unreadable pid is fixed: unreadable sibling pids no longer abort the family scan; an end-of-scan uid-gate decides, fail-closed (reported by cxserver).
  • Cluster + pre-update backups are capped at newest 20 / newest 10 per class, honouring dry-run, with a floor of one copy (reported by pan_vinokur).
  • APPLY TO SERVERS keeps your Backup Location unless you explicitly opt in with the new checkbox (reported by pan_vinokur).
  • The Timed Update countdown now shows on the dashboard as a ticking chip on the queued server’s card (reported by pan_vinokur).
  • Cards no longer stick at Running/Stopping after a stop-timeout: a fail-closed verified-exit check runs before the force-kill ladder (reported by pan_vinokur).
  • The bulk-update confirm reads “Update Now” / “Schedule Update” instead of “Restart Now” (reported by pan_vinokur).
  • UI polish: one status indicator per card in every state; a single-line “Loading…” label; and one-click Reset My HWID on the Licence tab and the force-quit screen.

Platform and file details

PlatformPackageSizeRequirements
Windows.zip (bundles the companion ASA RCON Manager)372.4 MBWindows 10/11 or Windows Server 2019+
Linux.tgz · AppImage · .deb290.8 MB64-bit graphical session; Ubuntu 22.04+ or Debian 12+ recommended

For either platform, use at least 16 GB RAM. AASM recommends 32 GB when running multiple ASA servers, plus SSD storage and sufficient free space for server files, staging data and backups.

Upgrade guidance

  1. Stop active server maintenance and wait for backups or updates already in progress to finish.
  2. Create a current backup of every world and any shared cluster data.
  3. Update in-app through Settings → Check for Updates, or download the correct platform archive from this domain and verify its SHA-256 fingerprint.
  4. Confirm v0.9.5 in AASM before restarting the fleet.
  5. If scheduled maintenance fires at the wrong hour on your machine, update, let it fire once, and send the new scheduler log lines (UTC + local + timezone offset) — they name the culprit.

Common questions about v0.9.5

Why did a maintenance cycle leave my server offline?

Because before v0.9.5, a maintenance cycle that could not verify the install state aborted without restarting the server. v0.9.5 fixes this: every abort path now brings the server back up before it exits, and if verification is inconclusive AASM retries on a bounded budget before aborting. An aborted cycle must never leave a fleet dark.

Why could I not start my server when the dashboard said Running?

The record said Running but the process had actually exited out-of-band, and Start refused on the stale status. v0.9.5 resolves liveness the moment Start is pressed: a confirmed-dead record is corrected to STOPPED and the start proceeds, while a genuinely-alive or unverifiable process is still refused so a second copy can never be started on one save.

Why did my cluster backups keep growing without limit?

Cluster and pre-update backups sat in the never-pruned set, so they accumulated forever. v0.9.5 caps them per class - the newest 20 cluster backups and newest 10 pre-update backups are kept, the oldest beyond the cap are pruned, and the cap can never delete everything. Manual and player backups are still never pruned. Pre-update backups also now carry their own pre_update_backup_ name instead of posing as automatic backups.

How do I fix the "activated on another machine" licence error?

From v0.9.5 it is one-click self-service: a Reset My HWID button on the Licence screen - and on the "activated on another machine" force-quit screen itself, the one that exits 30 seconds later - opens the self-service portal at arkascendedservermanager.com/hwid-reset/. Enter your email and licence key, reset, fully close AASM including the tray, then relaunch and validate. No support ticket needed.

What changed for Linux in v0.9.5?

One unreadable sibling process used to abort the entire process-family scan, leaving servers stuck in STARTING forever. The scan now continues past unreadable pids, records each one's uid from the world-readable /proc/<pid>/status, and decides at end-of-scan - fail-closed: it refuses rather than risk masking a possible duplicate server. The Windows path is untouched; the change is purely additive on Linux.

Is anything still not fixed in v0.9.5?

Yes, and it is said openly. Scheduled maintenance can still fire about one hour early on some timezones (observed on a Windows Server 2019 box): the scheduler math is DST-correct in the obvious path, so it needs a live DST-observing machine to pin down - v0.9.5 ships new diagnostics that log the computed fire time in UTC, local time and timezone offset. A stuck Running/Stopping card under heavy fleet load is also still under investigation. Neither is claimed fixed; both are instrumented, and the logs now show exactly where the probe failed.