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 five peer Lightning IT products and the separate ModuLix engineering foundation. 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 |
|---|---|---|
| Run automation through a controlled runtime boundary | AIO — Automation and Operations Platform | AIO overview |
| Host approved workloads on an infrastructure platform | Wunderbox — Infrastructure Platform | Wunderbox overview |
| Develop and validate governed delivery work | Workbench | Workbench overview |
| Observe services and platforms through governed signals | Atlas — Observability Platform | Atlas overview |
| Govern assessments and evidence | Platform Governance & Evidence | Platform Governance & Evidence overview |
The products remain peers. ModuLix provides reusable engineering and automation content as a foundation; it is not a sixth sellable product.
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.