The TofuPilot CLI is the new way to run a test station. It is the runtime behind Stations v2.0, and it replaces the v1.0 station: the desktop app that ran on the bench, pulled deployments, and executed procedures locally. The CLI does the same job with one-command install, automatic deploys from Git, and the same live operator UI. This guide shows how to move a bench over.
On a self-hosted instance? Set up the deployer first so your instance can build station bundles, and enable the realtime server so runs stream live. Follow Enable Realtime and Deploys on Self-Hosted, then come back here. Cloud TofuPilot has both on already, so you can start right away.
Why move to the CLI
Station v1.0 was a desktop application installed on each bench. Stations v2.0 run on the TofuPilot CLI, which keeps everything the desktop app did and adds what it could not:
- One-command install. No installer to download per machine. The CLI installs in one shell command from the station setup page and registers itself on first boot.
- Deploy from Git automatically. Connect the procedure to its GitHub repo and pick a branch (typically
main) for auto-deploy. Pushes to that branch roll out to the right stations on their own. Other branches stay manual: deploy them from the dashboard when you are ready. - Remote and kiosk operator UI. Drive a run from the dashboard over the web, or from a full-screen local kiosk UI on the bench. A terminal UI is there too when an engineer drives a benchtop test.
- No Git provider login on the bench. The desktop app synced procedure code straight from GitHub or GitLab, so each bench needed Git provider access. Linking the repo now happens once in the dashboard, and the bench pulls a pre-built artifact instead, so it never touches your repository and you control deploys entirely from the web.
- Offline-friendly upload queue. Runs queue locally on the bench and upload as soon as the network is back, so a flaky link never costs you data.
- Runs headless anywhere. The desktop app needed a desktop environment. The CLI runs headless on a server, a rack box, or a small single-board computer, and works against self-hosted deployments out of the box.
Migration steps
1. Make sure the procedure has a deployment
The CLI runs from a built artifact, so the procedure needs a fresh deployment for the new station to pull. On the procedure page in the dashboard:
- If the procedure is already linked to its Git repository (most v1.0 procedures are), trigger a new deployment: push to the auto-deploy branch, or deploy manually from the dashboard.
- If it is not linked yet, link the GitHub or GitLab repository first, then deploy.
That build is what the new station pulls and runs.
2. Install the CLI on the bench
Open the station's detail page in the dashboard and copy its install command. It is pre-filled with the station's setup token, and on self-hosted it also carries the --url flag pointing at your instance, so copy it from the dashboard rather than typing it by hand. It looks like this:
curl -fsSL tofupilot.sh/install | sh -s -- --token <SETUP_TOKEN>Run it on the bench once. The CLI installs, registers itself with your organization, and the station shows up online in the dashboard. The setup token expires one hour after issue, so if it lapses, generate a new one from the station's row.
3. Tune the station config
From the station settings, pick the behaviors that match your floor:
- Launch on boot so the station is ready as soon as it powers up.
- Kiosk UI for full-screen operator mode, or Terminal UI for an engineer benchtop.
- Desktop shortcut for one-click launch.
- Auto-update to keep the CLI current between runs.
4. Retire the desktop app
Once the bench is running runs through the CLI and they land in the dashboard live, uninstall the v1.0 desktop app from the machine. Station v1.0 is being phased out, and we are reaching out to every team still on it with hands-on migration support.
You are done. The next operator-triggered run lands in the dashboard live, with validators and attachments handled by the CLI.