Implemented Features
One page for each feature that has shipped: what it gives you, how it fits into Nixstasis, and what turned out differently from the plan. Each page links to the feature's original design record.
Add Rule Modal Improvements
The Add/Edit Rule dialog on /alerts now works like the report dialog: the same validation, keyboard shortcuts, focus
Ash API Contract Unification
2 items
AtomixOS Bootstrap Provisioning
An operator can give a freshly installed, approved, online AtomixOS device its complete first configuration: a
AuthCrunch Role Contract
Caddy and AuthCrunch turn identity-provider groups into three Nixstasis roles: viewer, operator, and admin. Phoenix
Bounded LiveView Catalog Reads
1 item
Compose Dev Harness
A development lab that runs the whole stack on a laptop with one command: Phoenix, PostgreSQL, Caddy, FRPS, and
Dashboard Device Groups
Operators can organize devices into groups from the Devices view. A device can be in any number of groups, and a group
Dashboard Home
The home page gives operators a picture of the fleet at a glance: total devices, how many are online, approvals
Device Detail Page
Each device has its own page, opened from the Devices list, where operators can see its telemetry and PCP metrics,
Docusaurus Documentation Site
The documentation site is built with Docusaurus instead of mdBook. It has offline full-text search, light and dark
Go Client Rewrite
The agent on each device is now a single Go program that runs as a CLI and as a service. It handles the device's
In-Memory SSH Authorized Keys
Browser terminals no longer write SSH keys to authorized_keys files. Instead, OpenSSH asks the client, through
IoT Device Monitoring
The core of Nixstasis: devices register and wait for approval, keep lasting credentials, send authenticated heartbeats
Packaging and Deployment Migration
There is now one supported way to deploy the server, with Docker Compose, and one way to release the client, with
Phoenix UI Polish
The web UI got a consistent, responsive look and feel: a shared page layout, readable screens for dense operational
Production Operations Runbooks
Operators have a set of runbooks for the supported Compose deployment: backup and restore, secret rotation, health
Report View Improvements
The report list and report pages are easier to work with: clear details about each report, explicit actions, results
Rich API Examples
The API documentation includes copyable examples of both successful and failed requests for the device, Caddy
Schema-Driven Builder Dropdowns
When you build an alert rule or a custom report, the field pickers now list the fields your devices actually report,
Self-Extracting Installer
Client releases include a .run installer for each architecture, for systemd Linux hosts that don't use deb or rpm
Server Command Allowlist Management
Operators can define which commands device scripts may run. Each entry maps a command name to an absolute path, entries
Server Curated Command Package Catalog
A command catalog, kept on the server, sits on top of command policies. In Scripts → Command Policies, operators
Server Stary Script Workbench
Operators can write and edit Stary scripts in the web UI, validate them, test them on chosen devices, read each
Server-Client E2E Tests
An end-to-end test harness, driven by the client, runs whole suites or chosen journeys against the server, which checks
Server-Provided FRPS Token
Devices no longer share one FRPS secret. Instead, while a device has an authorized remote-access lease, each heartbeat
Starlark Script System
The client runs .stary telemetry scripts: YAML front matter, Starlark code, and a schema for the output. It can