Document metadata
- Status
- Maintained
- Approval
- Approved
- Version
- 1.0
- Classification
- PUBLIC
- Owner
- Lightning IT Documentation Maintainers
- Approver
- Lightning IT Product Owners
- Audience
- technical evaluators, platform engineers, security engineers
- Last reviewed
- Next review
- (Annual)
Get started
This site contains public technical documentation for four peer Lightning IT products. Product and company marketing remains on l-it.io, and the customer portal serves a different, non-public purpose. This site contains no customer-specific procedures, credentials, environment topology, or internal operating records.
Choose a product
| Goal | Product | Start here |
|---|---|---|
| Build reusable automation content | ModuLix — Automation Content | ModuLix overview |
| Run automation through a controlled runtime boundary | IO — Automation Runtime | IO overview |
| Host approved workloads on an infrastructure platform | Wunderbox — Infrastructure Platform | Wunderbox overview |
| Observe services and platforms through governed signals | Atlas — Observability Platform | Atlas overview |
Build, Run, Host, and Observe describe possible functional interaction. The products remain peers, and a solution does not have to use all four.
Choose an audience path
These paths group the first decisions for different responsibilities without changing the peer-product hierarchy.
- Automation authors
- Platform operators
- Architecture and assurance
Start with the ModuLix concepts, then use its development and testing guidance. Changes to public guidance follow the documentation contribution workflow.
Select the applicable product operations and troubleshooting pages. Before state is at risk, establish the cross-product backup and recovery model. Concrete procedures still come from the selected release contract.
Review the peer-product architecture, integration decisions, and publication boundary. Use the compliance approach and BSI mapping method without treating them as certification evidence.
Read claims carefully
Conceptual pages describe responsibilities and design constraints. They do not claim that a product release implements a specific feature. Code-level pages in public component repositories own exact variables, commands, compatibility, artifacts, and release evidence. A repository or configuration file proves source presence, not a production deployment.
For terminology and verified public links, use the Reference.