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
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.
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?
InsForge
@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.
InsForge
@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.
Nonilion
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
InsForge
@hanghuang @deepanshu_goyal3 That's awesome! Love to discuss and share thoughts together.
congrats!how long does it typically take to create a fresh backend branch?is the provisioning process instant or dependent on project size?
InsForge
@dylan_russell It depends on project size and branch mode. `schema-only` is lighter and faster; `full` mode has to restore schema + data at creation time, so large databases take longer. Once the branch is ready, it runs on its own backend infrastructure with no live coupling to prod.
InsForge
@dylan_russell it depends on project size right now but we are doing a lot of exciting updates to really speed up the process!
This is exactly what agent driven development needs. For teams in regulated industries fintech, healthtech is there an audit log of every action taken within a branch? Being able to trace exactly what an agent did in an isolated environment would be critical for compliance sign-off.
InsForge
@dominic_cruz Totally agree! auditability matters a lot for regulated teams. Today the merge flow gives a structured diff and conflict context before changes reach production. I wouldn’t overclaim it as a full compliance-grade per-agent audit trail yet, but branch-level visibility and accountability are definitely core to where this should go.
Love the concept. Once a branch is running what does observability look like? Can I pipe branch level logs, query traces and error events into my existing monitoring stack Datadog, Grafana, etc. or does InsForge have its own builtin observability layer?
InsForge
@elena_fischer1 Today InsForge has built-in logs / diagnostics that agents can read, and a branch runs as its own backend environment.
Native branch-level export into Datadog/Grafana isn’t something I’d claim as built-in yet, but it’s a very natural direction for teams that want branch observability inside their existing monitoring stack.
Really impressive. If two feature branches both modify the same table schema independently and then try to promote to production how does InsForge detect and surface those conflicts? Is there a diff view or a merge review step built into the workflow?
InsForge
@elijah_smith6 yes, there’s a merge review step. We run a 3-way diff: parent at branch creation, parent now, and branch now. If two branches both changed the same table schema differently, the later merge will be blocked with a conflict report instead of silently applying. The diff shows which table / policy / function / config object diverged and why.
Congrats on shipping! What's the typical spin up time for a new backend branch in practice? If it takes several minutes it might interrupt fast iteration loops. If it's under 30 seconds it becomes genuinely seamless. Would love a real world benchmark.
InsForge
@elsa_williams It depends on project size and branch mode. `schema-only` is much faster; `full` mode restores schema + data at creation time, so large databases naturally take longer. I don’t want to give a fake universal benchmark here, but the tradeoff is exactly why both modes exist.