Skip to content

Releases: azerioid/azerioid-stack-manager

v2.14.5 — Docker cap fail-safe handles spawn errors (A80)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 15:01
2d3ba37

Completes the Docker resource-cap fail-safe: a cap the rootless daemon rejects makes the container exit immediately (a Supervisor "spawn error"), which is now caught and treated like a failed start — the cap is recorded-but-not-enforced and the container is brought back without it, so the site never goes down. Found and fixed via live validation on the Rocky host.

v2.14.4 — Docker cap honest degradation (A80)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 12:46
9ab2f5b

Refines v2.14.3: when a host's rootless Docker can't enforce a CPU/memory cap (no cgroup v2 delegation), the cap is no longer silently removed. It stays recorded, the container runs without it, and the panel reports it as "recorded but not enforced on this host" — persistent, honest visibility. Re-attempted on each change in case delegation gets enabled.

v2.14.3 — Docker cap fail-safe (A80)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 12:40
5684ac3

A per-vhost resource cap must never take a running site down. On a host whose rootless Docker lacks cgroup v2 CPU/memory delegation, docker run --cpus/--memory is rejected and the container won't start; applying such a cap now clears it, restarts the container without it, and reports that this host's rootless Docker can't enforce caps — instead of leaving the site down. Found by live validation.

v2.14.2 — clone UI source guard (A79)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 12:13
7826f02

Hardening for the Clone to… UI: the clone action now re-verifies server-side that the source site is a known, non-readonly vhost before cloning, rather than trusting a client-set value (defense-in-depth; the broker already re-validates).

v2.14.1 — Clone to… UI (A79)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 12:09
4b5d558

Adds a Clone to… action to the Virtual Hosts page: clone a site into a fresh staging vhost (files + Octane/PM2 runtime) and optionally its databases, with the new one-time database credentials shown once — the web counterpart to the existing azerioid vhost clone CLI. README refreshed with the full post-audit feature set and CLI examples.

v2.14.0 — app down alert (A84)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 11:41
47c1b55

A84: get alerted when an app worker goes down. Octane, PM2 and Docker sites run a background worker — if it crashes, the site is down even though the server and web server are healthy. The panel now watches each runtime site's worker via Supervisor and raises an alert (with the same Telegram notification + auto-resolve as other alerts) when a worker is stopped, fatal, exited or backing off. Transient states don't alarm. Toggle it on the Alerts page (on by default).\n\nThis completes the post-audit feature roadmap (A78–A84).

v2.13.1 — recovery codes refresh on re-enrollment (A83)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 11:34
db6e2ca

Erratum to A83. Resetting / re-enrolling two-factor now issues a fresh set of recovery codes and invalidates the previous ones — so codes from a replaced (possibly compromised) setup can no longer sign in.

v2.13.0 — 2FA recovery codes (A83)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 11:30
736c041

A83: one-time recovery codes for two-factor auth. When you enable 2FA you now get 8 single-use recovery codes, shown once — keep them somewhere safe and you can sign in even if you lose your authenticator. At the login challenge, choose "Use a recovery code"; each code works exactly once. Settings shows how many codes remain and lets you regenerate them (current password + a valid authenticator code required). Codes are stored encrypted at rest.

v2.12.0 — per-vhost access log viewer (A82)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 11:22
ac01534

A82: view any site's access log from the Logs page. The Logs page now has a "Site access log" picker listing your managed domains — selecting one tails (or fixed-string searches) that site's Caddy access log. The broker derives the path from the domain and re-checks it stays under the web log directory, so it is read-only and path-safe. System logs remain available via "— system logs —". App/error logs for Octane/PM2/Docker sites stay on the Docker logs page and the runtime status.

v2.11.0 — audit feed filters (A81)

Choose a tag to compare

@azerioid azerioid released this 07 Oct 11:14
a6d124f

A81: the audit log is now filterable. The Audit page already recorded every privileged action (web actions and the result of every broker call) with the acting user, IP, outcome and redacted arguments — now you can filter it by action, result (succeeded/failed), user, and date range. Filters are reflected in the URL so a filtered view can be shared or bookmarked.