Skip to main content
Mission Control includes an optional Convex backend that adds authentication, fleet synchronization, community features, and cloud relay capabilities. Cloud features are entirely optional. The GCS works fully offline for USB and local WebSocket connections.

​
What Cloud Adds

FeatureWithout CloudWith Cloud
USB/WebSocket connectionsYesYes
All configuration panelsYesYes
Mission planningYesYes
Video feed (LAN)YesYes
Authentication & profilesNoYes
Fleet sync across devicesNoYes
Cloud relay to remote dronesNoYes
Community changelogNoYes
Community roadmapNoYes
Contact formNoYes

​
Architecture

The cloud backend is built on Convex, a reactive backend platform. The GCS repo includes a complete convex/ directory with 25 tables (7 auth + 18 custom). Key tables:
TablePurpose
profilesUser profiles with roles (admin, member, viewer)
cmd_droneStatusCloud relay drone status (heartbeat from agent)
cmd_droneCommandsCloud relay command queue (GCS enqueues, agent polls)
cmd_missionsStored missions synced across devices
cmd_preferencesUser preferences synced to cloud
communityChangelogPublic changelog entries
commentsComments on changelog, roadmap, and other content
contactSubmissionsContact form submissions

​
Cloud Relay

When the GCS runs on HTTPS, it auto-activates cloud mode. This enables connecting to remote drones through the Convex backend. The cloud relay has three layers:
The simplest layer. The Drone Agent POSTs status to the Convex backend every 5 seconds. The GCS subscribes to reactive queries.
  • Latency: 2-5 seconds
  • Infrastructure: Just the Convex backend, nothing else
  • Use case: Monitoring, fleet overview, non-critical telemetry

​
Authentication

Cloud mode uses Convex Auth with a password provider. Users sign up with email and password. The first user to register is automatically granted admin role. Roles:
  • Admin: Full access. Manage users, view all drones.
  • Member: Standard access. View paired drones, use community features.
  • Viewer: Read-only. Can view fleet status but cannot send commands.

​
Community Features

The community section (/community route) provides:
  • Changelog: Browse project updates and release notes. Admins can create and edit entries.
  • Roadmap: View the project roadmap as a kanban board.
  • Contact form: Submit feedback or questions.
These features are powered by Convex reactive queries, so updates appear in real time for all connected users.

​
Self-Hosting

You can deploy your own Convex backend and run the full cloud stack independently.
1

Install Convex CLI

npm install -g convex
2

Start the dev backend

From the ADOSMissionControl directory:
npx convex dev
This starts a local Convex development backend and pushes your schema and functions.
3

Set the URL

Copy the Convex URL from the terminal output and set it in your .env:
NEXT_PUBLIC_CONVEX_URL=https://your-deployment.convex.cloud
4

Start the GCS

npm run dev
Cloud features are now active, pointing at your own backend.

​
Production Deployment

For production, deploy the Convex backend to Convex Cloud (free tier available) or self-host using Convex’s open-source backend with Docker and SQLite. 
# Deploy to Convex Cloud
npx convex deploy

# Or self-host with Docker
docker compose up -d
The self-hosted option stores all data in a local SQLite database, giving you full control over your data.

​
MQTT Bridge Tool

The tools/mqtt-bridge/ directory contains a Node.js service that bridges MQTT telemetry to Convex:
  1. Subscribes to MQTT topics (ados/+/status, ados/+/telemetry)
  2. Debounces updates (3 seconds per device)
  3. POSTs to the Convex HTTP API
It runs as a Docker Compose stack alongside Mosquitto and an optional Cloudflare tunnel.

​
Video Relay Tool

The tools/video-relay/ directory contains a video relay that converts RTSP streams to WebSocket fMP4:
  1. Accepts WebSocket connections from browser clients
  2. Spawns ffmpeg per device (copy codec, no transcoding)
  3. Streams fMP4 fragments over WebSocket
  4. Cleans up ffmpeg when the last viewer disconnects
This is an alternative to WebRTC for situations where peer-to-peer is not possible.

​
Offline Behavior

Cloud features degrade gracefully when the network is unavailable:
  • Local connections (USB, WebSocket) continue to work
  • Settings stored in IndexedDB remain available
  • Previously loaded fleet data stays visible but marked as potentially stale
  • The GCS retries cloud connections in the background
For field operations without internet, use direct USB or local WebSocket connections. Cloud features are a bonus for remote monitoring and fleet management, not a requirement for flying.