Deploy Lander with Kandji

This guide rolls Lander out to a managed macOS fleet with Kandji. The pattern matches the other MDMs: ship a signed package as a Custom App, inject the control-plane settings, and run the service install. See Intune and Jamf Pro for the equivalents.

Overview

flowchart LR
  Pkg["Signed .pkg"] --> Custom["Kandji\nCustom App"]
  Script["Audit & Enforce script\nlander service install"] --> Custom
  Custom --> Blueprint["Blueprint"]
  Blueprint --> Devices["Managed Macs"]
  Devices --> Fleet["Registers in fleet"]

1. Build the package

Build a signed, notarized .pkg that installs Lander to /usr/local/bin/lander (see the Intune guide for the pkgbuild/productsign steps).

2. Create a Custom App

In Kandji, add Library → Custom Apps:

1. Upload the .pkg as the installer.
2. Choose an install enforcement — “Install once” is typical for the binary.
3. Optionally add a preinstall/postinstall script, or pair the app with a separate Custom Script library item (next step) to run the service install.

3. Add an Audit & Enforce script

Kandji Custom Scripts support an audit script (checks state, exits non-zero when remediation is needed) and an enforce/remediation script (fixes it). Use this to ensure the Lander service is installed and running with the right settings.

Audit script — exits non-zero if the service isn’t installed:

#!/bin/bash
/usr/local/bin/lander service status | grep -q "running" || exit 1

Remediation script — injects settings and installs the service for the console user:

#!/bin/bash
set -euo pipefail

LANDER_ENV_MANAGER_URL="https://control-plane.example.com/v1"
CONSOLE_USER=$(stat -f%Su /dev/console)
UID_NUM=$(id -u "$CONSOLE_USER")

launchctl asuser "$UID_NUM" sudo -u "$CONSOLE_USER" \
  env LANDER_ENV_MANAGER_URL="$LANDER_ENV_MANAGER_URL" \
  /usr/local/bin/lander service install --port 8082

Because Kandji re-runs Audit & Enforce on a schedule, this also self-heals — if the service is ever removed, Kandji reinstalls it on the next check.

Devices appear as their users authenticate

There is no owner email to map — ownership is derived from an authenticated user, so resolving Kandji’s assigned user to an address no longer determines who owns the device. Kandji installs and starts Lander, and Lander does the rest itself: it opens the browser in the user’s GUI session and enrolls once they authenticate. Expect a freshly imaged fleet to show zero devices until users work through that prompt. See Authentication.

Note

The audit script checks only that the service is installed, so it stays green on a device nobody has authenticated on yet. Audit & Enforce cannot drive enrollment — Lander prompts the user, and only they can complete it.

4. Assign to Blueprints

Add the Custom App and the Custom Script to the Blueprints that cover your target Macs. Devices in those Blueprints install Lander and run the service install automatically.

5. Verify the rollout

• In Kandji, the Custom App shows installed and the Audit & Enforce status is green (passing).
• On a sample Mac: lander service status is running and lander device status shows a deviceId. No deviceId usually means nobody has authenticated yet — check lander auth status.
• In the dashboard, devices appear under Fleet → Devices (/admin/fleet/devices) as their users authenticate, each owned by the account that did.

Updating and removing

• Update — upload a new package version to the Custom App; Kandji deploys it and KeepAlive restarts the service.
• Remove — switch the script’s remediation to run lander service uninstall, or remove the library items from the Blueprint and push an uninstall script.

Next: see the data flowing in Monitor Agents & MCPs.