Build with the Oplut CLI

A user signs up, SSHes into their Raspberry Pi or opens a terminal on the board, installs Oplut, authenticates with a browser device code, runs setup, captures a baseline, and checks whether the physical unit still matches the version that worked.

sudo apt install -y pipx
pipx ensurepath
pipx install oplut
oplut auth
oplut setup --goal network-stream --execute
oplut baseline --upload
oplut check --upload

Oplut is installed where setup and local checks need to run: on the Raspberry Pi, Jetson, laptop, or robot computer. The first supported path is Raspberry Pi hardware, while SDK metrics let teams integrate custom stacks.

sudo apt install -y pipx
pipx ensurepath
pipx install oplut
oplut --help

Raspberry Pi OS blocks global pip installs because system Python is externally managed. pipx keeps Oplut isolated and still exposes the oplut command.

The CLI creates a short-lived device code, opens the browser approval page, polls until the account approves it, and stores local credentials. Manual API-key auth can remain as a fallback, but the default path is safer for SSH and headless boards.

oplut auth
# open the approval URL
# enter the code shown in your terminal

oplut setup detects the board and OS, asks what surface and goal the user wants, calls POST /v1/setup, and executes each returned step with terminal output.

oplut setup --goal network-stream --execute
Board detected: raspberry-pi-4 (bookworm-64bit)
Peripheral: pi-camera-module-2
Goal: network-stream

Field robots and lab rigs are not always online. Oplut should still detect hardware, capture baselines, run checks, write evidence, and explain drift locally. The dashboard and cloud are review surfaces for synced summaries, not a dependency for knowing whether the unit changed.

oplut baseline
oplut check
oplut diff

# later, when connectivity is useful:
oplut sync

Setup gets a surface working. Baseline and check make that working state useful later. Oplut stores compact evidence locally first, then optionally syncs summaries to the dashboard for review across devices.

oplut baseline --upload
oplut check --upload
oplut diff
oplut describe

Oplut should not expand from a weak first proof. The foundation is one real hardware stack where setup works, an accepted baseline is captured, a physical change is introduced, the check detects it, and the diagnosis tells the builder what to do next.

oplut setup --goal network-stream --execute
oplut baseline

# introduce a real change:
# stop service, change config, unplug bridge, or alter timing

oplut check
oplut diff

Enterprise teams should not need Oplut-specific hardware. The Python SDK lets custom hardware stacks report device identity, components, compact metrics, events, baselines, checks, and local-only evidence boundaries.

The CLI runs on the board itself, so it can read OS, architecture, service, USB, serial, and network facts directly. Those facts become setup context and later evidence context.

A setup profile contains board, peripheral, OS, goal, tier, steps, verification checks, expected result, and tested-on metadata. The profile is useful because it creates a surface Oplut can baseline and check later.

{
  "id": "rpi4-picamera2-network-stream",
  "board": "raspberry-pi-4",
  "peripheral": "pi-camera-module-2",
  "os_version": "bookworm-64bit",
  "goal": "network-stream",
  "tier": "free",
  "steps": [
    {
      "title": "Install camera packages",
      "type": "command",
      "command": "<server-returned command>",
      "expected_output": "<server-returned check>"
    }
  ],
  "verification": {
    "command": "<server-returned verification>",
    "expected_output": "<server-returned result>",
    "success_message": "Hardware output verified."
  }
}

Setup profiles tell the runtime how to run the baseline loop for a supported surface. They are not the product and should not be treated like a public marketplace of proprietary hardware combinations.

1. Flash a clean OS image.
2. Research the actual working path across official docs, forums, and source repos.
3. Execute on real hardware.
4. Convert the working sequence into an Oplut setup profile.
5. Flash clean again and run only the profile steps.
6. Add error handling for likely failures.
7. Mark verified with board, OS, date, and tester.

A release is not complete just because the site deploys. The package, production API, auth, setup profiles, installed services, baselines, checks, dashboard review, and SDK examples should pass together.

sudo apt install -y pipx
pipx ensurepath
pipx install oplut
oplut auth
oplut setup --goal network-stream --execute
oplut baseline --upload
oplut check --upload

1. Install from PyPI or pipx on a fresh Raspberry Pi OS image.
2. Run oplut auth without OPLUT_API_BASE_URL.
3. Run oplut setup from plain choices, not only exact slugs.
4. Capture a local baseline after setup.
5. Run oplut check after changing or stopping a managed surface.
6. Confirm the dashboard shows setup, baseline, check, and health evidence.

The CLI proves the local loop. The SDK lets teams integrate custom hardware. The dashboard turns synced evidence into device review, team history, and later population intelligence across many specific physical units.