Devices & Fleet

A device is a single managed endpoint running the Lander agent. The fleet is every device that has checked in. This page covers how a device comes to exist in the control plane and what you can see about it.

How a device is born

When Lander first runs serve on a host, it:

1. Probes the machine’s hardware identity — on macOS, the serial number via ioreg and model via sysctl hw.model. If hardware probing fails, it persists a random UUID and uses the hostname as the model.
2. Ensures a device key pair and certificate exist under ~/.lander/certs/.
3. Authenticates the user. Enrollment is authenticated, and Lander drives this itself: running in the user’s GUI session, it opens a browser to the Connector’s sign-in page and waits for them to authenticate and approve. Until somebody does, there is nothing to attribute the device to, so it stays unenrolled and keeps serving the local proxy.
4. Registers with the control plane at POST /v1/devices/register, sending the serial, brand, model, and certificate, signed with the device key and carrying the authenticated user’s bearer token.
5. Receives a server-assigned deviceId and persists registration state to ~/.lander/device.json.

Registration requires both proofs, and neither substitutes for the other: the certificate signature proves which device is calling, and the bearer token proves which human it belongs to. The control plane takes ownership from the token’s subject, so a device cannot enroll as somebody else by asserting their email address.

Registration is idempotent — if the device is already registered with the same certificate and owner, Lander skips the network call. See the Lander install guide for what the user sees, and Authentication for how the prompt behaves unattended on an MDM-managed fleet.

What the control plane tracks

Each device record includes:

Field	Description
deviceId	Server-assigned UUID
serialNumber	Hardware serial (or a persisted fallback UUID)
brand / model	e.g. Apple / Mac16,8
ownerEmail	Person the device is associated with — resolved from the authenticated user at registration, not self-asserted by the endpoint
certificateFingerprint	SHA-256 of the device certificate
status	online, offline, or error
version	Lander version reported on check-in
agentTypes	AI agents discovered on the device
MCP counts	How many MCP servers are configured / enabled
lastReportedAt	Last successful check-in

Administrators browse devices through GET /admin/devices, drill into one with GET /admin/devices/:id, and review change history and the last inventory snapshot via GET /admin/devices/:id/history and GET /admin/devices/:id/inventory.

Fleet views

The control plane aggregates devices into fleet-wide views:

• Fleet metrics (GET /admin/fleet/metrics) — totals and health across the fleet: device counts by status, agent counts, MCP adoption.
• Fleet graph (GET /admin/fleet/graph) — a network graph of agents, devices, and MCP servers and the connections between them, rendered on the dashboard so you can see which agents reach which MCPs across the fleet.

flowchart LR
  subgraph Fleet
    D1["Device A"]
    D2["Device B"]
    D3["Device C"]
  end
  D1 --> AG1["Claude Code"]
  D2 --> AG1
  D2 --> AG2["Gemini CLI"]
  D3 --> AG2
  AG1 --> MCP1["github MCP"]
  AG1 --> MCP2["filesystem MCP"]
  AG2 --> MCP1

The graph makes it obvious, for example, that a sensitive MCP server is reachable from more agents and devices than you expected — a starting point for tightening mirroring and policy.

Keeping inventory fresh

After registration, Lander pushes an inventory snapshot and then keeps it current by watching the agents’ config files (via fsnotify, debounced) with a periodic poll as a backstop. Any change — a new MCP added to Claude Code, an agent removed — triggers a fresh inventory push so the fleet view reflects reality within seconds. The mechanics are covered in AI agents.

Next: the agent types Alien Giraffe discovers — AI agents.