Label an issue.
Review a merge request.

FragonForge plans, codes, and tests the fix in an isolated sandbox, then opens a merge request for your review: on GitLab or GitHub, cloud or self-managed, on Gitea and Forgejo. On Bitbucket Cloud the trigger is the pull request, not a label.

Free for 1 repository and 100 runs per month, on your own API key. Paid plans from EUR 29/month include a monthly AI budget instead. No credit card.

fragonforge run watch 1847illustrative example
queued issue #412 labeled, verified
sandbox up k8s job ff-run-1847, egress: deny
clone acme/reporting @ main (a41c9f2)
plan 1 file to change, 2 tests to add
edit src/Export/ExportService.cs
test dotnet test: 214 passed, 2 new
push branch fix/412-empty-csv-header
done MR !391 opened, awaiting review

The loop

From issue to merge request in four steps

  1. Label an issue

    Write the issue the way you would for a colleague. Add the trigger label. FragonForge receives the webhook, verifies its signature, and queues a run.

  2. The agent works in an isolated sandbox

    Each run starts a fresh Kubernetes job with a hardened runtime (gVisor, or Kata VMs on Team and Business). The sandbox holds a clone of your repository and the toolchains, and nothing else. No credentials, no network egress except one authenticated gateway.

  3. It runs your tests

    The sandbox ships real toolchains, not mocks: dotnet test, pytest, phpstan, rubocop, and more. The agent runs your test suite against its own change and iterates on failures. One condition today: your dependencies have to be in the repository already, because the sandbox has no route to a package registry.

  4. You review the merge request

    FragonForge pushes a branch, opens a merge request with a description of what it did and why, and comments on the original issue. It never merges on its own unless you explicitly allow it: autonomous merge is an opt-in that applies only to steps whose quality gate is green, and it stays off by default. Your review process stays exactly where it was: in the MR.

Read the loop in depth: agent modes, quality gate, guardrails →
issue #412illustrative example

CSV export crashes when a column header is empty. ExportService.WriteHeader throws a NullReferenceException when a report column has no display name.

merge request !391illustrative example

Fix: handle empty column headers in CSV export

fix/412-empty-csv-header → main

@@ ExportService.WriteHeader @@
- writer.Write(col.DisplayName.Trim());
+ writer.Write(col.DisplayName?.Trim() ?? "");
214 tests passed, 2 new+12 -3awaiting your review

Closes #412. WriteHeader now emits an empty cell for unnamed columns; two regression tests cover the repro.

The product

Screenshots, not mockups

Captured from a demo workspace of the real product, seeded with example data. This is the dashboard you get after signup.

dashboarddemo workspace
FragonForge dashboard showing task counts, success rate, capacity, active pipelines, and a recent activity list
Runs, repositories, capacity, and open issues in one view, with recent activity across your organization.
task detaildemo workspace
A completed FragonForge task showing the source issue, branch, duration, the merge request it opened, and an approved reviewer verdict
One run in detail: the issue it started from, the branch it pushed, the merge request it opened, and the reviewer verdict.
orchestratordemo workspace
A running orchestrator pipeline with completed, failed, in-progress, and blocked steps ordered by dependency
An orchestrator pipeline mid-run: finished steps link to their merge requests, a failed step waits for retry, blocked steps wait on their dependencies.

Deep planning

One goal in. A shipped series of merge requests out.

The orchestrator is what you use when the work is bigger than one issue: a feature, a module, or a whole app built from an empty repository. Describe the goal; a discovery stage clones and scans your repository, an architecture stage drafts a design you approve, and decomposition is validated step by step: acceptance criteria, files to touch, and tests to add are required for every step, or the plan is regenerated.

Then the pipeline runs. Each step goes through the normal loop in its own sandbox and lands as a merge request, in dependency order, with you as the gate between stages. A failed step retries from the earliest failed point, not from scratch.

orchestrator · deep planningillustrative example
goal "CSV import for reports"
discovery repo cloned, 214 files scanned
architecture drafted · approved by you
decompose 6 steps, criteria validated · approved by you
[x] 1 Parser module MR !84 merged
[x] 2 Schema validation MR !85 merged
[x] 3 Import endpoint MR !86 merged
[x] 4 Error reporting MR !87 merged
[x] 5 Upload UI MR !88 merged
[x] 6 End-to-end tests MR !89 merged

goal shipped · 6/6 merge requests merged

