Use case

Roll out LGTM across many repos

Install LGTM org-wide once, then enroll specific repos progressively. Per-repo config inherits from org defaults. Multi-repo rollout in days, not months.

The problem

Org has 50 repos. Manual setup per repo is a multi-day project nobody wants to own. LGTM's install-then-enroll model scales without per-repo config overhead.

The install model

GitHub App installs at the ORG level (or personal-account level). A single install grants LGTM access to the repositories the installer selects โ€” could be 1, could be 'all repos in org'.

Once installed, LGTM picks up webhook deliveries for all enrolled repos. The first PR opened on each enrolled repo triggers index + first review. No per-repo manual setup required.

Adding repos later: github.com/organizations/{org}/settings/installations โ†’ LGTM โ†’ Configure โ†’ add repos. New repos start getting reviews on the next PR opened against them.

Org-level defaults, repo-level overrides

Default review behavior is configured once at the org level: which agents enabled, which models, what verdict threshold, what severity blocks merge. New repos inherit these defaults.

Override per repo when needed: Settings โ†’ Repos โ†’ {repo} โ†’ Config. Override specific values; unset values inherit from org. Visual diff in the UI shows what's inherited vs overridden, so config drift is easy to detect.

Common pattern: org defaults are 'flagship model + strict severity + all agents'. Marketing/internal repos override to cheap model + relaxed severity. Production-critical repos override to flagship model + auto-approve disabled (human always reviews).

Progressive rollout strategy

Don't enroll all 50 repos on day one. Phased rollout reduces noise + lets the team adjust thresholds before scale.

Week 1: enroll 1-3 'pilot' repos. Active monitoring of review quality, false-positive rate, team feedback. Adjust verdict threshold + agent selection based on what fires.

Week 2-3: expand to 10 repos covering different stacks (front-end / back-end / infra / etc.). Confirm cross-stack quality. Per-repo config tweaks for any with unusual patterns.

Week 4+: open enrollment. New repos opt in via a CODEOWNERS file or simple PR adding the repo to LGTM's selected list. Engineering team's responsibility, not central platform.

Billing on multi-repo

LGTM's pricing is per-account, not per-repo. Go โ‚น999 / Pro โ‚น1,999 / Max โ‚น9,999 per month covers 100 / 200 / 1,200 reviews respectively across all repos in your install (up to 5 / 20 / unlimited repos). No per-repo tax, no per-PR tax (just BYOK token cost which is a separate provider bill โ€” or opt into Managed AI). Enterprise unlocks unlimited.

Cost scales with REVIEW VOLUME, not repo count. 100 repos with low PR activity might cost less than 10 repos with constant PR churn โ€” because the BYOK token bill scales with token usage.

Org-level usage dashboard: Settings โ†’ Usage. Shows reviews per repo, tokens per agent, average review latency, per-provider spend. Useful for spotting expensive repos that could move to cheaper models.

See LGTM pricing โ€” unlimited repos, no per-seat

Go โ‚น999 / Pro โ‚น1,999 / Max โ‚น9,999/mo ยท BYOK or Managed AI ยท org-wide install ยท per-repo overrides

Go to the product page

FAQs

Can I roll back a repo enrollment if reviews are noisy?

Yes โ€” github.com/{org}/settings/installations โ†’ LGTM โ†’ Configure โ†’ remove the repo. LGTM stops reviewing immediately. Existing reviews + data are retained until you uninstall completely.

What about repos with their own custom review bot?

Multiple review bots can coexist on a repo. LGTM doesn't interfere with other Apps. If you have an existing AI review bot (CodeRabbit, Greptile, etc.), LGTM runs in parallel. Compare findings; deprecate the redundant one if LGTM's quality is higher.

How do I roll out without spamming reviewers?

On enrollment, LGTM reviews only NEW PRs by default. Historical PRs don't get retroactively reviewed unless you explicitly trigger via `lgtm review --pr <n>` from the CLI. Spam-free rollout.

Can I have different teams use different LGTM installs?

Yes โ€” install LGTM separately on each org you own. Each install has its own settings, its own billing, its own BYOK keys. Useful for separate billing entities (parent + subsidiary, or multiple clients).

What about archived repos?

Archived repos don't get PR webhooks, so LGTM doesn't see them. No reviews fire. If you un-archive later, the next PR triggers index + review as normal.

Related across LGTM

Related use cases