When you need Stout
You already have Lager running if you canlager python test.py against a box from your laptop. You need Stout once you have:
- More than a handful of boxes, distributed across benches, rooms, or sites, and no good way to see which are online.
- Multiple teams or engineers sharing the same hardware, where “who’s using the scope right now?” is a real question.
- Compliance requirements that demand an audit trail of who ran what test, against which firmware, at what time.
- CI/CD ambitions — you want a pull request to automatically run on real hardware before it merges.
- Customers or auditors who want to see a dashboard of fleet health, not a Slack channel of box IPs.
What Stout adds
Fleet visibility
Every registered Lager box reports heartbeats, capabilities, and connected devices. See your whole fleet at a glance.
Access control
Organizations, teams, three-tier roles, per-box assignments, SSO via OIDC or SAML.
Jobs and workflows
Submit Python scripts from a web UI; chain them into multi-step workflows; trigger them from GitHub events, cron, or manually.
Audit and governance
Every user action is logged with actor, resource, and timestamp. Maintenance windows and resource locks prevent collisions.
What Stout is not
Stout never forks Lager, moves core Lager capabilities behind a paywall, or ships patched Lager versions. Anything that belongs in the runtime — a new instrument driver, a new net type, a new CLI command — belongs in Lager. Stout’s job is organizational, not technical. If you want to keep using Lager on its own, you always can. Stout is an addition, not a replacement.Next steps
Quickstart
Go from an empty account to a first job running on hardware in about ten minutes.