Skip to main content
The agent’s configuration lives in one YAML file, /etc/ados/config.yaml. Its shape is defined by schemas/agent-config.schema.json in the agent repository, and every key has a default, so a short file (or none) gives a working agent. The browser dashboard and Mission Control cover the settings most operators change. Edit the file, or use the REST API, for everything else. Extensions keep their settings in their own plugin config, not in this file; see Plugins.

How the file is loaded

Services read /etc/ados/config.yaml through the ADOS_CONFIG path their systemd unit sets, which points there. Keys missing from the file fall back to the packaged defaults, merged under the file. Keys the running schema does not recognise are kept on write rather than dropped, so a config from a newer or older build survives a round trip. ados config status shows pending migrations, and ados config migrate brings the file to the current shape. See Agent CLI reference.

What the installer writes

The installer writes the node’s identity, profile and the flight-controller port it detected at install (empty if none was attached), with the default baud. Your edits take priority over the defaults.

Read and write the config

From the REST API

The response carries persisted. A write that changed the running model but could not reach /etc/ados/config.yaml answers "persisted": false with a persist_error naming the reason:
Reading a secret path returns ***. Writing that placeholder back is rejected with a 400, so a read-edit-write round trip cannot overwrite a real secret. PUT /api/config of a profile, role, radio or regulatory key is refused while the vehicle is armed. GET /api/config/schema returns the embedded schema; build a settings UI against it. See REST API.

Edit the file

Edit /etc/ados/config.yaml with any text editor, then restart the affected service, for example:
The unit for each subsystem is on Systemd services. The terminal dashboard is read-only and does not edit config.

Settings that need care

Leave raw_proxy_enforce_auth at true and raw_proxy_lan_access at false. Setting raw_proxy_enforce_auth: false lets any host on the LAN write to the flight controller of an unpaired drone, and raw_proxy_lan_access: true serves every off-box peer on the raw ports whatever raw_proxy_enforce_auth says, because the raw ports carry no credential. With serial_port empty the agent ignores baud_rate and sweeps common rates for a heartbeat, so a default-config drone often runs at 115200 even though the file says 57600. To pin a rate, set both keys. Check what the link settled on with ados status. See MAVLink proxy.

Profile

agent.profile: "auto" lets the agent detect the profile at boot. workstation and compute are never auto-detected; they are chosen at install time with --profile. ados profile set persists only drone and ground_station. Detection rules are on Node profiles.

Hotspot passphrase

Empty is the default and means “generate a per-unit passphrase on first use”. The generated value is written mode 0600 to /etc/ados/ap-passphrase and shown on the OLED access-point page, in the terminal dashboard and on the installer’s completion card. Read it with ados network ap-passphrase.
A configured value takes precedence over the generated one, so naming a passphrase here gives every unit in your fleet the same key. Set it only to pin a deliberate shared passphrase.

Cloud server mode

  • local (default): no cloud connectivity; Mission Control reaches the node over the LAN.
  • cloud: connects to the hosted backend shown under cloud:.
  • self_hosted: connects to your own broker and Convex deployment.
The heartbeat runs every 5 seconds and is fixed; there is no setting for it or for the telemetry publish rate.
For self_hosted, url must point at the Convex site origin on :3211 (HTTP actions: pairing register, heartbeat, command poll), not the client API on :3210. A :3210 URL sends the register call to the wrong origin and returns 404. See Self-hosting: Agent.

Pairing backend URL

pairing.convex_url is the origin the pairing beacon and heartbeat call. A self-hosted deployment must set it to its own site origin: setting server.mode: self_hosted and filling server.self_hosted is not enough on its own. See Self-hosting: Agent.

MQTT broker TLS

The telemetry gateway always connects to the broker over TLS, verified against the system trust store, and authenticates as the device id unless server.mqtt_username names another user. server.mqtt_plaintext_dev: true turns TLS off for a development broker; the password then crosses the network in clear text.

LAN transport

The HTTP API on port 8080 is plain HTTP on the LAN, with the pairing key at the auth edge. There is no device TLS or WireGuard setting: keep the node on a network you trust, or reach it through the cloud relay or a tunnel. See Hardening.

Video mode and codec

The schema default is wfb; the installer writes auto. Only disabled (video exits) and wfb (thumbnail at boot) change behaviour. Use h264 for browser playback: WebRTC and MSE players expect H.264 High Profile. See Video pipeline. The video.wfb keys (channel, TX power and its ceiling, FEC, fleet slot, regulatory domain, link presets, adaptive bitrate and auto-hop) are documented on WFB-ng. The full list is in the video table below.

Vision backend

auto selects rknn on a Rockchip SoC, otherwise the ONNX CPU backend when the build includes it, otherwise mock (no detections). Set hailo explicitly for a Raspberry Pi 5 AI HAT.

Swarm

The swarm: block (enabled, wifi_direct, role, default_formation, default_spacing, mode, flock, separation, tasks) is documented on Swarm bus.

All keys by section

Each table is generated from the config schema. Secret keys show “Secret, not shown”.

Next steps

Terminal dashboard

Watch the node’s links, autopilot and video live.

MAVLink proxy

How the agent connects to the flight controller.

WFB-ng

Radio link settings and automation.

Agent CLI reference

ados config and the other commands.
Last modified on October 11, 2026