DJI Dock 3 turns a drone from something a pilot carries to a site into permanent infrastructure that lives on it. The aircraft sits inside a weatherproof enclosure, charges between flights, and takes off, flies and lands without anyone in the field. What people usually underestimate is everything around the box: the site work, the connectivity, and the software layer that decides what the dock does and when.
What the dock actually is
At its core Dock 3 is four things in one enclosure:
- A hangar. A sealed shell that protects the aircraft from rain, dust, wind and temperature swings, with climate control so the batteries stay in a usable range.
- A charger. Fast charging between missions, which is what makes a repeated daily or hourly cadence possible instead of a single sortie.
- A ground station. Its own RTK reference, weather sensing and a radio link to the aircraft during flight.
- A network node. Ethernet or 4G/5G back to a cloud service that issues tasks and receives results.
Dock 3 also supports vehicle-mounted deployment, so the same enclosure can be moved between sites rather than being poured into one concrete pad forever.
What it needs on site
Before the first flight, three things have to be true:
- Power and network. Mains power and a stable connection. If the link drops mid-mission the aircraft keeps flying its route and returns home, but you lose the live picture and the ability to intervene.
- A clear takeoff and landing corridor. No canopy, cables or structures in the vertical column above the dock, plus a return-to-home altitude that clears everything in the operating area.
- Regulatory cover. In Europe that usually means an operational authorisation for BVLOS flight, a defined operational volume and ground risk buffer, and procedures for what happens when a flight is interrupted.
None of that is software. But all of it constrains the software: the route altitudes, the geofence, the abort behaviour and the preflight checks have to match the authorisation you actually hold.
What it needs in the cloud
The dock is deliberately not the brain of the operation. It executes what a cloud service tells it to. That service is responsible for:
- Route design — the geometry of the flight: waypoints, corridors, area coverage, camera actions, altitude mode.
- Task issuing — when a route runs: right now, on a schedule, or when the dock reports itself ready.
- Preflight validation — battery state, aircraft health, storage, wind and rain readings, and whether the airspace and route are still valid.
- Live supervision — telemetry and video while the aircraft is airborne, and the ability to pause, return home or land.
- Data handling — where media goes after landing, who can see it, and how long it is kept.
DJI's own FlightHub 2 covers this ground. So do third-party clouds that speak the same Cloud API — including Timoneiro, which keeps the data in European datacentres and can be branded as your own product.
A realistic first deployment
A sensible sequence for a first dock is: install and commission the hardware, fly a manual verification flight, build one conservative route with generous altitude margins, schedule it once a day, watch it for a week, then start tightening. Autonomy is not a switch you flip — it is trust you accumulate as the same route completes without intervention.
Where to go next
If you are choosing the cloud layer rather than the hardware, the questions that matter are which mission types you can build, how tasks are scheduled and validated, where the data lives, and whether you can put your own brand on it when you resell the service. We wrote about those trade-offs in what to look for in a third-party Dock 3 cloud.