Add mobility without changing where the work lives.
Self-hosted agent operations
Drover treats Herdr and your machine as the system of record. Its job is to transport a small, authenticated control surface—not to become another place that stores your repository.
Clear ownership boundaries
- Herdr owns
- Private session, workspace, and terminal topology plus live orchestration authority.
- Drover Host owns
- Protocol validation, paired-device transport, and exact live-route bridge into Herdr’s Host → Session → Workspace → Tab → Pane model.
- Your host owns
- Repositories, credentials, tools, processes, and the authoritative runtime state.
- Drover for iPhone owns
- Native presentation, paired-device identity, user intent sent over a live authenticated path, and the host-count gate itself — it is the one party that knows how many hosts it has paired, and no server counts hosts.
- Cloud services own
- Minimum signaling, optional encrypted relay, generic push routing, and Drover Pro entitlement verification for push notifications and the Live Activity — the route itself is never priced.
What Drover avoids
- No Drover login in v1.
- No cloud-hosted repository or agent runtime.
- No root daemon.
- No Herdr version pin or protocol guessing; compatibility uses a capability floor.
- No command queue that wakes up after a network gap.
- No nickname that hides the verified machine identity.
Operational tradeoff
Self-hosted authority means your host must be available, Drover Host must be running, and Herdr must be compatible. A direct path is preferred, but restrictive networks can require an end-to-end encrypted TURN relay. Cloudflare can observe connection metadata on that fallback; it cannot decrypt the Drover payload.
Review installation requirements and security boundaries.
Keep the host. Add the control surface.
Drover for iPhone is in beta — join to get a TestFlight invite. Drover for Mac and Linux are available now.