bugstack Documentation

bugstack is autonomous software maintenance. It watches your app and your repository, fixes what breaks, and sends every change as a pull request you control. Pick your language, install the SDK, and connect your repository.

Start here

Quickstart

Install the SDK, connect your repository, and get your first fix pull request.

→

Install by language

Platform docs

• How it works →
• Privacy & data handling →
• Error reference →
• Integrations →

SDK reference

• JavaScript SDK reference →
• Python SDK reference →
• Ruby SDK reference →
• Go SDK reference →

What bugstack does

Keeping software running takes constant work: crashes, failed deploys, vulnerable packages, leaked secrets, dependencies that rot. bugstack takes that upkeep on. It finds the problem, works out the cause, writes the change, and opens a pull request. You decide how much it does without asking.

bugstack watches four places. Your app reports crashes through the SDK. Your host reports failed deploys, with Render supported today. GitHub reports failing CI on your default branch. And bugstack reads your repository on a schedule: vulnerable packages every four hours, secrets nightly, outdated packages daily. It works without a monitoring vendor. If you already use one, keep it.

How a fix happens

1. Something is detected. The SDK captures an uncaught error on your server, a connected host reports a failed deploy, CI fails on your default branch, or a repository scan finds a problem. SDK capture is asynchronous, so your response latency is unaffected.
2. Specialist agents are assigned. A coordinator hands the problem to the right agents: a fixer that reads the code and writes the patch, a tester that reproduces the failure, and security, dependency and infrastructure specialists.
3. The change is written. Fixes are written by Anthropic's Claude. A fix over 3 files or 30 changed lines always waits for your review.
4. The fix is proven in a sandbox. In an isolated copy of your repository, with the network cut, a test reproduces the bug and fails on your current code. With the fix it passes, and the rest of your test suite still passes. Only then does a pull request open, carrying the test and its proof. How the sandbox works.
5. The change is checked. The proposed change is checked against the autonomy level you set for that repository and against bugstack's safety rules.
6. It is drafted, opened, or merged. Depending on the level, bugstack drafts the fix, opens a pull request for you to merge, or merges it. Your CI runs on every pull request.
7. The outcome is recorded. Every decision lands on a tamper-evident audit log. Undo opens a revert pull request.

Rolling it out

Each repository has one of three autonomy levels: Suggest, Review and Autopilot. New repositories start on Review, where every fix is a pull request that a person merges. Move a repository to Autopilot when you are ready. An Autopilot merge needs green CI and sandbox proof, checked again at merge: the reproduction test fails on the base and passes with the change, with the rest of your suite intact. Without that proof the pull request waits for you.

When you connect a repository, bugstack runs your test suite once in its sandbox. The project’s settings show it as sandbox-ready when every test passes.

Some things never happen without you. In production and staging, infrastructure changes and deploy rollbacks always wait for a person, at every level, and bugstack never rotates a secret itself. For dependency and security findings, bugstack scans and reports; it can open upgrade pull requests for npm packages, which is switched on per account.