Install Lander on an Endpoint

This guide installs the Lander endpoint agent on one machine and registers it with your control plane. It’s the right way to validate your setup before rolling out to a fleet with MDM. For the full command and config surface, see the Lander CLI and Lander Configuration references.

Note

macOS is the primary supported platform (launchd). Linux and Windows are deferred targets — the binary cross-compiles, but service installation is macOS-first.

Prerequisites

• A running control plane and its API URL (see Install the Control Plane).
• The Lander binary for the host’s architecture.
• A Connector account to authenticate with. Lander prompts for this itself in step 4 and opens the browser for you; on a headless host see --no-browser. The device is associated with whoever authenticates; there is no email to supply.
• The control plane must have its dashboard URL configured (A10E_DASHBOARD_URL), otherwise sign-in is disabled. See Control Plane Configuration.

1. Place the binary

Install the binary somewhere on PATH, for example:

sudo install -m 0755 ./lander /usr/local/bin/lander
lander --version

2. Point Lander at the control plane

Lander reads its control-plane URL from an environment variable (which takes precedence over config):

export LANDER_ENV_MANAGER_URL="https://control-plane.example.com/v1"

In a fleet rollout this is injected by MDM; here we set it in the shell (and it gets persisted into ~/.lander.json on first run).

LANDER_OWNER_EMAIL is deprecated

Ownership used to come from LANDER_OWNER_EMAIL (or --owner-email, or the OwnerEmail managed preference). It no longer determines who owns the device — that comes from whoever authenticates in step 4. The variable is still accepted for one release and logs a warning when set.

3. Install the background service

Install Lander as a launchd user agent. It runs at login, restarts on crash, and hosts the HTTP proxy used by HTTP-stream mirroring.

lander service install --port 8082

This renders ~/Library/LaunchAgents/com.aliengiraffe.lander.plist, registers it with launchd, and starts lander serve. On startup the daemon discovers installed agents, authenticates (next step), registers the device, and pushes its first inventory.

4. Authenticate when Lander prompts you

You do not run a sign-in command. Because the service runs in your GUI session and has no credential yet, Lander opens a browser by itself on the Connector’s login page.

Sign in with whichever provider your deployment uses, then approve the request on the consent screen — it names the host that is asking. Lander stores the credential at ~/.lander/credentials.json (mode 0600), refreshes it automatically ahead of expiry, and enrolls the device without further prompting.

Confirm it locally at any time:

lander auth status   # authenticated identity and token expiry, no network call

If you are setting this host up over SSH — or you dismissed the prompt and don’t want to wait for the next window — trigger the flow explicitly instead:

lander auth login                # open the browser now
lander auth login --no-browser   # print the URL instead, for a headless host

Either way the outcome is the same. If nobody authenticates, everything still installs and the local proxy still runs; the device simply stays unenrolled while Lander re-checks in the background.

5. Verify the device

Check local state (no network):

lander auth status     # authenticated as whom? token expiry?
lander device status   # device identity, registration state, last inventory
lander service status  # installed? running? PID?

lander device status should show a deviceId once registration succeeds. If no deviceId appears, check lander auth status first — an unauthenticated device installs cleanly but does not enroll. Nothing is stuck: the daemon re-checks every 15 minutes and enrolls itself once authentication completes, so you can wait rather than intervene. If the control plane was unreachable, registration also retries in the background; force a synchronous attempt with lander device register once connectivity is restored. The discovered agents and MCPs for the device are shown in the Connector dashboard (next step), not via a local command.

6. Confirm it in the dashboard

In the control-plane dashboard, open Fleet → Devices (/admin/fleet/devices). The new device appears with its serial, owner, status, version, and MCP count — the owner is the account you authenticated with in step 4. Open Fleet → Agents to see the agent types discovered on it.

What got created

Path	Purpose
~/.lander.json	Unified config: agents, MCPs, proxy state, logging, control-plane URL
~/.lander/certs/	Device key + self-signed certificate
~/.lander/credentials.json	The authenticated user’s Connector token (mode 0600)
~/.lander/device.json	Registration state (deviceId, fingerprint, timestamps)
~/.lander/logs/	Service logs and per-MCP audit logs
~/Library/LaunchAgents/com.aliengiraffe.lander.plist	launchd service definition

Uninstall

lander auth logout         # revoke the token and delete the local credential
lander service uninstall   # stop and deregister the launchd service

This removes the service and plist. Local state under ~/.lander/ is left in place; remove it manually if you want a clean slate. Run lander auth logout first if you want the token revoked control-plane-side rather than left to expire — deleting ~/.lander/ only removes the local copy.

Next steps

• Install an approved MCP from the Connector: Install an approved MCP.
• Roll out to the fleet: Intune · Jamf Pro · Kandji.