2GT-RichandClaude Opus 5
1a4b635052
CI / Deployment files in sync (push) Canceled after 0s
CI / Frontend — Lint, Type-check, Test & Build (push) Canceled after 0s
CI / Backend — Lint, Type-check & Build (push) Canceled after 0s
CI / Security Audit (push) Canceled after 0s
CodeQL Security Analysis / Analyze (javascript-typescript) (push) Canceled after 0s
Documentation / Build (check only) (push) Canceled after 0s
Documentation / Publish versioned site (push) Canceled after 0s
Publish to GHCR / Build & Push Backend (push) Canceled after 0s
Publish to GHCR / Build & Push Nginx (Frontend) (push) Canceled after 0s
Release / release (push) Canceled after 0s
A regression I introduced in v0.24.3, and described inaccurately in its own commit message. Adding concurrency moved the halt check to the end of a wave. I wrote that "at the default of 1 those are the same moment". That is only true of a wave holding one device. With several devices in one wave and the default sequential setting, the old code stopped the moment one failed; mine went on to attempt every remaining device in that wave first. Anyone relying on halt-on-failure with a wide wave 1 got a wider blast radius than before, without changing a setting. Halting now stops further devices from *starting* as soon as a failure is known, whatever the concurrency. Devices already in flight are allowed to finish, because interrupting one mid-write is how you brick it. At concurrency 1 that is precisely the previous behaviour. Above 1, only the devices genuinely running side by side can carry a bad build -- which is the unavoidable part of the trade in #135, rather than a cost imposed on rollouts that never asked for concurrency. The firmware documentation said the same wrong thing and is corrected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MikroTik Manager documentation
Reference material for people already running the platform. If you are still deciding whether to try it, the project README is the better starting point.
| Document | Covers |
|---|---|
| Configuration | Environment variables, secret management and key rotation |
| Sites | Grouping devices into sites, switching between them, and what each site scopes |
| Change Guard and Config Health | How the safety system works, its settings, and what to expect when it fires |
| Alerting | Alert rules, delivery channels, webhooks, scheduled reports, maintenance windows |
| Single sign-on (OIDC) | Identity provider setup, group-to-role mapping, break-glass behaviour |
| CAPsMAN | How centrally provisioned access points are modelled, and current limits |
| Cellular (LTE) | Signal, carriers, tower movement, and the data-cap reset SMS |
| SSH keys | Per-device keypairs, rotation, and what installing one costs |
| Bulk commands | Running one command across a fleet, in waves |
| Firmware rollouts | Waves, the upgrade pipeline, and what upgrading several at once costs |
| Backups | Finding, reading, comparing and deleting configuration backups |
| Polling and scaling | Poller health, headroom, tuning, and clearing a backlog |
| API and automation | Scoped tokens, authentication, and driving the platform from scripts |
| Architecture | How the system is put together, for contributors |
Conventions used here
- Settings in the UI are stored in the database and apply without a restart.
- Environment variables live in
.envand require a container restart to change. - Anything described as read-only makes no writes to your devices.
Which version is this?
These pages describe a specific release, shown in the header. The platform ships frequently, so if something here does not match what you see, check that the version you are running matches the version you are reading.