GitHub integration

GitHub events start the run. Authorization decides what it may touch.

NopsAI connects to GitHub as a first-party GitHub App. Repository events arrive with signed delivery validation, become governed runs under the authorization of the caller they resolve to, and report status back as check runs — without a workflow file holding production credentials.

Book a demo All integrations

What it does

GitHub inside a governed run.

How GitHub participates once it is connected — and what the platform does with what it returns.

Signed webhook delivery
Deliveries are validated at the edge before anything downstream sees them. Events carrying an unknown or disabled installation are rejected before they reach the run model at all.
Multiple App installations
More than one GitHub App installation is supported, and repository operations route by repository owner. Organisations that split repositories across accounts do not need a second deployment.
Check runs and reruns
Run status flows back to the pull request as a check run, with rerun support and cancellation of stale checks when a newer commit supersedes the work in flight.
Repository file access
A run can read the repository content it was authorized for — manifests, configuration, source — as resolved context, rather than being handed a broad token and trusted to behave.

How it stays governed

The controls that make it safe to leave connected.

An integration is easy to add and hard to bound. These are the parts that decide whether it stays reviewable six months later.

Credentials are references, not values

The App private key and the webhook secret are stored in the encrypted credential registry and referenced by name. Neither appears in GitOps configuration, pipeline YAML or environment variables.

Trigger ownership stays separate from App configuration

Which repositories may start which pipelines lives in trigger manifests and webhook source records, not in the App settings. Changing an App installation cannot silently widen what a repository is allowed to trigger.

Repository metadata is never written to config

Repository names and per-repository detail are loaded on explicit refresh and returned only to that response. Only lightweight metadata — accessible repository count, last refresh, last error — is persisted.

The caller is still authorized

A GitHub event starting a run does not bypass authorization. The run resolves to a subject, and every referenced resource is checked against that subject before dispatch.

Configuration

Owned by Git, reviewed like code.

Configuration is a reviewable file rather than a form someone filled in once. Credentials appear as references; the values live in the encrypted registry.

setting/git-apps/github.yamlYAML

provider: github
app_id: "123456"
private_key_credential_ref: credential://system/github/app-private-key
webhook_credential_ref: credential://system/github/webhook-secret
installations:
  - installation_id: "987654"
    account_login: nopsai
    account_type: organization
    enabled: true

In context

Workflows where GitHub shows up.

The same integration, seen from the workflow rather than from the connection.

01Support to release

A customer-reported bug needs to ship as a hotfix

The fix is small, but no single durable trail connects the complaint, the code change, the test result and the emergency approval.

SalesforceJiraConfluenceGitHub

Open use case

05Release

Preparing a release

Scope mismatch, unmerged PRs, failed gates and an outdated runbook can all cause a late surprise.

JiraGitHubCI/CDConfluence

Open use case

06CI/CD

A CI/CD pipeline suddenly starts failing

Most failures are a diagnosis problem before they are an engineering problem, and diagnosis eats the first thirty minutes.

GitHubConfluenceServiceNow

Open use case

Common questions

What teams ask about GitHub.

How is this different from a GitHub Actions workflow?

Actions authorizes the repository and the environment. A governed run additionally resolves the caller and checks every downstream resource it will touch before dispatch, pauses durably for a named approver where the risk warrants it, and keeps one correlated record of the trigger, the decisions and the outcome. The two compose: a repository event starts the run, and status returns as a check run.

Do we have to give it broad repository access?

No. Access follows the App installation scope, and within a run the authorization check is per resource against the resolved subject. The design intent is that a run can read what it was authorized for and nothing else.

Can we run this against GitHub Enterprise Server?

The platform is self-hosted and the GitHub connection is configured with your own App credentials and endpoint. Bring your deployment topology to a demo and we will map it concretely rather than guess at it here.