Check-in device fleet registry (lightweight ops schema)

For small teams (you + a few admins), keep fleet tracking lightweight but structured so it can move into a database or admin UI later without reinventing fields.

At current scale, Notion (databases) or Google Sheets (three tabs / linked tables) is enough. Plan to migrate around 10+ devices to something queryable (e.g. Supabase tables + internal admin) when reporting and automation matter more.

Related: on-site hardware expectations and remote access are in the first-client preflight checklist (role-based). For a sub–10-minute install time budget and pre-staging checklist, see on-site install runbook.

1. Device registry (one row per gate / check-in unit)

Field	Example	Notes
`device_id`	`CHK-001`	Internal serial; use a consistent prefix + sequential number
`hostname`	`chk-gate-001`	Set on the device OS; should match how you find it in Tailscale
`tailscale_ip`	`100.x.x.x`	Stable once the node is registered
`tailscale_tag`	`tag:checkin-device`	Prefer a small set of shared tags for ACLs (e.g. all check-in units share one tag)
`auth_key_ref`	`ak-chk-001`	Reference name only — not the secret key (see §3)
`hardware_rev`	`v1.0`	Prototype / BOM iteration you care about in support
`nfc_reader_serial`	`READER-…`	Serial from the credential reader (record whatever your team standardizes)
`status`	`active` / `spare` / `retired`	Fleet state for spares and decommissioning

Optional columns you may add later: facility_id / customer_slug when a unit is long-term assigned (still keep deployment history in §2).

2. Deployment log (one row per deployment event)

This is the table teams skip early and regret. It answers: which physical unit was at which customer or venue, when, and who touched it — essential after a bad cable, wrong accessPointId, or mystery network issue.

Field	Example
`device_id`	`CHK-001`
`customer`	`Actor Boy Awards`
`location`	`Little Theatre, Kingston`
`deployed_at`	`2026-05-10`
`retrieved_at`	`2026-05-11` (nullable if still on site)
`deployed_by`	`David`
`notes`	`Left charger on site`

Practice: Log every move: dry run, pilot, event, return to bench, RMA swap.

3. Auth key registry (separate, private)

Store only metadata here. Never paste Tailscale (or other) auth key values into the main registry or a shared Sheet the whole company can read.

Field	Example
`key_ref`	`ak-chk-001`
`device_id`	`CHK-001`
`created_at`	`2026-04-01`
`expires_at`	`never` or a date
`revoked`	`false`

Where the secrets live: password manager (e.g. Bitwarden) or your cloud provider’s secret store, keyed by key_ref / device_id.

Rotation: When a key is rotated or revoked, update revoked / expires_at and issue a new key_ref; don’t reuse names for a different secret.

Practical format (today vs later)

Phase	Recommendation
Now	Notion with three linked databases, or Google Sheet with three tabs + strict “no secrets in Sheet” rule for §3
Later (~10+ devices)	Supabase (or similar) tables + optional internal admin; same column names as above to ease migration

Sign-off (optional)

Use this when handing a unit to a client or closing a deployment.

device_id	customer / location	deployed_at	deployed_by	Notes