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
InsForge
We shipped many incredible features in this launch! Agentic development on InsForge is even more versatile now - with monetization, branching, and custom compute services. Come and try them out, make sure to leave your feedbacks so we can make it better!
InsForge
@fermionic we will ship faster and faster :)
The PR-style review metaphor is great. I would make that the center of the demo.
InsForge
@linglistack fair, next time will 100% do that (probably will update on our website)
InsForge
@linglistack +1, the PR-style review is really the part that makes the workflow click. We’ll make it more visible in the demo.
The 3-way diff on schema and config makes sense. What stops an edge function on a branch from firing real side effects though? Solid product!
InsForge
@artstavenka1 Branch edge functions run in the branch environment, with branch-specific keys/env values. For third-party side effects, the important pattern is to use dev/test credentials or webhooks on the branch. InsForge isolates backend writes, but we still don’t want a branch function calling a real production Stripe/email/etc endpoint by accident.
What parts of auth and storage are mergeable back to main, and what stays environment-specific?
InsForge
@alstonzhuang Auth provider settings and storage bucket config are mergeable. Secrets, OAuth credentials / redirect URLs, API keys, users, sessions, and storage objects stay environment-specific. So config can move back to main, but prod credentials and real user/file data don’t get overwritten.
SocialEcho 2.0
The PR-style diff before merge is the part that really clicks for me. Agents can experiment, humans still approve.
InsForge
@eexlkuang_se Yes, that’s the core idea: let agents experiment freely, but keep the final decision human-reviewed.
The branch can carry real backend changes, and the merge preview makes those changes explicit before anything reaches production.
InsForge
@eexlkuang_se yep, human-in-the-loop is the most important part
This feels like a missing primitive for coding agents. Production should not be the first place an agent tests a backend change.
InsForge
@song_kirby Exactly. “Try it on production” does not make sense once agents are changing backend state.
We wanted Backend Branching to become that missing primitive: give the agent a real backend to test against, but keep production isolated until the changes are reviewed and merged.
InsForge
@song_kirby exactly! This is the future of agentic engineering
Congratulations for your product
InsForge
@madalina_barbu thank you so much!
Lessie AI
Congrats! Can this work with existing apps, or does the app need to be built on InsForge from the start?
InsForge
@libin_yao yes, it needs to on InsForge, because we built the branching for InsForge's primitives
Really love the concept. How does InsForge handle schema migrations across branches? If I run a migration on a feature branch and then want to merge back is there a conflict resolution mechanism or does that still live on the developer to manage?
InsForge
@amna9 We run a 3-way diff across parent at T0, parent now, and branch now. If both sides changed the same schema object differently, merge is blocked with conflict context, then the developer or agent resolves it on the branch and retries.
InsForge
@amna9 yes if there’s a conflict, then merge will be blocked. And yes we have conflict resolution mechanism
StoreClaw
Curious how teams are using this today. Is the most common use case schema changes, auth config, or edge functions?
InsForge
@phoenixhu The first use case is usually schema / RLS / migration changes, because that’s where touching prod is scariest. But the branch is the whole backend, so auth config, storage buckets, edge functions, realtime, schedules, and config changes are all part of the same workflow.
InsForge
@phoenixhu every write operation - e.g. you are developing a new feature, or want to start a dev / staging environment