Connect your sources
Choose the evidence that answers your architecture question, with clear boundaries for code, cloud, IaC, and CI/CD.
Create a workspace before choosing integrations. Connect the part of the system you need to understand first; you can add other sources later.
Choose by the facts you need
Start with the application you want to understand.
Connect a selected GitHub, GitLab, or Bitbucket repository, or upload a source archive. A workspace does not require a GitHub account.
- What it contributes
- Services, imports, dependencies, API definitions, calls, and data access found in the submitted revision.
- What remains unknown
- A source snapshot cannot establish the current deployed state or prove that a particular path was exercised in production.
Add observations from the environment.
Use the managed collector with your authenticated AWS, Azure, or Google Cloud CLI and a scoped workspace token. Collection runs in your environment.
- What it contributes
- Bounded resource inventory, provider account identity, supported relationships, collection times, and coverage warnings.
- What remains unknown
- Coverage depends on the collector's supported scopes and permissions. A missing or partial collection does not prove that a resource was removed.
Explain what the infrastructure declares.
Include infrastructure configuration in the repository or archive you review. Hyperoru can connect those declarations to application and cloud evidence.
- What it contributes
- Declared resources, network configuration, policy boundaries, and the configuration supporting an architectural relationship.
- What remains unknown
- A Terraform file or Kubernetes manifest expresses configured state. It does not prove that the configuration was applied; inspect cloud evidence for corroboration.
Connect the code to how it is delivered.
Include pipeline configuration with the source snapshot. Repository merge checks can submit an exact revision for an architecture review.
- What it contributes
- Build and deployment configuration, pipeline relationships, declared targets, and review results attached to a particular revision.
- What remains unknown
- A pipeline file does not prove a successful deployment. Check the specific evidence and observation time before treating a configured target as runtime truth.
Connect a repository or upload
In Repositories, choose one of the supported paths:
| Source | Setup | Result |
|---|---|---|
| GitHub | Authorize an installation and select repositories within its permitted scope. | Reviews tied to selected repository revisions. |
| GitLab | Add GitLab.com or an allowed self-managed host with scoped read access, then select discovered projects. | Reviews of explicitly selected project revisions. |
| Bitbucket | Connect a Bitbucket Cloud account boundary with read access and select repositories. | Reviews of explicitly selected repository revisions. |
| Source ZIP | Upload a repository or a supported bundle and wait for archive validation. | A review tied to that uploaded source snapshot. |
An account connection does not authorize every project. Review the selected scope and source revision before starting work. See GitHub setup, GitLab and Bitbucket setup, or upload requirements.
Add cloud observations
Use the cloud collector with your authenticated provider CLI and a workspace token that can submit evidence. It records the provider account boundary, collection scopes, time, and warnings. Collection runs in your environment with read permissions.
Submitting cloud evidence is separate from connecting a repository. Inspect collection status and confirm that the expected cloud observations are present in the model you are reviewing. A successful upload alone does not establish that every expected source has been reconciled into that review.
Add infrastructure and delivery context
Include relevant IaC and pipeline files in your source snapshot. They describe configured resources, network boundaries, build steps, and deployment targets. Use repository merge checks when a review should apply to a specific change.
IaC is declared configuration. Cloud is an observation of the collected environment. CI/CD configuration describes a delivery path. Keep those distinctions when interpreting a relationship.
Confirm coverage after the review
Open Coverage for the review you selected in Map or Truth. Confirm the source label and collection time, then inspect observed and missing source families. A capability being available in the connection catalog does not mean that source was collected.
If a source is absent, the model's answer must remain bounded to the evidence it has. Read your architecture map next.