Setting Up Automated Bug Fixing in Your CI/CD Pipeline

Automated bug fixing only works if it's integrated into your existing deployment infrastructure. A well-written AI fix stuck in a PR that no one reviews is useless. The value comes when fixes are embedded in your CI/CD pipeline: errors captured in production, fixes drafted, validated against your test suite, and merged under rules you set. It is one part of what bugstack does, which we call autonomous software maintenance.

This guide walks you through connecting bugstack.ai to a real CI/CD workflow. We cover the GitHub App, SDK installation for JavaScript and Python, what your CI sees when a fix pull request arrives, autonomy levels, and what to check when something looks wrong.

Prerequisites

Before you start, make sure you have:

• A GitHub repository with at least one test suite (unit, integration, or end-to-end)
• A CI system that runs on pull requests in that repository (GitHub Actions, for example)
• A server-side application in a language the SDK supports: JavaScript/TypeScript, Python, Ruby or Go (this guide shows JavaScript and Python)
• Basic familiarity with environment variables and secrets management

You do not need a personal access token or a service account. bugstack works through a GitHub App installed on your organization, which is what opens branches and pull requests.

If you're not sure whether your team has test coverage, that's actually a good question to answer first. Automated bug fixing relies on tests to validate that fixes don't introduce regressions. More on this later.

Step 1: Sign Up and Connect Your Repository

Sign up with GitHub (a card is required) to start bugstack Pro: $100 a month with $100 of usage credit every month, plus a one-time $100 welcome bonus. Or book a call and we set it up with you. Once your account is set up:

1. Get started
2. Sign in with GitHub on the dashboard
3. Connect the repository. This installs the bugstack GitHub App on your organization; you choose which repositories it can see
4. Open the project page for that repository and copy the project API key

The GitHub App is the only permission bugstack holds on your repository. It reads the repository, creates branches named ai-fix-..., and opens pull requests. Merging follows the autonomy level you set per repository (Step 6). New repositories start on Review, so nothing merges on its own until you say so.

Step 2: Put the API Key Where Your App Runs

