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.
Interactive & automated testing
Drive a box’s instruments by hand in Workbench, run structured pass/fail suites in Factory, and wire in GitHub so a pull request is checked on real hardware before it merges.
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 driving real hardware from your browser in about ten minutes.