v0.24.3-beta shipped without a release. The workflow compared the version in
HEAD against HEAD~1, so a bump pushed together with any follow-up commit —
here a docs commit — was no longer the tip and nothing looked changed.
It now asks whether a tag for the current version already exists. That does
not care how commits are batched, is safe to re-run, and makes the job
idempotent rather than dependent on push shape. The paths filter is dropped
for the same reason: the tag check is the real guard.
Release notes are taken from the commit that last touched the version rather
than the tip, since a bump is often followed by docs or CI commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes#130. Multi-site, not multi-tenancy: a site is a named collection of
devices whose clients, events, topology and dashboards are viewed separately.
Sites separate what you see, not who you are — the admin/manage/read-only
roles are unchanged and every user sees every site. Per-site permissions
would have multiplied the work for a need nobody stated.
Two measurements decided the design.
Every device-derived table hangs off devices(id) — 25 of 50 tables, 35
foreign keys — so a single site_id column on devices scopes clients, events,
topology, backups and the rest transitively. No other table needed one.
The frontend has 162 useQuery call sites across 57 files. Threading a site
through each would be a large change that leaves a permanent trap: every
future query another chance to forget. The site is injected in the existing
axios interceptor instead, beside the auth token, so a new query is scoped by
default. Only 23 collection routes needed filtering; the 131 per-device
routes are already scoped by their device.
Existing installs are untouched. Migration creates one "Default Site", adopts
every device into it, and a single-site install never meets the concept. An
absent X-Site-Id header means unscoped, so existing API tokens and scripts
behave exactly as before.
Polling stays fleet-wide. Sites are a view over data already gathered, not a
change to how it is gathered — a device does not stop being monitored because
you are looking elsewhere. Rogue-AP detection scopes the scans but keeps the
"these are ours" BSSID set fleet-wide, or your own AP in another site reads
as an evil twin. Bulk actions do obey the selector: an operation that
silently spanned two customers is the blast radius the wave guards exist to
contain.
Four rounds of defects came out of testing the UI rather than the API, and
the first is the one worth recording. Switching sites called
queryClient.clear(), which empties the cache and reviews as correct. It
isn't: clear() destroys each query but a *mounted* observer keeps its own
reference and last result, so every rendered page went on showing the
previous site's data. The QueryClient is now keyed on the site, which
remounts the tree against an empty cache. Three tests pin the old behaviour
down so the shortcut cannot return.
The others: an unscoped fallback path behind the Connected Clients chart;
Config Health, TX retries and the activity feed reading fleet-wide; and
site_id added to the device list query but none of the other four that build
a device payload, so the Site field could not read its own value and appeared
to reject every change while the writes were landing. That last one is now
structural — DEVICE_BASE_COLUMNS is shared by all five, with a test that
fails when a device payload is hand-rolled, and which found two further
instances while being written.
Frontend tests were never run by CI despite vitest being configured and six
suites existing; they now run in both the workflow and ci-preflight.
Verified against a live four-device fleet: the migration left every figure
identical, an empty site returns zero from every read endpoint, moving a
device carries its history with it, and deleting a site with devices is
refused.
Minor bump rather than patch: sites change the shape of the product rather
than adding to it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes#121.
The Quick Deploy file was missing NETFLOW_BIND_PORT and the 2055/udp mapping, so
the collector bound inside the container and nothing reached it. NetFlow did
nothing, silently, with an empty traffic page and no error — for everyone
following the path the README tells new users to take.
The report was accurate and understated. docker-compose.ghcr.yml had drifted for
seven weeks, and three closed issues had never reached it:
* NETFLOW_BIND_PORT and the UDP port — as reported
* all five POLLER_* tunables — #114, whose fix was "pass the tunables through"
* the Redis memory ceiling and eviction policy — #116
* TZ on the postgres service, which nobody had noticed at all
The middle one is the uncomfortable part. Four days ago #114 was closed by
forwarding poller settings that were documented but inert, with a comment saying
setting them "did precisely nothing". On Quick Deploy that remained true, because
one compose file was fixed and the other was not — including the advice given to
that reporter about which knob to turn.
So patching the four gaps would have been treating the symptom. The two files
describe the same system and differ only in where images come from; maintaining
both by hand meant remembering every change twice, and the one forgotten was
always the file no maintainer runs.
docker-compose.ghcr.yml is now generated from docker-compose.yml by
scripts/generate-ghcr-compose.mjs, which performs the two build-to-image swaps
and nothing else. Substitution is textual rather than parse-and-reserialise so
comments survive — the reasoning about Redis eviction is worth more than the two
lines it explains. The file stays committed and browsable, because the README
tells people to curl it directly.
A --check mode runs as the first preflight gate and as its own CI job, both of
which fail when the committed file does not match what the generator produces.
Verified by deleting the NetFlow line and watching the guard reject it, with the
reason and the fix in the failure message.
Reported by @mamb1329, on their first issue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two pieces of housekeeping that had gone quiet.
**A code-scanning alert nobody had looked at.** CodeQL flagged js/log-injection
in the preflight handler: a request value interpolated straight into a log line.
Log entries are newline-delimited, so a value containing a line break forges
additional entries — and an audit trail its own subject can write into is worse
than none, because it is believed.
The interesting part is that the risk had already been recognised. Two sites in
the clients routes strip carriage returns inline, ad hoc, and the third was
simply missed. That is what a shared helper is for, so there is now a `logSafe`
utility with tests, used at all three. It replaces control characters with a
visible marker rather than stripping them, so a tampered value reads as tampered
instead of being quietly tidied, and truncates absurd input so one field cannot
flood the log.
**Twelve Dependabot pull requests, the oldest six weeks old.** Nine had passing
checks, but those runs were from July against a main that has moved a long way,
so rather than merging stale branches serially the eight safe ones are applied
here as one change and verified together: bullmq, pg, helmet, @types/supertest,
tailwind-merge, vite, actions/setup-node and github/codeql-action.
Deliberately excluded, and left open:
* bcryptjs 2.4.3 to 3.0.3 (#79) — a major on the password-hashing path.
Dependabot groups it with routine bumps; it is not one, and it deserves
its own verification rather than riding along in a batch.
* typescript 5.9 to 7.0 (#81), tailwindcss 3.4 to 4.3 (#76) and
eslint-plugin-react-hooks (#78) — all three already fail their own checks.
Verified beyond the gates: the application was rebuilt and exercised on the new
dependencies — authentication, the BullMQ-backed poller, Postgres reads and
helmet's headers all behave.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The release notes were passed through a step output and interpolated straight
into the gh command. Commit messages here routinely contain backticks, so the
shell evaluated them as command substitution — which failed the first release
outright, and would let a commit message run arbitrary code in CI.
Notes are written to a file and passed with --notes-file; nothing from the
commit reaches a shell as code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The dashboard sends people to the releases page to see what changed. That page
held a single entry from five months earlier while the product shipped several
times a day, which tells a visitor the project is abandoned — raised on #119,
and the more useful half of that thread.
A release is now cut whenever the shipped version changes, tagged to match the
container image so the thing you are running and the notes you are reading carry
the same number. Notes are the commit body rather than a generated list of
subjects, because the commit messages here already explain what changed and why.
Betas are marked pre-release so nobody is pointed at one by accident.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The default cache glob matches requirements.txt or pyproject.toml, and the
documentation toolchain is deliberately kept separate from the application's —
so setup-python found nothing and failed the job before it could build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes#112.
Source stays `docs/*.md`, rendered by MkDocs-Material and published to GitHub
Pages by Actions. Same repository on purpose: documentation drifts, and
co-location is the only thing that reliably prevents it — the pull request that
changes behaviour changes the description, and review sees both. A separate repo
would double the ceremony and guarantee divergence.
The markdown remains readable when browsing the repository, so the site renders
those files rather than replacing them.
**Versioned from the start**, using mike. Images are published to GHCR and this
project ships betas most days, so readers are routinely running something other
than the newest build; a single "latest" would confidently describe a release
they do not have. Versions follow the product rather than the docs, so the site
and the running image carry the same number.
**Content came first, and it had to.** The docs were eleven days and sixteen
releases stale — SSH keys, bulk commands, the data-cap SMS, poller health and the
timezone setting appeared in exactly zero files between them. Publishing that
would have given documentation missing five of the most consequential features a
polished, authoritative home, and a well-presented wrong answer is worse than an
obviously rough one. Four pages now cover them:
- cellular.md — signal grading, carrier aggregation, the uplink anchor,
observed bands, and the data-cap SMS including why it fires early and how to
calibrate the margin
- ssh-keys.md — leading with what installing a key costs, because RouterOS
disables password SSH for that user and the database becomes load-bearing
- commands.md — why waves exist, and why reading output matters when RouterOS
reports failure in text rather than an exit code
- scaling.md — headroom, why it is insufficient on its own, and every tunable
Pull requests build the site with `--strict`, which turns warnings into errors.
That is the point of running it there at all, and it earned itself immediately:
the first build failed on two links to the project README, which sits outside the
docs tree. They are absolute now, so they resolve both in the rendered site and
when reading the markdown on GitHub.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Security Audit job failed because new advisories dropped against existing
deps and `npm audit --audit-level=high` audits the whole tree (incl. dev/build
tooling that isn't shipped).
- Switch both audit steps to `audit-ci --high --skip-dev`, so the gate reflects
what's actually deployed (backend ships --omit=dev; frontend ships a static
build) while still failing on real high/critical production advisories.
- Allowlist GHSA-qwww-vcr4-c8h2 (React Router "RSC Mode CSRF") for the frontend:
this is a client-side SPA using BrowserRouter — RSC mode is not used — and
there is no forward-compatible fix for react-router-dom 7.x (only a downgrade).
- `npm audit fix` on both lockfiles to patch non-breaking transitive dev
advisories (js-yaml, postcss, brace-expansion, minimatch). No direct/prod
dependency versions changed; app runtime is unchanged.
Verified: backend 114 tests pass, frontend builds, and audit-ci passes for both
projects locally.
Address the open CodeQL code-scanning alerts:
- guestWifi voucher codes now use rejection sampling so the character
distribution is uniform (fixes js/biased-cryptographic-random).
- Scheduled-report recipient validation replaced the backtracking email regex
with a linear split-based check (fixes js/polynomial-redos).
- Add .github/codeql/codeql-config.yml excluding js/missing-rate-limiting:
rate limiting is applied globally via app.use('/api', rateLimitRedis) plus
per-route limiters, which CodeQL can't attribute to individual handlers, so
that rule fired ~38 false positives.
Remaining alerts are dismissed as accepted/false-positive (RouterOS MD5 API
login and self-signed cert acceptance are protocol-mandated; log sites already
strip CRLF).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add docker/setup-qemu-action and platforms: linux/amd64,linux/arm64 to
both the backend and nginx build-push steps so GHCR images run natively
on arm64 (ARMv8) hosts instead of amd64-only. Refs #56.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
docker/build-push-action@v6 renamed the parameter from 'dockerfile' to
'file'. The backend succeeded by luck (default Dockerfile matched), but
nginx failed because the Dockerfile isn't in the root context directory.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds a GitHub Actions workflow that builds and pushes backend and nginx
images to GitHub Container Registry on every merge to main and on
releases. Adds docker-compose.ghcr.yml for end users who want to deploy
without cloning the repo, and updates the README with Quick Deploy
instructions alongside the existing build-from-source guide.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Dependabot was logging warnings on every PR because the configured
labels (frontend, backend, dependencies, etc.) don't exist as GitHub
labels in this repository. Removing them stops the noise.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- SECURITY.md with vulnerability disclosure policy and self-hosting guidance
- Dependabot config for weekly dependency updates (npm, Docker, Actions)
- ESLint v9 flat config for frontend and backend, with eslint-plugin-security
- GitHub Actions CI: lint, typecheck, build, and npm audit on every push/PR
- CodeQL workflow for automated security scanning (runs on push and weekly)
2GT-RichandClaude Opus 5
dependabot[bot]