We sit above FlightHub, not against it.
FlightHub is strong at operating a contained DJI fleet. FlightStudio governs the wider airspace programme and can synchronise the DJI records you choose to bring across.
Pull sync · outbound writes off by default · source records retainedWhich problem are you actually solving?
A contained DJI fleet and a multi-operator airspace programme overlap, but they are not the same job.
- FlightHub: DJI fleet, docks, tasks, livestreams
- FlightStudio: approvals, UTM, risk, conformance, evidence
- Use both when both jobs exist
Twelve dimensions, no sneering.
The meaningful differences are ownership, airspace scope, standards evidence, cross-vendor operations, approval workflow, and deployment boundary.
- Self-hosted or air-gapped deployment
- ASTM F3548 and F3411 roles
- SORA 2.5 and ED-269 workflow
- Multi-operator and authority tenancy
Deep enough to be worth doing.
The adapter maps FlightHub organisations, projects, devices, completed flights, telemetry, and related references into durable FlightStudio records.
- Idempotent pull synchronisation
- Source identifiers retained
- Per-class direction controls
- Health and sync history in the marketplace
You keep your history. All of it.
Disconnecting the adapter stops synchronisation. It does not delete the Sites, assets, completed flights, or telemetry already stored in your database.
- No vendor tenant dependency
- Open-format evidence export
- Reconnect without duplication
- Outbound push requires explicit enablement
Point it at your organisation and watch what lands.
Use a trial deployment to inspect the mapping and verify the retained history before planning a cutover.