julian
96acd6b662
Camera snapshots were stored RAW — the camera's full-res JPEG straight into the BLOB, no resize/recompress. Measured on the dev DB: 300 snapshots = 81.7 MB = ~72% of the 114 MB SQLite file (the big ones 2688×1520 / ~600 KB, Hikvision main stream). They dominated the appliance's single backed-up DB file. Re-encode on capture (snapshot.ts): - Downscale each frame to SNAPSHOT_MAX_EDGE (1280px long edge) + recompress at SNAPSHOT_JPEG_QUALITY (80) via sharp (libvips, Apache-2.0) before storage — ~6-10× smaller (verified 2688×1520 → 1280×724, ~8×), plate still readable, clean image/jpeg (drops the camera's charset cruft). STORAGE-ONLY: recognition keeps the ORIGINAL full-res bytes (downscaling hurts OCR). Fail-soft — a re-encode error stores the original, never drops the snapshot or blocks the (already-open) path. sharp lives in apps/server (owns the capture path), where bcrypt already establishes the native-dep pattern. Disk-pressure retention (snapshot-retention.ts) — a SAFETY VALVE, not the daily mechanism (the re-encode does that). Daily check reads the DB filesystem used% (statfs on db.$client.name); no-op unless ≥ SNAPSHOT_DISK_HIGH_PCT (70). Over the mark: delete the OLDEST until an estimated SNAPSHOT_DISK_FREE_TARGET_PCT (10%) of disk is freed — never below SNAPSHOT_MIN_KEEP (500) — then VACUUM once to return space to the OS. A DELETE only frees SQLite pages (disk doesn't drop until VACUUM), so the loop is driven by estimated freed bytes (SUM(length(bytes))), not a live disk re-read; the prune owns the DB-locking VACUUM, run daily off-peak. diskUsage is injectable for tests. None of this touches the signed ledger — snapshots are unsigned/advisory, referenced only by id. Tests: encodeForStorage (downscale / clean-type / no-enlarge / fail-soft) + pruneSnapshots (no-op below mark / delete-oldest-to-target + VACUUM / MIN_KEEP floor / skip-VACUUM-when-empty). All four snapshot env knobs documented in the komodo env reference. Full workspace build/lint/test green; the prune smoke-verified on a scratch DB copy (file shrank after VACUUM). Existing ~81.7 MB of raw snapshots are unchanged (a one-off re-encode backfill is a separate optional follow-up). Updated entry-exit-points + technology-stack wiki. Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
komodo/ — fleet deployment as code
Infra-as-code for the Komodo Core control plane that deploys the parking appliance to the
booth fleet over the NetBird mesh. See wiki/decisions/fleet-deployment-komodo.md for the
rationale, threat-model analysis, and the three settled choices (many/growing fleet · deploys
are manual + pinned · secrets are Komodo-managed, per-booth).
This directory does not change how images are built or how the app runs — it's only the
control plane. The booth still runs the same docker-compose.yml + docker-compose.prod.yml
(container-deployment); Komodo just drives them remotely instead of someone SSH-ing in to
run booth.sh.
Files
resources.toml— the Komodo resource definitions (Servers, Stacks, optional Builders/ Procedures), synced into Core via a ResourceSync. This is the reviewable, version- controlled source of truth for which booth runs what..env.komodo.example— the variables a Stack expects, documenting what comes from Core's secret store (per-boothJWT_SECRET/EVENT_SIGNING_KEY) vs. plain Stack env.
How Core consumes this (one-time)
In Komodo Core, create a ResourceSync pointing at this repo + path (komodo/resources.toml),
on the branch you manage from (e.g. main). Core reads the file and reconciles Servers/Stacks to
match. Thereafter, a PR to this directory + a sync is how you change the fleet — no clicking.
Komodo's TOML schema evolves across releases. Treat
resources.tomlas a starting sketch:resources.tomlmirrors the workingpark-buziStack (built by hand in the Core UI, then exported to TOML — so field names match the running Komodo version, v2.2). Import it into the sync Unmanaged first and review the diff; it should be ~empty against the live Stack.
How servers get created — NOT here
There is no [[server]] block in resources.toml. Servers are created by the Periphery
agent onboarding outbound: in Core, create a one-time Onboarding Key (Settings →
Onboarding), then install Periphery on the booth passing --onboarding-key + --core-address
(Core's reverse-proxy URL, reached over the NetBird mesh) + --connect-as=<booth-name>. The
agent self-registers, generates its own auto-rotating key pair (private key never leaves the
booth), and connects outbound — the booth opens no inbound port. The sync owns only the
Stack, which references the server by the name it onboarded as (server = "park-buzi"). See
wiki/decisions/fleet-deployment-komodo.md.
Adding booth N
Copy the [[stack]] block, change name, server (its onboarded name), and the per-booth
secret references ([[park_<site>_jwt_secret]], [[park_<site>_event_signing_key]]). Create
those secrets in Core's store first.
Hard rules encoded here (do not relax without updating the decision page)
- No deploy webhook on a booth Stack. Deploys are a human action; pin
TAG=dev-<sha>before a production booth goes live. A moving:devon a production booth is the non-determinism we rejected. (TAG=devhere is fine while staging.) - Onboarding, outbound, mesh-only. Servers self-register via an onboarding key; Periphery connects outbound to Core's mesh URL and exposes no inbound port. Never a LAN/WAN address.
- Secrets are per-booth and unique.
EVENT_SIGNING_KEYsigns the anti-fraud ledger — one leak must taint one booth, never the fleet. Reference Core secrets by name; never inline a real value in this file (it's in git). - Volumes preserved. The Stack must never run
compose down -v— that would wipe theparking-datavolume (the signed ledger). Komodo's "destroy" is gated for the same reason.