← LGTY

What happens after you install

Installing the GitHub App turns on Change Analysis immediately — no connection, no config file, nothing to wire up. Production Impact and Visual Review are different: they're grounded in infrastructure you actually run, and there's no way to make that trustworthy without a little real setup. This page says plainly what each step buys you, and what you'll see before you've done it.

Day one: Change Analysis, zero setup

Once repos are selected, LGTY posts a brief on your next pull request — behavioral delta and "who calls this," worked out from the repository alone, with call-graph receipts pointing at file:line. Nothing to connect, nothing in lgty.yml required. This is the floor every pull request gets, from the first day.

Turning on Production Impact

Production Impact answers a question Change Analysis can't: not just what changed, but what depends on it right now, in production — real traffic, real downstream consumers, a real migration lock. Getting that right needs LGTY to read your actual infrastructure, and a few things only you can supply.

Which environment is production. Most observability platforms carry more than one environment that looks like production — a blue/green pair, a -v2 migration in progress, a staging tier someone renamed once. Nothing in the data reliably tells them apart. If LGTY guessed and guessed wrong, your brief wouldn't show an error — it would show a blast-radius number that looks exactly as confident as a right one, for the wrong environment. So this is declared once per connection, on the Connections page, and never inferred — see the Production Impact setup guide for the mechanics.

A read-only connection to where that metadata lives. Paste a scoped, revocable token for an observability platform you already run (Datadog, Grafana, New Relic, Honeycomb, Dynatrace — usually fastest, since you're reusing access you already granted the vendor), or add the lgty GitHub Action to a scheduled CI job, authenticated by OIDC, with no token to hold. Either way, LGTY reads metadata — dependency edges, traffic estimates, table size estimates — never a row of your data.

Your database, declared once in lgty.yml. Static migration analysis (lock class, rewrite risk, missing rollback) needs to know your database engine, version, and where your migration files live. LGTY doesn't infer this from your source or a live connection — it's a claim about your production database, and only you can make that claim correctly. Add the production_impact.database block once and the static check runs on every pull request, no connection required.

A narrowly-scoped CI role, if you want row counts. The static check works without it. To turn "lock class: ACCESS EXCLUSIVE" into "lock class: ACCESS EXCLUSIVE — ~2.1M rows," run the lgty action against a database role scoped to read table structure and size, never your data.

Optional — PagerDuty, for incident correlation. Connect a read-only token and tell LGTY which PagerDuty service ids map to which of your services. That mapping is a declaration for the same reason the environment is: guess it wrong and you'd silently attribute someone else's incidents to your change.

Full technical detail — the exact lgty.yml shape, connection tiers, and troubleshooting — is in the Production Impact setup guide.

Turning on Visual Review

Visual Review renders your UI before and after a change, at the states your diff actually touches. The setup every team can use, regardless of hosting provider or deploy topology: your CI uploads the screenshots it already produces for its own tests, keyed to the commit. There's no fallback source — if that upload step isn't there, there's nothing to render from, and LGTY says so instead of guessing. (If you already publish a reachable preview deployment for each commit, LGTY can discover and render against that directly instead — see the Visual Review setup guide for that contract.)

The minimum addition is one step in a CI job that already produces screenshots — Playwright, Cypress, Storybook's test runner, or a hand-rolled script all satisfy it identically — pointed at wherever it already writes images. No lgty.yml entry, no state list to declare: the upload's arrival is the configuration.

What you see while it's not fully wired up

Nothing here is silent, and nothing here nags. A capability that isn't connected yet says so, in the same place a finding would otherwise appear:

  • Production Impact, no source connected yet. Every path it would have spoken to instead reads uncovered — never a clean bill of health, never "no impact." Change Analysis keeps running normally alongside it.
  • A connection exists but its environment isn't declared. This shows up as its own state on the Connections page, distinct from both "connected" and "not connected" — the credential is stored, but the connection isn't queried until the environment is named.
  • Visual Review, no upload has ever arrived for this repo. Renders exactly like today's not-run state — no claim that anything is coming.
  • Visual Review, an upload has arrived before but not yet for this pull request. The brief posts immediately without that facet and updates in place once the images land — you'll see "your CI hasn't finished yet, will update here," not a gap that quietly stays empty.

Why the setup is split three ways

Configuration for the paid capabilities lives in three places — the dashboard, lgty.yml in your repo, and a step in your CI — and that's a real cost, not an oversight. Each place holds a different kind of fact:

  • The dashboard holds credentials: tokens and connections an admin can see, scope, and revoke. Nothing that belongs in source control lives here.
  • lgty.yml holds facts about your systems that only you can state correctly — database engine and version, criticality overrides, which capabilities are on for a repo. It's config-as-code: reviewed and versioned like anything else in the repo, not a form buried in a settings page.
  • Your CI is where metadata collection and screenshot rendering actually run, inside your own perimeter, using access you already control. LGTY never asks to run inside your infrastructure any other way.

What LGTY never asks for

Every read-only connection above — token or CI role — is scoped to metadata: dependency edges, traffic estimates, table structure and size. None of it can read a row of your data. Row-count estimates come from cheap, built-in database statistics, not a scan or a SELECT count(*); the CI database role is narrow enough that it can see a table's shape, not what's in it. A pull request is a lookup against a metadata index LGTY already built — it never opens a live query against your systems while you're waiting on a review.