Files
PilotVault/API Server
tajniak81andClaude Opus 4.8 33595c99e8 Add a Drones fleet section that fills itself in on connect
The fleet lived as a tab inside the Logbook, which buried it, and every
drone had to be typed in by hand — model, serial and firmware copied off
an airframe the app was already talking to.

Promote it to its own nav section above Logbook, and let a connecting
drone register itself. The Fly App already forwarded model, serial and
firmware upstream; the hub was keeping only the model. It now carries the
identity through to DeviceState, and the Web App offers it to a new
POST /api/drones/auto, which upserts keyed by serial. The auto path only
writes what the aircraft is authoritative about (model, both firmware
versions) and never touches what the pilot curates.

Serial and the firmware versions resolve on their own schedules after
connect — the serial in seconds, the aircraft firmware sometimes a minute
later — so nothing along the path treats an absent value as a cleared one,
and a later event filling firmware in still reaches the server. The auto
call rides every telemetry frame, so the client remembers the identity
tuple it last sent and only a change goes out; a 4xx is the server's
settled answer and is not retried, or one drone connected for an hour
would mean one request per frame for an hour.

New fields on drones: firmware, controller_firmware, and registration for
the FAA/CAA aircraft number — distinct from operator_number, which stays
the EU operator ID. Controller firmware is the remote controller's own
version, read from its component; the flight controller's version is a
different quantity and stays off this field (see 002e484). name becomes
optional and is now the pilot's custom name: auto-added drones arrive
unnamed, so the API serves a computed displayName (name, else model +
serial) for the fleet table, the flight picker and the CSV export. A
unique index on serial is what keeps the find-then-create path from
forking a drone's history across two records.

The schema is applied to the remote PocketBase; the migration is here for
fresh deployments, which the remote does not read.

Verified against a simulated device over the real socket with identity
resolving late: one record from four events, both firmware versions
filled, curated fields intact across re-registration, and a drone deleted
while connected coming back on the next frame.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 17:04:12 +02:00
..

PilotVault — API Server

