Self Hosting
Self-Hosting Architecture
In a self-hosted deployment, Helio Audit sits alongside your existing Git and delivery tools. Developers open Pull Requests in the Git provider; Helio Audit analyzes changes and returns Review findings inside your Organization boundary.
System flow
Major actors
| Actor | Role |
|---|---|
| Developer | Authors changes, opens Pull Requests, consumes Reviews |
| Git provider | Hosts Repositories and Pull Requests (GitHub, GitLab, Bitbucket) |
| Helio Audit | Self-hosted platform that analyzes changes and produces findings |
| CI/CD systems | Optional pipeline integrations such as GitHub Actions and Jenkins |
| IDE / CLI | Surfaces feedback where developers already work |
Capability layers
- Repository connectivity — connect and synchronize Repositories from supported Git providers
- AI Reviews — change understanding, Pull Request Review, security-focused Review, and resolution assistance
- Security and quality analysis — application security, secrets detection, dependency security, infrastructure security, and related quality signals
- Repository intelligence — broader Repository and branch-level analysis beyond a single Pull Request
- Developer experience — CLI, IDE extensions, agent prompts, and reusable Organization guidance (skills)
- Reporting — consolidated views for engineering, security, and compliance stakeholders
Deployment topology
- Helio Audit runs in your Docker, Kubernetes, Linux, or cloud environment
- Your Git provider remains the system of record for source and Pull Requests
- Network access between Helio Audit and the Git provider must be allowed per your installation guide
- Developers reach Helio Audit through Pull Request comments, IDE extensions, and CLI workflows
Trust and data boundary
Self-hosting keeps analysis inside the Organization boundary you define. See Security for the security capabilities that operate on that code.