Roadmap

What we plan to build, what we are exploring, and what recently shipped. This page deliberately carries no dates: FragonForge is built by a small team, and we do not publish deadlines we cannot keep. Items ship when they are done and tested. When plans change, we update this page rather than let it rot.

Planned

decided, no promised order

Managed hosting for what the agent builds

further out

The project orchestrator already turns a goal into a dependency-ordered pipeline of merge requests. Managed hosting is the step after the merge: you mark a repository as ready, FragonForge produces a hosting-ready build and runs it on the same EU Kubernetes infrastructure our sandboxes use. From issue to running app, not just issue to merge request.

Billing would follow what actually runs, per workload, on top of your plan. We write "would" deliberately: the pricing model is not designed yet, and we are not going to invent one on a roadmap page. Territory for the next major version, not for tomorrow.

A support commitment below Enterprise

Today only Enterprise carries named response times, and the pricing page says so plainly rather than letting a paying customer assume otherwise. That is a staffing reality of a company this size, not a position we intend to keep.

As the product grows to where support can be staffed properly, a response-time commitment for the paid self-serve plans comes with it. An uptime SLA follows the same logic: we will commit to a number once there is enough operating history to stand behind one, which is also why the status page shows what it shows today. No date attached, on purpose. A support promise we then miss would cost more trust than the honest gap does now.

Dropped: the self-hosted runner

This page used to list a self-hosted runner as the planned answer for forges that are only reachable inside a VPN. We dropped it. A runner in your network would hold your forge token and LLM key itself, a different security model than the credential-free sandbox we run today, and we would rather remove a promise than keep one we are not sure we should build. The answer for VPN-only setups is now the Enterprise tier, where a deployment on your own hardware can be arranged by agreement. If this change affects your decision, tell us.

Exploring

not committed

Things we want and have not committed to. They are listed here so you can tell us which of them would actually change your decision.

  • Spend metering for runs on your own key

    FragonForge AI runs are metered to the cent and capped by the budget your plan includes, so that half is done. Runs on your own key are not: the cost dashboard shows the planning and indexing calls, while the agent's model spend inside the sandbox goes straight to your provider. Metering that path needs token counting for keys we do not hold, so until then our honest advice stays the same: set a spending limit at your provider.

  • Our own inference hardware, serving open-source models

    FragonForge AI runs on models we buy today, reached through a gateway's EU endpoint. The processing stays in the EU, but the gateway operator is a US company, so that guarantee rests on a contract rather than on where the company sits. It is the last piece of the chain we do not own. If this business ever earns enough to pay for it, we would rather serve open-source models on hardware we own than route through anyone else. Calling that a plan would be dishonest: there is no date, no order, and it depends on profit that does not exist yet.

  • SOC 2 / ISO 27001 certification

    Asked for by every regulated prospect, and honestly answered with 'not yet' today. Certification is a question of audit budget and calendar time; we will not claim progress before an engagement exists.

Recently shipped

live

  • FragonForge AI: models we operate, billed in euros

    Every paid plan includes a monthly budget in euros, so a run works without you holding an API key at all. Those runs go through a gateway's EU endpoint, so the processing stays in the EU. Bringing your own key stays available on every plan, including Free, and those runs do not draw on the budget.

  • SAML single sign-on and SCIM provisioning

    Your Owner uploads the identity-provider metadata and signs in through your own IdP; SCIM 2.0 keeps seats in sync with your directory, including deactivation. Both are configured in the dashboard by you, not by us.

  • Connect a ChatGPT plan as your seat

    A ChatGPT Plus, Pro, Team, or Business plan can fund the runs you start, instead of a pay-per-token API key. OpenAI only for now. Automated triggers and the planning stage stay on the organization key.

  • Self-serve plan changes in both directions

    Upgrade or downgrade from the billing portal. Upgrades apply immediately and are prorated; downgrades take effect at the period boundary.

  • Bitbucket pull-request triggers

    Pull-request webhooks on Bitbucket Cloud now dispatch automatically: opened and updated PRs run analysis, comments reach the agent for feedback, merges and declines are tracked. The issue-label trigger is off the list for a structural reason - Bitbucket Cloud has no issue labels.

  • Manual run trigger via API and CLI

    Start a run without labeling an issue, from the API or the CLI. Manually started runs pass the exact same plan, quota, and concurrency checks as webhook runs.

  • Legal package

    Terms, Privacy Policy, DPA, and a public sub-processor list - published and in force.

  • Business tier on the pricing page

    EUR 299/month: 30 repositories, 30 seats, 5 concurrent runs, 120-minute wall clock, Kata VM runtime.

  • Audit log with CSV and NDJSON export

    90+ audited actions, filterable in the dashboard, and exportable over a date window as CSV or cursor-paged NDJSON for a SIEM.

This page is a statement of intent, not a contractual commitment. For what the product does today, read how it works and the security architecture.