API key
A box-facing credential of the formstout_<64 hex chars>. Boxes use it in the X-API-Key header to authenticate heartbeats and job-dispatch WebSockets. Stout stores an HMAC-SHA256 hash of the key keyed by a server-side pepper, so a database leak alone can’t yield working keys. Older rows may still be stored as bare SHA-256 and are transparently upgraded on next use. If a key is lost, rotate it with the box’s Rotate API Key action (POST /api/orgs/:orgId/boxes/:boxId/rotate-api-key), or by re-running the install-stout flow — which also rotates the key.
Artifact
A file produced by a job (log output, images, firmware, test reports) and uploaded to object storage via a presigned URL. Each artifact carries a storage key, a checksum, and an upload state.Audit log
An append-only record of user actions: who did what, against which resource, at what time. Visible to admins under Settings → Audit Log with filters for actor, action, resource type, and date range.Box group
A named collection of Stout Boxes for easier fleet management and access control. A member or team can be granted access to a whole group at once instead of box-by-box.Device
A physical instrument (power supply, oscilloscope, debugger, etc.) connected to a box. Devices are populated from the box’s heartbeat payload and unique per(boxId, netName).
Factory suite
A reusable collection of hardware test scripts and fixtures with anentryPoint (typically main.py) and supporting files. Runs produce step-by-step pass/fail results with optional image and video capture.
Job
A one-off execution of alager CLI command on a box. The submitted command string is passed to lager as its arguments — e.g. command: "python my_test.py" runs as lager python my_test.py on the box, command: "supply psu1 voltage 3.3" runs as lager supply psu1 voltage 3.3. Jobs move through the states queued → waiting_for_box → dispatching → running → uploading_artifacts → completed | failed | cancelled | timed_out. Default timeout 3600 seconds.
Maintenance window
A scheduled period during which a box or device cannot accept new jobs. Useful for firmware updates, bench reorganizations, or holidays.Net
A named logical connection to a physical instrument on a Lager Box — e.g.supply1 mapping to channel 1 of a Rigol DP832 power supply, or uart0 mapping to /dev/ttyUSB0 at 115200 baud. Nets decouple test code from specific hardware addresses, so the same script works as instruments move or change.
Organization
The top-level tenancy boundary. All boxes, jobs, workflows, and members belong to exactly one organization. Cross-org access is not possible.PR Reviewer
A GitHub-integrated feature that automatically runs a configured set of hardware tests against every pull request in a selected repository. Supports allowed-box lists, approval gates, and rate limiting. (Coming soon in the dashboard — the underlying API is live today.)Reservation
A temporary hold on a box or device that prevents other users from submitting jobs to it. Intended for long-running tests or bench-time scheduling.Role
Owner, Admin, or Member. Determines what a user can do at the org level. Layered with per-box access controls.SSO
Single sign-on via OIDC or SAML. Users sign in with their corporate identity; Stout can map group claims to Stout roles. Secrets are encrypted at rest with AES-256.Stout Box
A Lager Box that is enrolled in a Stout organization. It runs two sibling Docker containers: the Lager container (Flask + SocketIO) for hardware control, plus astout container that handles control-plane communication — heartbeats, job dispatch, and audit reporting. A Lager Box becomes a Stout Box once the install-stout flow completes; if the stout container is removed, it reverts to a plain Lager Box.
Stout Boxes send heartbeats every 30 seconds and are marked offline after 3 minutes of silence.
Team
A named subgroup within an organization, used to manage box access for many members at once.Trigger
The mechanism that starts a workflow run. Types: manual, schedule (cron), push, pull_request, box_online.Webhook
Stout uses webhooks in two distinct ways. Inbound webhooks are how GitHub and GitLab notify Stout of repository events (pushes, PR updates) to fire workflow triggers; Stout verifies each request against the provider’s native signature header (x-hub-signature-256 for GitHub, x-gitlab-token for GitLab). Alert webhooks are outbound: when an alert fires, Stout POSTs JSON to the URL you configured for your org.
Workflow
A multi-step automation with a dependency graph (dependsOn between steps), one or more triggers, and an optional GitHub repo target for YAML export.