GitHub integration

Connect a GitHub account, import repositories as Vera projects, optionally discover their config with AI, and keep them in sync automatically.

Connect a GitHub account or organization to Vera and import repositories as projects — optionally letting Vera propose testing config from the repo source and keep it in sync as you push.

Not the same thing as running Vera from GitHub Actions. That is the vera-run action, which needs no App, no installation and no connection — just an API token. See CI integration. This page is about letting Vera read your repository.

Requires the platform to have a GitHub App configured (QA_GITHUB_* env vars). When it isn't, none of this is visible. Connecting and importing additionally need the Pro plan; auto-sync needs Team.

App configuration (platform admin, one-time)

When creating the GitHub App (github.com/settings/apps), the post-install redirect belongs in the App's Setup URL, not the OAuth "Callback URL":

Setup URL = <public-url>/api/public/github/callback, with "Redirect on update" ticked. GitHub sends the user here after they install or reconfigure the App. Because Vera uses the installation flow (not OAuth), leave the OAuth Callback URL field blank — pointing it at the redirect path is the classic misconfiguration that strands users on a 404 so the connect state never flips.
Webhook URL = <public-url>/api/public/github/webhook.
QA_PUBLIC_URL must be set so the callback can redirect the browser back to the dashboard. In production it's your deployment origin; in split-origin local dev set it to the dashboard: QA_PUBLIC_URL=http://localhost:4546 (without it, the redirect resolves against the API origin :4545, which serves no dashboard → JSON 404).
The feature appears once the app id, private key and app slug are set — the private key goes in the environment base64-encoded, not as a raw PEM. The webhook secret is not part of that gate: without it everything but auto-sync works, and the webhook endpoint answers 404.

1. Connect

Settings → Integrations → Connect GitHub. You're sent to GitHub to install the Vera app; pick the repositories it may access. GitHub redirects you back and the panel shows the connected account.

Vera stores only the numeric installation id — no access tokens at rest. Short-lived tokens are minted per request from the App key.
Disconnecting removes Vera's access record; to fully remove it, also uninstall the app from your GitHub settings.

2. Import repositories

Projects → Import from GitHub. Search and multi-select repositories; already -imported ones are flagged and cannot be re-selected. Each becomes a bare project (name + repo link, no base URL) — set its base URL before it can run anything.

Up to 20 repositories per import. The server re-checks every one against what the installation can actually see, so a repo you cannot access is refused rather than silently created.
Imports respect your plan's project limit, per repo: if the batch runs out of slots, the ones that fit are created and the rest are reported as blocked rather than the whole import failing. The seeded example project does not consume a slot — otherwise a Free workspace's single project would already be spent on the onboarding sample.

Two things a linked repo unlocks beyond config discovery: pushing an issue to GitHub can use the App installation instead of a stored token (see Issues & triage), and Vera can read business rules out of the repository source (see Business context).

3. Discover config (optional, AI)

On a GitHub-linked project: project settings → General → Discover from GitHub. Vera fetches a read-only source snapshot and proposes a base URL, login/auth roles, and a seed command for your review. Nothing is applied until you click Apply.

An imported snapshot has no .env, so any credentials come only from committed code; a discovered seed command is informational (it can't run from a snapshot).
It runs on your workspace's own AI key (Settings → AI), like every other generation feature — or on the free onboarding grant while that lasts. Without either, it refuses with the usual "add a key" prompt rather than half-working.
There are two fidelities and you get the better one on self-host. With the local claude CLI available, Vera reads the repository with read-only file tools and follows what it finds. On an API key it falls back to stuffing the high-signal files into one prompt, bounded to a few tens of kilobytes and four directory levels, skipping node_modules, dist, build and friends. Both propose; neither applies.

4. Auto-sync (optional)

On a GitHub-linked project: project settings → GitHub sync → "Propose config updates automatically when the repository changes". On a push to the repo's default branch, Vera re-reads the repo and, if the config it finds differs, surfaces a proposal banner on the project. Reviewing and applying it is always an explicit action — auto-sync never changes your config on its own. There is no green gate for a config change the way there is for a repaired selector, so there is no auto-apply here at all.

Turn it off (default) and pushes are ignored.

Team plan and above. On Free or Pro the toggle does nothing: the webhook is still acknowledged, no proposal is raised.
Only pushes to the default branch count, and only a meaningful difference raises a banner — a changed base URL, auth appearing for the first time, or more setup actions than before. A repeated delivery of the same commit is ignored.
A proposal can contain credentials read out of committed code, so its auth block is sealed at rest before it is stored. An unsealed proposal would put the application-under-test's passwords in a database dump in the clear.

Security notes

The webhook verifies GitHub's X-Hub-Signature-256 (HMAC) over the raw body before parsing it, and resolves the tenant strictly by installation id — an installation Vera does not know is a silent no-op. A rejection's reason is logged, never returned.
Source archives are capped at 80 MB compressed and 20,000 files, and extraction rejects symlinks, hard links, absolute paths and any .. segment. The snapshot directory is always removed afterwards, including on failure.
The App client talks to api.github.com and codeload.github.com only, so there is no user-supplied URL to guard.
QA_GITHUB_* are platform env vars only — never editable over the API.