v0.2.0

The Daemons page can now be relied on for a fuseraft serve on another machine. It stays connected, picks work back up after either side restarts, can be shared with non-admins, and keeps its secrets encrypted. It needs fuseraft v1.14.0 on the daemon's machine for reconnecting, restarts and wss://.

New

• Stays connected. Daemons connect when the server starts and reconnect after a dropped connection, with backoff. A wrong token, an untrusted certificate or a protocol mismatch stops the retries and shows why.
• Picks work back up. After a network drop, a restart of fuseraft-web or a restart of the daemon, a running task carries on, its pending approval is asked again, and results that finished meanwhile appear.
• Saved daemons. Daemons added on the page are kept in <data>/daemons.json (mode 600), with their tokens encrypted, and stay connected or disconnected as you left them.
• TLS. CertificateSha256, also a field on the page, trusts a self-signed wss:// certificate by its fingerprint. A plain ws:// URL to another machine is marked unencrypted.
• Sharing. Admins can share a daemon with named users, via "Users": [...] in Fuseraft:Daemons or a field on the page. Those users see only their own tasks and approvals; everyone else doesn't see the daemon at all.
• Read-only daemons. A daemon reached with a read token from its --tokens-file shows its progress, marked read-only, with no task box.
• Encrypted keys. Fuseraft:KeyCertificate (an RSA .pfx, password in FUSERAFT_WEB_KEY_CERT_PASSWORD) encrypts the data-protection keys. On Windows they're encrypted with DPAPI by default. See docs/deploying.md.

Fixed

• Approval cards on the Daemons page didn't appear until some later event refreshed the page.

Heads-up: a daemon older than fuseraft v1.14.0 still works, but the page warns that a dropped connection there loses the pending approval. Back up the data directory's daemons.json along with keys/, and the key certificate if you set one: without the keys, saved daemon tokens can't be read.

What's Changed

• docs: point at the renamed repo and require fuseraft v1.13.0 by @fuseraft in #6
• feat(daemons): keep remote daemons connected, shared and safe across restarts by @fuseraft in #7

Full Changelog: v0.1.0...v0.2.0

v0.1.0

The first release of fuseraft-web, the web UI for fuseraft (formerly fuseraft-server). It needs fuseraft v1.13.0 or later.

Unpack the archive for your platform and run ./fuseraft-web. The log prints a one-time link for creating the first admin. See the README and docs/deploying.md.

Highlights

• Accounts. Sign in with a password, single sign-on (OIDC), or both. Includes a fuseraft-web users command and admin and account pages. (#5)
• One fuseraft home per account. Each account's sessions, chats, memory, schedules and model profiles are its own, and profile keys go only to that account's processes. (#5)
• Sessions outlive the server. Stopping, upgrading or crashing fuseraft-web leaves sessions and chats running, and the next server picks them up, approvals included. Under systemd, set KillMode=process. (#5)
• Runs fuseraft out of process over its versioned wire protocol, so a fuseraft upgrade can't break the build. (#1)
• Pages: Sessions, REPL, HITL approvals, Builder, Schedule, Memory, Configs, Context, Plugins, Model Profiles, and Daemons for attaching to fuseraft serve. (#2, #3)
• Self-contained archives for Linux, macOS and Windows; no .NET install needed. (#5)

What's Changed

• refactor: run fuseraft out of process over the wire protocol by @fuseraft in #1
• feat: bring back the Memory, Schedule, Configs and Builder pages by @fuseraft in #2
• feat: add a Daemons page that attaches to fuseraft serve over WebSocket by @fuseraft in #3
• docs: add a Daemons page screenshot to the README by @fuseraft in #4
• feat: accounts, per-user fuseraft homes, a real build, and sessions that outlive the server by @fuseraft in #5

New Contributors

• @fuseraft made their first contribution in #1

Full Changelog: https://github.com/fuseraft/fuseraft-web/commits/v0.1.0