Team

Enroll machines

A developer signs their machine in to the team once. From then on, every sandbox on that machine starts from the team's signed policy, and the machine reports what it runs.

Sign in

open      https://fenzi.dev/device
code      KQXT-MRWD
waiting   approve it in the browser
signed in li@acme.dev, team acme
machine   li-x1, enrolled
policy    acme r14, verified and cached

1. Open the page and enter the code. The CLI waits. Nothing is typed into the terminal but the command.

2. Approve in the browser, signed in to the console as yourself. The page names the machine that is asking. Approve only a code you started; a code someone sent you would sign their machine in as you.

3. The CLI receives the team's current policy, checks its signature, and caches it.

The address is your team's console, https://fenzi.dev unless you pass fenzi login --server <url>. The machine is named after its host name. Sign-in through your identity provider is planned for the License plan, which is not built yet.

Rolling out to many machines

Today, each machine installs the command and signs in once. There is no unattended sign-in yet.

1. Install without the guided setup. This installs the command and stops. It asks nothing, so it can run from a script.

   $curl -fsSL https://fenzi.dev/install.sh | FENZI_NO_SETUP=1 shCopy

2. Sign each machine in once with fenzi login. It prints a code, and the developer, signed in to the console, approves it in the browser. Each developer stores their own model key with fenzi key set.

3. Keep forwarding running. Forwarding runs during fenzi run and fenzi connect, while the Mac app is open, or as fenzi forward started as a login item or user service. There is no packaged launchd or systemd unit and no MDM package yet. Run it as a service has a LaunchAgent and a systemd user unit to copy.

What the machine keeps

One file, ~/.config/fenzi/enrollment.json, readable only by you:

• The machine's token. It never leaves the machine except to authenticate to the control plane, which keeps only a hash of it.
• The team's public signing key, received at sign-in. Every later policy is checked against it. Each team has its own key.
• The latest signed policy and its revision number.

No model keys, no source, no logs.

What changes after sign-in

If the team has not published a policy yet, run refuses to start a sandbox rather than fall back to the Free default.

Check the machine

account   li@acme.dev, developer, team acme
machine   li-x1
server    https://fenzi.dev
console   https://fenzi.dev/console
policy    r14, verified

If the control plane cannot be reached, status says so, checks the cached policy's signature again, and keeps using it. If an admin signed the machine out in the console, it says that instead, and still keeps the cached policy.

What the machine reports

On every fenzi sync and forward pass, the machine reports the runtime version, the policy revision it holds, and the sandboxes it started; the full list is in What our cloud receives. The console lists every machine and when it last reported. The machine always makes the call. The control plane never connects to it.

Sign out

Forgets the sign-in and the cached policy. The machine goes back to the Free plan for the next run, and those runs send nothing to the console. A sandbox that is already running keeps the policy it started with. Signing out happens on the machine only: the console sees the machine stop reporting, and after a day its Drift page warns that the machine stopped reporting.