Go service that is the single entry point for PilotVault. The Fly App streams drone telemetry to it; the Web App and the built-in API Web Panel read live state and issue commands. It keeps device state in memory and proxies authentication to a PocketBase kept behind it (PocketBase's address is never exposed to clients).

Fly App  ──►  /ws/device  ┐
                          ├─►  API Server (:8080)  ──►  PocketBase (auth only)
Web App  ──►  /ws/ui      ┘

The server root (GET /) serves a PilotVault-branded web panel: a live health readout plus a quick reference of both API audiences. Open http://localhost:8080/ in a browser to check the server at a glance.

The panel is a Vue 3 + Tailwind v4 app in panel/, built into internal/api/dist and embedded into the Go binary at compile time:

cd panel
npm install
npm run build        # outputs to ../internal/api/dist
cd ..; go build -o api-server.exe ./cmd/server   # embeds the fresh dist

For panel development with hot reload (proxies /api to a running server on :8080): cd panel; npm run devhttp://localhost:5174.

Requirements

  • Go 1.24+ (go version)
  • Node 18+ (only for building the panel)
  • A reachable PocketBase instance with a users auth collection (for login). To persist user settings, that collection needs a preferences JSON field — see pocketbase/README.md.

Configure

Copy-Item .env.example .env
# edit .env: set POCKETBASE_URL (and CORS_ALLOW_ORIGINS if needed)
Variable Purpose Default
API_ADDR Listen address :8080
POCKETBASE_URL PocketBase base URL (login proxy). Legacy PB_URL still honoured. http://10.2.1.10:8026
CORS_ALLOW_ORIGINS Comma list, or * *

Run

./scripts/Run-ApiServer.ps1
# or:  go run ./cmd/server

Health check: GET http://localhost:8080/healthz.

API

Client / dashboard endpoints

Method Path Description
GET /healthz, /api/health Readiness probe + device count (public)
POST /api/auth/login {email, password} → PocketBase session (proxied)
GET /api/auth/validate Validate the Authorization token
GET /api/me Caller's {id, email, role, organization, organizationName} resolved from their token
GET /api/preferences Read the caller's saved settings blob (from their PocketBase user record)
PUT /api/preferences {preferences} → persist the caller's settings onto their user record
GET /api/users List users (manager; admin → own org, superadmin → all)
POST /api/users {email, password, role, organization?} → create a user (manager; admin scoped to own org)
PATCH /api/users/{id} Edit {email?, role?, verified?, password?, organization?} (manager; scope-checked; cannot demote self)
DELETE /api/users/{id} Delete a user (manager; admin → own org only; cannot delete self)
GET /api/orgs List organizations (manager; admin → own org, superadmin → all)
POST /api/orgs {name} → create an organization (superadmin only)
PATCH /api/orgs/{id} {name} → rename an organization (superadmin only)
DELETE /api/orgs/{id} Delete an empty organization (superadmin only)
GET /api/admin/pb-config Read the PocketBase connection + a live probe (superadmin only)
POST /api/admin/pb-config/test {url?, adminEmail?, adminPassword?} → probe a candidate connection without applying (superadmin only)
PUT /api/admin/pb-config {url, adminEmail?, adminPassword?} → apply at runtime + persist to .env (superadmin only)
GET /api/admin/plugins List plugins with state + last health (superadmin only)
POST /api/admin/plugins {name, baseURL, provider?} → register an external plugin, no rebuild (superadmin only)
GET /api/admin/plugins/{name} One plugin's view (superadmin only)
PUT /api/admin/plugins/{name} {enabled?, config?} → enable/disable + configure (superadmin only)
DELETE /api/admin/plugins/{name} Remove an external plugin (superadmin only)
POST /api/admin/plugins/{name}/health Run a health check now (superadmin only)
GET /api/devices List devices and their last-known state
GET /api/devices/{id}/track GPS track history for a device
POST /api/devices/{id}/command Send {command, payload?} to a connected device
DELETE /api/devices/{id} Forget a device's stored state
GET /ws/ui Live telemetry stream (WebSocket)

Device endpoints (Fly App)

Method Path Description
GET /ws/device?id={id} Telemetry uplink (WebSocket)
POST /api/telemetry?id={id} Push a single telemetry event over HTTP

Telemetry events

Device messages carry a type: registration, connection, battery, or telemetry (altitude, lat/lng, velocity, GPS sats, flight mode…). The server merges them into a per-device DeviceState and fans each update out to every connected dashboard as {type:"update", device, event}. latitude/longitude samples are appended to the device's GPS track.

Plugins

The server integrates external third-party services through a uniform plugin contract (internal/plugins), managed by a superadmin from the panel. Two kinds share one interface:

  • Built-in — Go connectors compiled into the server (type-safe, first-party). The reference example is OpenSky Network (internal/plugins/builtin/opensky), a live ADS-B flight-state connector with an OAuth2 / anonymous auth provider. Adding a new built-in needs a rebuild.
  • External — a remote HTTP service registered at runtime, no rebuild. It answers a small contract (GET /health, GET /manifest, POST /invoke) and can run as its own process/container (the sandboxing story).

Enable-state and per-plugin config (secrets included) persist to a local, gitignored plugins.json (override with PLUGINS_FILE), loaded on boot. Every plugin exposes a real HealthCheck. Deferred extension points (invocation API, retry/circuit-breaker, per-tenant credentials, audit logging) are documented in internal/plugins/doc.go.

Writing a plugin: see the developer guide internal/plugins/README.md — step-by-step for both built-in (Go) and external (HTTP, no rebuild) plugins, with complete examples.

Project layout

cmd/server/main.go       entry point, wiring, graceful shutdown
internal/config          env/.env configuration
internal/hub             in-memory device state + websocket fan-out (drone core)
internal/api             router, middleware, handlers, embedded panel
internal/plugins         plugin contract, manager, external kind + built-in connectors
panel/                   Vue 3 + Tailwind v4 web panel (built into internal/api/dist)
scripts/                 run helper