The infrastructure you actually run

Built for self-managed GitLab, GitHub Enterprise, Gitea, and Bitbucket, and for plain gitlab.com and github.com

Works with your forge, not just github.com

Most coding agents assume github.com and stop there. Your code might live on a self-managed GitLab, on GitHub Enterprise, on a self-hosted Gitea or Forgejo, or on plain gitlab.com or github.com. FragonForge connects to all of them: you supply the API endpoint and a token per organization, and it is validated live against your host when you save it. One requirement to know upfront: FragonForge is a hosted service and connects to your forge from our infrastructure, so an instance that is only reachable inside your private network cannot be connected today. On the Enterprise plan, a deployment on your own hardware can be arranged by agreement.

Bitbucket Cloud is the narrowest integration, and differently shaped: Bitbucket has no issue labels, so the trigger there is the pull request itself. Opened and updated pull requests run analysis automatically, a comment on a pull request dispatches agent feedback, and auto-fix pull requests still start from the dashboard. The label-an-issue loop does not exist on Bitbucket, by design rather than by backlog.

Three ways to pay for the model

Every paid plan includes a monthly FragonForge AI budget in euros: 7.50 on Solo, 25 on Team, 75 on Business. Runs draw on it as they use models, so you can start without opening an API account anywhere. When the budget is used up, runs pause and wait for the reset rather than failing or charging you something you did not agree to; an Owner can turn on an opt-in overrun limit if they would rather runs keep going. Free carries no budget.

Or connect your own API key for Anthropic, OpenAI, Google, OpenRouter, Mistral, Groq, DeepSeek, or any OpenAI-compatible endpoint. Model spend then goes on your existing contract, under the data processing terms you already negotiated with your provider, and we never resell or mark up tokens. A repository set to your key always spends your key: an organization without one fails closed, it never silently borrows someone else's.

The third way is a subscription you already pay for. Connect a ChatGPT Plus, Pro, Team, or Business plan as your seat and the runs you start spend that plan instead. OpenAI only for now; automated triggers and the planning stage keep using the organization key.

The subscription itself pays for orchestration, isolation, code search, and collaboration. Which path a repository uses is stated in its settings, so a run never bills against something you did not expect.

See what a seat covers

connected providers

  • Anthropic
  • OpenAI
  • Google
  • OpenRouter
  • Mistral
  • Groq
  • DeepSeek
  • Custom (OpenAI-compatible)

Billed by your provider, on your contract. Encrypted per organization (AES-GCM), rotatable per provider. A ChatGPT plan can stand in for the OpenAI key on the runs you start yourself.

Isolation is the product

Running an AI agent against your codebase means running untrusted code. We treat it with the same posture as a CI runner, and we built the product around that fact.

Every run executes in its own Kubernetes job with a hardened runtime, non-root, from a digest-pinned, vulnerability-scanned image. Network egress is default-deny; the only way out is a single gateway that authenticates every call with a per-run token, revoked when the run ends. The sandbox holds no credentials: clone, push, and merge request calls happen outside it, and your LLM key is attached at the egress proxy, never inside the sandbox.

Read the security architecture
sandbox isolation, per run

kubernetes job

created per run, destroyed after

gvisor / kata runtime

syscall interception or VM boundary

default-deny egress

one gateway, authenticated per run

zero credentials inside

git and LLM auth stay on the control plane

More than the loop

Beyond the loop

01

Quality gate

A quality gate built in, self-healing included: 33 community analyzers you already know run against every change, a baseline-aware gate blocks only new findings, and findings can flow straight into auto-fix merge requests. The agent cannot ship regressions your linters would catch.

33 tools · 0 new findings · repo rating: B

02

Codebase context (RAG)

On paid plans, FragonForge indexes your repository so the agent retrieves the right context instead of guessing. Chunking is AST-aware for C#, Go, JavaScript, TypeScript, Python, Java, Rust, PHP, and Ruby; every other file is chunked line by line. The index is scoped to your organization and deleted when you leave.

AST-aware for 9 languages · line-based for the rest · tenant-isolated

Pricing

Flat plans with an AI budget included

Every paid plan carries a monthly FragonForge AI budget in euros, so a run needs no API key of your own. Bring your own key instead and that provider bills you, never us.

See pricing →

Your backlog has issues that never get scheduled. Label one.

Free plan: 1 repository, 100 runs per month, hard stop, no credit card.