Connecting Your Code

Vygl scans code three ways. Pick one — these are alternative ways to trigger scans, not stages you need to combine. Most teams only ever use one.

	Managed SCM	CI/CD pipeline	Local CLI
Where scans run	Vygl’s servers (clones your repo)	Your CI runner (your code stays put)	Your laptop
What triggers a scan	GitHub/GitLab/Bitbucket webhooks (every push & PR)	Your pipeline (every build)	You, manually
Setup	One click — install an App / OAuth	Add a step to .github/workflows/, .gitlab-ci.yml, etc.	docker pull
PR / MR comments	✓ Built in	✓ With a Git Token	—
Blocks merges via CI status	✓ Commit status check	✓ Pipeline exit code	—
Source code leaves your env?	✓ Cloned to Vygl	✗ Stays in your runner	✗ Stays local

If your code is on GitHub.com, GitLab (Cloud or self-hosted), or Bitbucket Cloud, managed SCM is the simplest path — same automation, less wiring. CI/CD is the right pick when your runners must do the cloning (private network, Bitbucket Server / GitHub Enterprise Server, regulated environments).

Managed SCM integration (recommended)

Install the Vygl GitHub App or authorize the GitLab / Bitbucket OAuth integration. Once connected, Vygl receives webhook events for pushes and pull requests, runs scans automatically, and can post finding summaries directly on PRs.

Best for: teams on GitHub.com, GitLab (Cloud or self-hosted), or Bitbucket Cloud that want the whole flow automated end-to-end.

Setup: one click, browser OAuth, repository selection. No CI configuration required.

GitHub App One-click install, automatic webhook scans, PR comments. → GitLab GitLab.com or self-hosted, OAuth, MR comments. → Bitbucket Bitbucket Cloud, OAuth, PR comments. →

CI pipeline + API key

Add a single vygl scan step to your CI pipeline (GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins, anything with Docker). The CLI auto-detects branch, commit, and repo URL from the CI environment and pushes findings to the dashboard. Pair it with a Git Token to enable PR comments.

Best for: self-hosted SCMs that aren’t on the managed-OAuth path (Bitbucket Server, GitHub Enterprise Server), private-network repos that Vygl can’t reach, or teams who’d rather drive scans from their own runner. Also fine if you simply prefer it — the dashboard experience is identical.

Setup: copy a config snippet into .github/workflows/, .gitlab-ci.yml, or your equivalent. Add VYGL_API_KEY as a CI secret.

You don't need this if you've installed the managed SCM app

The managed SCM integration already runs scans on every push and PR, blocks merges via commit status, and posts comments. Adding a CI step on top duplicates work and produces redundant scan rows in the dashboard. Use one or the other, not both.

CI/CD Pipelines

PR / MR Comments

Local CLI (no SCM at all)

Run vygl scan from a developer laptop or any environment with Docker. The CLI works offline (--no-upload) for evaluation, or with an API key to push results to the dashboard.

Best for: evaluation, ad-hoc audits, monorepos that span multiple SCM providers, repos that aren’t pushed anywhere yet.

Quickstart (5 minutes)

Running Scans (CLI)

Managing connected repositories

Once a provider is connected, Settings → Connections lists every connection and, beneath it, an Enabled repositories table of the repositories Vygl scans.

Disabling scanning on one repository

1. Open Settings → Connections.
2. Find the repository in the Enabled repositories table.
3. Click its disable (trash) action.

Vygl stops scanning that repository on future pushes and pull requests. The SCM connection itself stays intact, and the repository’s existing scans and findings are kept — you can re-enable it any time from the Add Repository dialog on the Projects page.

Disconnecting an entire SCM provider

1. Open Settings → Connections.
2. Click the disconnect (unplug) action on the connection and confirm.

The connection is removed and webhooks for every repository under it are torn down — no more managed scans from that provider.

Your findings are kept

Disabling a repository or disconnecting a provider never deletes scans, findings, or projects — it only stops future managed scans. Merge-gating checks already posted on open pull requests simply stop updating. To also remove Vygl’s access on the provider’s side, follow the “Removing access” section on that provider’s page.

Who can do this

Disabling repositories and disconnecting providers are Owner/Admin actions. See Members & Roles.

Do I need to combine them?

No. Pick one. The three approaches can coexist, but for almost every team a single approach is enough:

• Managed SCM already scans every push and PR, posts comments, and gates merges via commit status — there’s no separate “CI gate” you need to add.
• CI/CD already runs on every push and PR (because your pipeline does), and --fail-on blocks the merge via the pipeline’s exit code.

The only time it makes sense to layer them is the local CLI alongside one of the cloud paths — running vygl scan --no-upload on a developer laptop for a fast pre-commit check, while managed SCM or CI handles the authoritative scan on push. That’s the only “combining” pattern most teams will ever need.

Self-hosted SCMs

Self-hosted GitLab is supported via the managed integration — set GITLAB_URL at deploy time and authorize the OAuth app on your instance. Bitbucket Server and GitHub Enterprise Server can post PR/MR comments via the Git Token + CI flow (the token’s API host is parsed from the project’s repository URL), but the managed-OAuth path is Cloud-only today.