InsForge Backend Branching - Git style branching for your backend
by•
Git-style branching for your entire backend. Spin off a branch to get a full, isolated copy of everything: your database, storage, auth, edge functions, and more, ready for your agents to experiment on without touching production.
Replies
Do branches have a configurable TTL or auto-cleanup policy? I can imagine teams accumulating dozens of stale branches quickly if there's no automated housekeeping. Would love to know if that's built in or on the roadmap.
@carlos_leonardo1 very fair point. Today you can delete/reset branches manually, but configurable TTL / auto-cleanup is exactly the kind of housekeeping we want for teams running lots of agent branches.
@carlos_leonardo1 This is on our roadmap! we don't want to see 100 branches all live and hard for it to clean up lol
congrats on the launch! the reset branch to main feature is honestly the most underrated thing in your whole description. when there's zero cost to failure inside a branch, agents can experiment at full speed without you holding your breath and that compounding freedom is what makes this more than just a safety tool.
@daniel_harris11 Reset is what makes experimentation feel cheap again. If the agent goes too far, you roll the branch back to T0 and keep going without touching prod.
@daniel_harris11 Exactly, agent can restore the branch for any exceptions.
How detailed is the audit trail? can teams see exactly which agent initiated a change?that could be valuable for accountability.
@luz_bidelspach totally agree, accountability matters a lot once agents can touch backend state.
Today the branch / diff / merge flow gives teams visibility into what changed before merge. More detailed agent-level attribution is something we care about, but I don’t want to overclaim it as fully solved yet.
Congratulations to the whole team!
can developers manually edit branches alongside AI agents?or is the workflow designed primarily for agents?
@fletcher_oliver yes, developers can work on branches manually too. The workflow is agent-native, but the branch is a real isolated backend environment, so humans can inspect, edit, test, and review alongside agents.
@fletcher_oliver Build for agents to understand and operate! but humans have the full visibility and can do edits as well!
congrats!
quick question:can branches be shared between teammates for collaboration? or are they tied to a single user?
@croft_benjamin today branches are managed at the project level, but we don’t have a dedicated “branch sharing” workflow yet. It’s a very natural direction though, especially for teams where multiple agents and teammates are working in parallel.
@croft_benjamin as long as you add the teammates to the org! we can share the project and the branches!
Branching for backends is wildly underrated — we just hit the same pain when migrating our backend from Python to Cloudflare Workers (different infra, same need to test risky changes in isolation). Curious: do you handle data branching too, or just code/config? Either way — congrats on shipping 🚀
@mythic_dd thanks! We handle both, with clear boundaries. In `full` mode, the branch copies schema + data at T0 for realistic testing. In `schema-only`, user-data tables start empty. On merge, schema and mergeable backend config can go back to parent, but user-data rows are not auto-merged into prod.
@jiaqichenThat split makes a lot of sense - user-data merge is the classic landmine (conflicting PKs, FK chains, audit trail integrity). Schema + config back to parent is the right boundary. The painful alternative would be CRDT-style row merging, which works for messaging apps but not for arbitrary app schemas.
Quick question: in full mode, when the branch copies data at T0, is it a logical snapshot (COW pages) or a physical clone? Curious about the cost story for users with 100M+ row tables. That's usually where "branching" pitches fall apart in real use.
Either way, congrats on shipping - branching for app backends is overdue 🚀
Does the merge diff separate schema changes from data changes and config changes? when I am reviewing what an agent did, those are really three different risk levels that need different kinds of attention. would love to know if the review UI reflects that layering or surfaces everything together.
@carter_garcia yes. Merge review focuses on mergeable backend objects: schema, RLS, functions, auth/storage config, realtime, schedules, etc. User-data rows are isolated and not auto-merged into prod, so data changes don’t get mixed into the same risk bucket.
Congrats on the launch! Curious how InsForge handles multi tenant architectures where data is logically separated within a single database rather than across separate instances. Does branching still work cleanly in that model or is it optimized for single tenant setups?
@diego_joaquin1 Branching works at the backend/project level, so it also works for multi-tenant apps where tenants live inside one database.
In `full` mode, the branch gets the parent schema + data at T0. In `schema-only`, user-data tables are empty, which is often better if tenant data is sensitive. On merge, schema/config changes can go back, but tenant data rows are not auto-merged into prod.
Smart product. One thing I'm wondering when branching a backend with large storage volumes does InsForge use copy on write semantics to avoid duplicating unchanged data? Or is each branch a full physical copy? That distinction could be a big deal for storage heavy apps.
@ding_hao For storage objects, we intentionally don’t copy all objects at branch creation. Existing parent files are readable from the branch, while new branch writes stay isolated. For the database, `full` mode copies schema + data at T0; `schema-only` is the lighter path for large projects.
I have also been making something similar - an agent orchestration that predicts the scale bottlenecks in your codebase, so that you can fix them before the actual traffic on your app face it.
Would love to connect @hanghuang
@hanghuang @deepanshu_goyal3 That's awesome! Love to discuss and share thoughts together.