Deploy Lander with Jamf Pro

This guide rolls Lander out to a managed macOS fleet with Jamf Pro. As with any MDM, you ship a signed package, inject the control-plane settings, and run the service install. See Intune and Kandji for the equivalents.

Overview

flowchart LR
  Pkg["Signed .pkg"] --> Jamf["Jamf Pro\nPackages"]
  Profile["Config profile\n(env values)"] --> Jamf
  Script["Post-install script\nlander service install"] --> Policy
  Jamf --> Policy["Policy\nscoped to a smart group"]
  Policy --> Devices["Managed Macs"]
  Devices --> Fleet["Registers in fleet"]

1. Build and upload the package

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

1. Upload the .pkg to your distribution point under Settings → Computer Management → Packages (or via Jamf Admin).

2. Deliver control-plane settings

Lander needs LANDER_ENV_MANAGER_URL. With Jamf you have two clean options:

• Configuration profile — create a custom profile (Computers → Configuration Profiles → Application & Custom Settings) that writes a managed plist your install script reads, or that defines a LaunchAgent with EnvironmentVariables. Scope it to the same group as the policy.
• Script parameters — pass the value as a Jamf script parameter ($4) so you can vary it per scope without editing the script.

Devices appear as their users authenticate

Ownership is derived from an authenticated user, so there is no owner email to map — <$ASSIGNED_USER_EMAIL> and the OwnerEmail managed preference no longer determine who owns a device. Jamf 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.

3. Add the install script

Add a script (Settings → Computer Management → Scripts) that writes the LaunchAgent and installs the service, reading the env values from parameters:

#!/bin/bash
set -euo pipefail

LANDER_ENV_MANAGER_URL="${4:?Connector URL required}"
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

4. Create the policy

Create a policy (Computers → Policies) that:

1. Installs the Lander package.
2. Runs the install script, passing the Connector URL as a parameter.
3. Is scoped to a smart computer group (for example, “Macs in Engineering”) and triggered at enrollment and/or recurring check-in.

If you used a configuration profile for the env values, scope that profile to the same group.

5. Verify the rollout

• In Jamf, the policy logs show the package installed and the script exited 0.
• 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 and let the policy re-run; launchd KeepAlive restarts on the new binary.
• Remove — add a policy that runs lander service uninstall, scoped to the devices you’re decommissioning.

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