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
curious about performance.does branch creation duplicate data physically or use snapshots under the hood?how does that impact costs?
InsForge
@joshua_cooper2 We support two branch modes: `full` copies schema + data at branch creation time, while `schema-only` copies schema and mergeable backend config but leaves user-data tables empty. For huge prod DBs, schema-only is usually the lighter path, then you add seed/test data as needed.
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.
InsForge
@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.
InsForge
@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.
InsForge
@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.
InsForge
@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.
InsForge
@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.
Congrats on shipping this! Does InsForge support snapshotting a branch at a specific point in time? Being able to roll back a branch to a known good state mid experiment would be incredibly useful when agents go off the rails.
InsForge
@chen_hao3 great point. Today `branch reset` rolls the branch back to its T0 state, the moment it was created. We don’t support arbitrary point-in-time snapshots inside a branch yet, but the reset flow is there for “agent went off the rails, give me a clean slate.”
InsForge
@chen_hao3 We support branch reset! and we also have backups that people or agents can manually backup as well!
Congratulations to the whole team!
can developers manually edit branches alongside AI agents?or is the workflow designed primarily for agents?
InsForge
@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.
InsForge
@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?
InsForge
@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.
InsForge
@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 🚀
InsForge
@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 🚀
Really impressive concept. Quick question for the team how do you handle branch merging when there are schema migrations involved? That's always been the tricky edge case with database branching. Would love to understand your approach.
InsForge
@daniel_juan2 We use a 3-way diff: parent at branch creation, parent now, and branch now. If the branch migration changes a schema object that parent didn’t touch, it can be previewed and merged. If both sides changed the same table / policy / function differently, merge is blocked with conflict context instead of guessing.
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.
InsForge
@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.