Add repositories and websites

Expand a project when another repository or live site belongs to the same product and should share health context. Do not use a single Guard project as a folder for unrelated systems.

Keep one project boundary

Repositories usually belong together when they ship one product, share a release or operational boundary, or need one owner to interpret their combined health. A frontend and its API may belong together; two unrelated client applications usually do not.

Guard runs repository audits against each repository’s own revision. The project groups those results, connected websites, activity, members, and automation without pretending that all repositories share one commit or one score.

Read Projects, repositories, and websites before expanding a project that has ambiguous ownership.

Add a repository

1. Open the existing project.
2. Choose Add a repository.
3. Select GitHub or GitLab.
4. Choose a connected account, organization, or GitLab credential.
5. Search for and select the repository.
6. Optionally link an exact website to the newly selected repository and any existing repository that powers it.
7. Select Add.

Repositories already attached to the project appear under Already in this project and cannot be added again. If the provider does not list the required repository, fix GitHub App installation access or GitLab credential health rather than selecting a substitute.

After Guard saves the repository, it dispatches the same initial published checks used during project creation. The new repository’s reports and scores appear as its runs finish; existing repository results remain tied to their own revisions.

Add a website

You can add a website while selecting repositories or later from the project’s website area.

1. Choose Add website.
2. Enter the canonical URL, including the expected scheme and host.
3. Under Which repos does it power, select at least one repository.
4. Confirm the addition.

Guard rejects an invalid URL and a website already linked to the selected project scope. Use the exact production or explicitly authorized test target; do not shorten the URL to an unrelated parent domain.

The repository links supply project context for site reports and later automation. They do not claim that every path on the host is owned by every linked repository.

Verify project scope

Return to the project dashboard and confirm:

• every repository appears under the intended project and provider path;
• the new repository has explicit initial run states;
• the website appears with the exact URL you entered;
• the website is linked to the repositories that actually power it;
• no unrelated repository or duplicate website was added.

If a repository belongs in another project, use the repository transfer flow. Its history, linked websites, and enabled schedules move with it; do not delete and recreate it merely to change the project boundary.

Website safety boundary

Linking a website makes it part of the project context. It does not authorize Auto-pentest or any other active request. Before enabling active testing, verify ownership, target scope, and potential side effects under Active testing consent.

Repository audits and active website testing therefore have separate permissions even when they appear in the same project.