Before you connect a repository

Guard works best when the first project has a clear owner, a representative repository, and a deliberately small scope. Prepare those decisions before opening setup so you do not grant broad provider access merely to discover what the product needs.

What you need

Choose a person who can connect the repository and another person—often the same owner—who can review the result. You need:

• a Guard account;
• access to a GitHub App installation or a maintainable GitLab token;
• at least one repository that belongs to the product you want to evaluate;
• permission to let Guard read that repository;
• someone responsible for reviewing findings and any proposed changes;
• an exact website URL only if the live site belongs to the same project.

For an organization-owned repository, confirm who can approve the GitHub App installation or create the GitLab credential. Avoid a short-lived personal token when the project will depend on scheduled work after that person’s access changes.

Choose the first project scope

Start with a repository that represents a real deployable product or a meaningful part of one. A small initial scope makes it easier to understand why an audit produced a finding and who owns the response.

Group repositories in one project when they contribute to the same product and should share health context. Do not place unrelated client systems in one project merely because the same team maintains them. Project members, activity, websites, reports, and automation become harder to reason about when the boundary is artificial.

A website is optional. Add it only with its canonical URL and link it to the repositories that power it. Connecting a website records project scope; it does not by itself authorize active security requests.

Choose a provider

Use Connect GitHub when the repository can be selected through an Enji Guard GitHub App installation. The installation controls which account or organization and which repositories are visible to Guard.

Use Connect GitLab for GitLab Cloud or an approved self-hosted GitLab instance. GitLab setup stores an explicit credential, host, Git author identity, and scope. Decide whether the credential belongs to one user or to the project before saving it.

If the repository does not appear in the provider picker, fix provider access first. Do not substitute a similarly named repository or a different host.

Decide what to enable

Repository connection and read-only audits are the smallest useful starting point. Other workflows have separate side effects:

• Recurring audits read new repository revisions on a schedule.
• Code review reads pull requests or merge requests and can post review comments when enabled.
• Improvements may create an issue and, after verification, a pull request or merge request for human review.
• Auto-pentest sends active requests to the exact linked website and requires explicit authorization.

Write-capable access does not authorize Guard to merge code. A human remains responsible for accepting or rejecting every proposed change. Read Provider and write matrix before enabling workflows that create external artifacts or send active requests.

Next step

Connect the chosen provider, select the repository, and create the project. Guard will start the initial published checks for the selected repositories; Understand the first scan explains what to wait for before interpreting the result.