What's managed for you
- The cloud relay. Provisioned, monitored, and patched by Nebli, in a single US region. There's nothing for you to run on the cloud side: no AWS account, no IAM, no certificates, no servers.
- Your account and deployments. Sign up at dash.nebli.ai and your org, first tenant, team, and deployment are created for you. Creating a deployment mints its credentials automatically, so there's nothing to copy by hand.
- The relay software. The Hover CLI and the Hover Relay desktop app are published for Linux, macOS, and Windows. Install the CLI with a one-line command or download the app; once you're signed in, both pull a deployment's connection details for you.
- Public viewer URLs. A PIN-protected browser URL scoped to a deployment that an incident commander can share without anyone installing anything.
- White-glove help, when you want it. Design-partner and enterprise customers can have Nebli walk the first install with them. It isn't required; the self-serve path works on its own.
What your team brings
Flying DJI? None of this applies. See DJI drones for the sign-in or paste-a-stream-key path instead.
- Field hardware. A laptop on the drone's local network: a rugged Toughbook, or any machine running Linux, macOS, or Windows. We can recommend a configuration; we don't sell or ship hardware.
- Internet uplink. A cellular hotspot, Starlink terminal, or bonded router, whatever your operation already uses. The relay works across CGNAT and consumer-grade NAT with no inbound ports to open. See the FAQ.
- Command-post machine. A laptop, Windows or macOS, where the operator runs their existing GCS (CCA3, Mission Planner, QGroundControl).
- Drone configuration. Anything that exposes RTSP video and MAVLink on its local network. We don't touch the drone's firmware.
The network it needs
The field proxy makes only outbound connections to the relay: UDP and TCP to relay.hoverfeed.com for video and control, and HTTPS to api.nebli.ai for sign-in and deployment lookup. Nothing inbound is required, so CGNAT, double-NAT, hotel WiFi, and hotspots all work without coordinating firewall rules or port forwards with a carrier. The command-post machine needs ordinary outbound internet. A DJI drone's RTMP push is also outbound-only, over whatever network the controller or phone already uses.
The rough timeline
This is the timeline for a relay-connected drone (PX4, ArduPilot, Parrot, Skydio, Autel, custom builds). A DJI drone skips straight from signup to a live feed: sign in on the controller or paste a stream key, no install step, no pairing step. See DJI drones.
| Step | Time | What happens |
|---|---|---|
| Sign up | ~2 minutes | Sign in at the dashboard with Google or an email code. Your org, first tenant, team, and a default deployment are created for you. |
| Create a deployment | ~1 minute | Add a deployment in the dashboard (or use the default). It mints credentials automatically and shows paste-ready install commands for the field and command-post machines. |
| Install the relay | ~30 minutes | On the field machine and the command-post machine: install the Hover CLI with a one-line command, or download the Hover Relay desktop app. Sign in once on each. |
| Pair & first feed | ~5 minutes | Start the proxy (field) and the client (command post). The GCS connects to 127.0.0.1 and video plays. |
| First flight test | 1 sortie | Verify on a real flight. Watch link health in the Hover Relay app or with hover logs. Confirm recording is hitting the SD card. |
From signup to a live feed in a command post is a working session; the install takes the longest, and most of that is your own IT setup. Enterprise and design-partner customers can add a short discovery call and have Nebli walk the first install; for everyone else, the path above is self-serve end to end.
What this looks like for the operator. On the relay path, they point their existing GCS at the relay client on 127.0.0.1: video at rtsp://127.0.0.1:5554, and MAVLink on the local port the client exposes, exactly as if the drone were on the desk. The relay is invisible when it's working; the Hover Relay app's console (or hover logs) is what they check when it isn't. On the DJI path there's no GCS and no relay console to check; the operator watches the feed directly in the Nebli dashboard. Exact ports and flags live in the CLI and desktop-app setup guides.
Adding more drones, more sites, more agencies
Each deployment runs in its own session, with its own credentials and its own public-viewer URL. To add one: create it in the dashboard, install the relay, and pair. There's no new contract to sign.
The dashboard manages all of your deployments in one place: a fleet list with live status, plus flights, recordings, members, and billing. How many you can run is bounded only by your tier's caps (deployments, tenants, teams, seats), and it all stays in the same tool. Tenants and teams let a larger org keep divisions, regions, or partner agencies cleanly separated; see Concepts for the hierarchy.
What happens when something breaks
The cloud relay is monitored by Nebli; if it goes down, we know before you call. For the field side, the first place to look is built in: the Hover Relay app shows live connection health and a console, hover logs <deployment> streams the same events from the CLI, and the dashboard shows each deployment's live status. No SSH required.
Remote support during live deployments (graduations, demonstrations, anything where uptime is non-negotiable) is available on request. See the pricing page for terms.
What about credentials, encryption, and what we log?
Security →