How NessForge fits into your existing stack

The setup takes about 5 minutes. After that, NessForge runs alongside your CI pipeline — indexing, correlating, and building a model of your deployment environment without getting in the way of your existing process.

Getting started in 4 steps

Connect your CI provider via OAuth or API token

For GitHub Actions, NessForge uses the GitHub OAuth app flow and requests read-only access to Actions run data, workflow definitions, and commit metadata. For GitLab CI and CircleCI, you provide a project-scoped API token. Nothing is written back to your CI provider — NessForge is read-only at this stage.

NessForge indexes your pipeline history

It reads the last 90 days of pipeline runs across your connected repositories. From the job definitions and deploy steps, it builds an initial service graph: which jobs produce which artifacts, which steps deploy to which environments, and which services appear together in the same pipeline. For monorepos, it reads path-based filters to map services to directory paths.

Install the GitHub App (or configure a webhook)

To receive real-time deploy and PR events, NessForge installs a lightweight GitHub App on your organization — or you configure a webhook from your CI provider if you prefer to control the integration point. The app only receives push, pull request, and workflow run events. It doesn't have write access to your repositories.

Optionally enrich the service graph

Connect a Kubernetes cluster or ECS configuration to add runtime service relationships — which pods talk to which, what config maps are mounted where. This step is optional but significantly improves failure attribution accuracy for services that share infrastructure. Setup is a read-only kubeconfig or IAM role.

Where NessForge sits in your stack

NessForge doesn't replace anything. It reads from what you already have and routes enriched context to where your team already looks.

Your existing stack

Source control GitHub · GitLab · Bitbucket reads
CI / CD GitHub Actions · GitLab CI · CircleCI · Buildkite reads
Orchestration Kubernetes · Amazon ECS reads

NessForge layer

Analysis Causal event graph · root cause engine · risk scorer NessForge

Where output surfaces

Alerts Slack · PagerDuty · OpsGenie writes
PR checks GitHub PR status checks · GitLab MR notes writes

What changes for the team

For developers opening PRs

NessForge adds a status check to each PR that shows a risk score based on your pipeline history — not generic heuristics. If your diff touches a shared config key that's historically preceded failures, the check annotates exactly which failure pattern it's correlated with and links to the historical evidence. You can ship anyway; it's informational, not blocking.

For platform and DevOps engineers

The deploy timeline view shows every active deploy in chronological order, with service dependencies overlaid. You can see at a glance when a change landed in staging vs. production, which services it touched, and whether any of those services logged anomalous behavior within the next 10 minutes. Filters by team, service, or environment.

For the engineer on-call at 2am

When PagerDuty fires, the alert includes a "NessForge context" field with the probable root cause, the change that introduced it, and a direct link to the investigation view. You can get from "paged" to "I know what happened and where to look" in under a minute, without opening six other tools first.

Technical objections, answered

Does this require changing our CI pipeline config?

No. NessForge reads from your CI provider's API — it doesn't inject steps into your pipeline YAML or require a wrapper script. You connect via OAuth or API token, it indexes your existing run history, and it receives new events via webhook or the GitHub App. Your pipeline runs exactly as it did before.

What data does NessForge store, exactly?

NessForge stores CI run metadata (status, duration, step names, exit codes), git commit SHAs and author metadata, environment variable keys (not values) that change between deploys, service dependency relationships inferred from your pipeline definitions, and structured failure events. It never stores your source code or the raw contents of CI logs. Log content is parsed for structured patterns (error codes, exception types, health check failures) and discarded after analysis.

What about self-hosted runners or on-prem CI?

NessForge works with self-hosted GitHub Actions runners and self-hosted GitLab instances — it reads data from the CI provider's API, not from the runner itself, so runner location doesn't matter. A fully self-hosted, air-gapped deployment of NessForge is on the roadmap for Q3 2026. If that's a hard requirement for your team, get in touch — we're prioritizing based on early access demand.

How does it handle monorepos?

NessForge reads your CI job definitions to map which jobs build which services, and uses path-based change detection to attribute commits to specific service directories. If you use Nx or Bazel for affected-change detection, it can import those dependency graphs directly — which produces significantly more precise risk scores. Plain path-filter-based monorepos also work, just with lower precision on cross-service impact scoring.

Can it send alerts to PagerDuty or Slack?

Yes. Slack webhooks and PagerDuty incident creation are available out of the box. The alert payload includes the root cause summary, a confidence score, affected services, the change that introduced the issue, and a direct link to the investigation view in NessForge. OpsGenie support is in beta.

How accurate is the root cause analysis?

On our early access test set, the top-ranked hypothesis is correct in approximately 84% of cases. When the model's confidence is below 70%, it presents the hypothesis as a "possible contributing factor" rather than a confirmed root cause, and surfaces the raw evidence so your engineers can reason from it directly. We'd rather show you the data than give you confident wrong answers.

What happens if we use multiple CI providers?

NessForge supports connecting multiple CI providers to the same organization. Runs across providers are correlated by commit SHA and repository, so the service graph spans all of them. The most common setup we see is GitHub Actions for application CI and a separate CircleCI org for infrastructure — both connect fine.

Ready to connect?

Setup takes about 5 minutes. We'll walk through the first integration with you on a short call.

Request early access