Get the Local Agent onto machines

Provisioning offers three ways onto the control plane. All three end in the same place: an endpoint bound to a deployment profile, holding a credential of its own.

1. 1

   Pick the deployment profile

   At the top of Provisioning. The panel beneath it names the control plane in plain text (for a self-hosted estate that is your own address, not ours) and whether any relay sits between the device and it.

2. 2

   Enter the email addresses

   Separate them with commas, spaces or new lines. Each person gets their own single-use link; nobody shares a grant.

3. 3

   Read the boundary statement, then send

   The block titled WHAT IS ENABLED ON AN INVITED PERSON’S DEVICE is generated from the profile you selected, not written by marketing. If it says no location is pre-enabled, the person approves every source themselves. If it names locations, those are indexed without asking. Press Send invites.

4. 4

   Track the grant

   The invitation appears under All enrolment credentials with its prefix, its use count (0/1 uses), its expiry and its status. Status moves to EXHAUSTED once redeemed. You can Revoke an unused one at any time.

The link the person receives points at /install?token=…&installation=…&url=…. All three parameters matter: token is the one-time grant, installation identifies the workspace, and url is the control plane the agent must talk to. Tell people to open the whole link, not to copy the token out of it.

1. 1

   Mint a fleet token

   From Provisioning, or from a profile’s own invite screen. Set the quota, meaning the number of machines it may admit, and the expiry.

2. 2

   Stage it with your device management tool

   The token reaches each machine as an environment variable the installer consumes. Stage the control-plane address alongside it; the installer writes both to the agent’s enrolment file so the service can redeem the grant on first start.

3. 3

   On macOS, deploy the privacy profile too

   macOS gates access to Documents, Desktop and Downloads behind a consent prompt no unattended installer can answer. Deploy the PPPC configuration profile shipped in the agent packaging via MDM so those folders are readable without a person clicking Allow. Until that is answered, by profile or by the person, those folders are simply not indexed.

The installer is a bootstrap shell script. There is no desktop app, no .dmg, no .msi and no .AppImage, and the two scripts are not interchangeable.

macOS, Apple Silicon or Intel

Installs a LaunchAgent in your own login domain. It refuses to run as root, so do not use sudo.

curl -fsSL https://downloads.evodira.com/local-agent/install-macos.sh -o install-macos.sh
EVODIRA_ENROLLMENT_TOKEN='evo_enroll_…' \
EVODIRA_CONTROL_PLANE='https://app.evodira.com' \
  sh install-macos.sh

Linux, amd64 or arm64, systemd required

Without root it installs a systemd user service that runs as you and needs no password.

curl -fsSL https://downloads.evodira.com/local-agent/install.sh -o install.sh
EVODIRA_ENROLLMENT_TOKEN='evo_enroll_…' \
EVODIRA_CONTROL_PLANE='https://app.evodira.com' \
  sh install.sh

For a server or an appliance with nobody logged in, a user unit does not exist at boot. Ask for a machine-wide unit explicitly:

EVODIRA_SCOPE=system sudo -E sh install.sh

sudo -E and not bare sudo: plain sudo drops the two environment variables the command just set.

The page at /install reads the token from the link and asks the control plane, read-only, what redeeming that grant would meet. It consumes nothing. If the grant is dead it says so there, instead of handing out a command that fails on the machine ten minutes later.

Already used

The grant is exchanged exactly once and a device has already enrolled with it. Ask for a new invite.

Revoked

An administrator withdrew the grant before it was used.

Expired

Enrolment grants are time-boxed, so a link forgotten in an inbox cannot enrol a machine months later.

Not recognised

The control plane has no record of it. Usually the link was cut short when it was copied, so check it arrived whole, or it belongs to a different control plane.

A page that cannot reach the plane shows the instructions anyway. Unverifiable is not invalid, and the enrol step gives the definitive answer.

The command-line tool is evodira-local. Hardware detection, policy retrieval and model selection all happen inside the agent from here. There is nothing else to configure to get it running.

1. 1

   macOS asks before it reads anything personal

   The system prompts before the agent may read Documents, Desktop or Downloads. Until that is answered, those folders are not indexed, not partially and not silently. If the prompt was dismissed, grant it in System Settings → Privacy & Security → Files and Folders.

2. 2

   Check the agent enrolled

   The status command reports lifecycle state, policy revision and age, device identity and service scope.

   Copy

   evodira-local status

3. 3

   If the profile is user-assisted, admit the endpoint

   The device arrives PENDING. An administrator opens Review, switches to the Enrolments lane and presses Admit endpoint. Admitting mints the device’s credential and shows it exactly once. This is the one lane that never defers a decision, because a token shown twelve seconds later has nowhere to go.

4. 4

   Confirm it appears in the fleet

   Fleet lists it with its connectivity, lifecycle state and profile convergence. The person can see their own machine at Your device without any administrator permission at all.

• Uninstall the service on the machine with evodira-local service uninstall. Config and state are left in place by design, so a reinstall does not lose the device identity.
• Revoke the endpoint from Fleet. This needs fleet.revoke and is terminal. A revoked credential is not reinstated. The device stops syncing, and its record is kept so its owner can still see what it reported.
• Request a wipe to destroy local agent state on the machine. Also fleet.revoke, also terminal, and it stops the device indexing, syncing or re-enrolling.