The project API key identifies your application to bugstack. It belongs in the environment of the running application (your host's environment variables or secrets manager), not in the repository.

BUGSTACK_API_KEY=your_project_api_key   # from the project page in the dashboard
NODE_ENV=production

Your CI does not need the key to run tests. The one exception is uploading source maps for a Next.js production build, covered in Step 3, which runs wherever you run next build.

Step 3: Install the SDK for Your Language

See our JavaScript SDK docs and Python SDK docs for detailed installation guides. The SDK captures uncaught server-side errors. It does not capture browser-side errors.

For JavaScript/Node.js

Install the package (the npm package is bugstack-sdk):

npm install bugstack-sdk
# or with yarn
yarn add bugstack-sdk

Initialise once, in your server entry point:

import { ErrorCaptureClient } from "bugstack-sdk";

ErrorCaptureClient.init({
  apiKey: process.env.BUGSTACK_API_KEY!,
  endpoint: "https://dashboard.bugstack.ai/api/ingest/sdk",
  environment: process.env.NODE_ENV,          // default: NODE_ENV
  enabled: process.env.NODE_ENV === "production",
  metadata: { service: "api", release: process.env.APP_VERSION },
});

For Next.js App Router, wrap each route handler:

// app/api/users/route.ts
import { withErrorCapture } from "bugstack-sdk/next";

export const GET = withErrorCapture(async (request) => {
  const users = await db.users.findMany();
  return Response.json(users);
});

For Express, register the error handler last, after your routes:

import express from "express";
import { bugstackErrorHandler } from "bugstack-sdk/express";

const app = express();
// ... your routes and middleware ...

app.use(bugstackErrorHandler({
  apiKey: process.env.BUGSTACK_API_KEY!,
  endpoint: "https://dashboard.bugstack.ai/api/ingest/sdk",
}));
app.listen(3000);

For a plain Node service (queue workers, cron jobs), bugstack-sdk/generic exports initBugStack, captureError and installGlobalHandlers.

Options worth knowing about. Defaults are in brackets:

• captureRequestBody (false), captureQueryParams (true), captureHeaders (true), maxBodySize (10000). Request bodies are off by default because they are where the secrets live.
• redactFields: an array of field names added to the built-in secrets redaction.
• metadata: an object sent with every error. Useful for a release identifier or service name.
• deduplicationWindow (5 minutes): the same error is not resent within the window. This happens client side.
• timeout (5000 ms) and enabled (true). Set enabled to false in test environments so CI runs never report.
• endpoint, or the BUGSTACK_ENDPOINT environment variable: set it to https://dashboard.bugstack.ai/api/ingest/sdk. The current SDK releases default to a different address, so set it explicitly.

Source maps for Next.js production builds. Wrap your Next.js config and upload the maps after the build so stack traces point at your TypeScript source:

// next.config.js
const { withBugstack } = require('bugstack-sdk/next-config');

module.exports = withBugstack({
  // your existing Next.js config
});

next build
npx bugstack upload

upload (alias sourcemaps) is the only command the CLI has. It needs BUGSTACK_API_KEY in the environment where the build runs.

For Python

Install the package:

pip install bugstack

Initialise early in your application:

import os
import bugstack

bugstack.init(
    api_key=os.environ["BUGSTACK_API_KEY"],
    endpoint="https://dashboard.bugstack.ai/api/ingest/sdk",
)

The Python SDK docs cover Flask, FastAPI and Django. For Ruby, gem install bugstack and Bugstack.init(api_key: ENV["BUGSTACK_API_KEY"], endpoint: "https://dashboard.bugstack.ai/api/ingest/sdk"). For Go, go get github.com/MasonBachmann7/bugstack-go and bugstack.Init(bugstack.Config{APIKey: os.Getenv("BUGSTACK_API_KEY"), Endpoint: "https://dashboard.bugstack.ai/api/ingest/sdk"}).

Step 4: Check Your CI/CD Pipeline

There is nothing to install in CI. When bugstack has a fix, it pushes a branch named ai-fix-... through the GitHub App and opens a pull request against your default branch. Your existing CI runs on that pull request exactly as it runs on a pull request from a colleague.

GitHub Actions Example

A workflow like this in .github/workflows/ci.yml is all bugstack needs from your pipeline:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

If you upload Next.js source maps from CI rather than from your host's build step, add the upload after the build, with the key as a repository secret:

      - name: Build
        run: npm run build

      - name: Upload source maps
        run: npx bugstack upload
        env:
          BUGSTACK_API_KEY: ${{ secrets.BUGSTACK_API_KEY }}

Two things to check in an existing workflow. First, that it runs on pull_request without a filter that skips bot-authored or ai-fix- branches; a pull request that never gets a CI result can never merge automatically. Second, that there is no job which approves or merges pull requests based on who opened them. That is what the autonomy level is for, and it applies bugstack's own rule: on Autopilot a fix merges only when CI is green and bugstack's sandbox proof holds on the merge base: the reproduction test fails without the change and passes with it. A workflow that auto-approves bugstack pull requests removes that check.

Key Configuration Points

1. Autonomy Level: The main control is the autonomy level, set per repository. There are three: Suggest (it writes the fix and waits), Review (a pull request per fix, you merge) and Autopilot (it merges once tests pass; safety rails still ask first). New repositories start on Review.

2. Automatic Merging: Your own CI runs on every pull request. Before a pull request opens, bugstack proves the fix in an isolated sandbox: a test that reproduces the bug fails on your current code, then passes with the fix while the rest of your test suite stays green. Autopilot merges only with that proof; without it, the pull request waits for you.

3. Changes That Always Wait for a Person: In production, sensitive changes (changing infrastructure, rolling back a deploy) always wait for a person, and bugstack never rotates a secret itself. A crash fix over 3 files or 30 lines also waits for review.

Step 5: Test the Integration End-to-End

Verify that errors are captured, a fix pull request appears, and your CI runs on it before you rely on any of it. The simplest way is a temporary route that crashes on purpose, deployed to a staging environment with the SDK enabled.

For JavaScript (Next.js App Router):

// app/api/bugstack-check/route.ts  (remove after testing)
import { withErrorCapture } from "bugstack-sdk/next";

export const GET = withErrorCapture(async () => {
  const user = await findUser("does-not-exist"); // returns null
  return Response.json({ email: user.email.toLowerCase() });
});

// What should happen next:
// 1. The SDK captures the TypeError and sends it to bugstack
// 2. bugstack reads the code and drafts a fix (add the null check)
// 3. A pull request opens on an ai-fix-... branch
// 4. Your CI runs on that pull request
// 5. On Review, you merge it

Verify in the dashboard and on GitHub:

1. Request the route once, so the error is thrown
2. Open the project in the bugstack dashboard and confirm the error was captured
3. Wait for the fix pull request in the repository. The branch name starts with ai-fix-
4. Confirm your CI ran on that pull request and reported a result
5. Review the diff. It should be small, and it should touch the file the stack trace points at

Step 6: Choose the Autonomy Level

Auto-merge should be earned. bugstack controls it with the autonomy level on each repository. Start conservative:

Weeks 1-4: Review. Stay where new repositories start. Fixes arrive as pull requests with your CI run on them. Your team reviews and merges every one, and notes which ones held.

After a month: Autopilot, where fixes have held (if desired). Use it on repositories where the fixes have earned it. Before a pull request opens, bugstack proves the fix in an isolated sandbox: a test that reproduces the bug fails on your current code, then passes with the fix while the rest of your test suite stays green. Autopilot merges only with that proof; without it, the pull request waits for you. Sensitive changes still wait for a person.

Monitoring and Troubleshooting

What to Monitor

1. Repair Success Rate: what share of fixes pass CI and hold? For reference, in bugstack's internal benchmark of planted defects on 25 September 2026, 45 of 61 graded crash runs ended with a fix that held (74%).
2. PR Merge Latency: how long from error to fix in production? Much of it is your own CI and review time, so measure your baseline first.
3. False Positive Rate: what share of fixes don't actually fix the error? Track it per repository.
4. Developer Satisfaction: are engineers happy with the fixes they review?

Common Issues and Solutions

"The error happened but no pull request appeared": Check the project page first. If the error is not there, the SDK never sent it: confirm enabled is true in that environment, the API key is the project key for that repository, and the handler that threw is actually covered (a Next.js route handler that is not wrapped in withErrorCapture, or an Express error handler registered before the routes, reports nothing). If the error is there, check the repository's autonomy level. On Suggest, bugstack writes the fix and waits for you in the dashboard; nothing opens on GitHub until you say go.

"CI is red on a bugstack pull request": Treat it like any other red pull request. bugstack will not merge it on autopilot. If the failure is in the fix, close the pull request; if it is a flaky test or a missing secret in your pipeline, fix the pipeline and re-run. A fix that cannot get a green CI result stays open for a person.

"The fixes don't actually fix the problems": Usually means test coverage is too low, or the error is too complex for a small, scoped fix. A crash fix over 3 files or 30 lines always waits for review, so only small fixes merge on their own. Keep the rest for your engineers, and if a merged fix turns out wrong, undo opens a revert pull request.

"We're getting too many PRs": Lower the autonomy level on that repository. The SDK has no per-error-type switches; if a noisy environment is the cause, set enabled to false there. The same error is already deduplicated for 5 minutes on the client before it is sent.

Moving to Production: A Phased Rollout

For a deeper look at what makes code truly self-healing, see our guide to building self-healing software.

Don't flip on full autonomy overnight.

Phase 1 (Weeks 1-4): Review only. bugstack drafts fixes for the errors it captures and opens them as pull requests. Your team reviews and merges each one.

Phase 2 (Month 2): Selective automation. Move one or two low-risk repositories where fixes have held to Autopilot. Monitor merge quality closely.

Phase 3 (Month 3+): Autopilot where it is earned. Autopilot on the repositories where fixes have held. Every action is written to a tamper-evident audit log, and undo opens a revert pull request.

---

Ready to set this up? Sign up with GitHub (a card is required) and start bugstack Pro. Get started. For configuration questions, check the integrations documentation.