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
Hey Product Hunt 👋 I'm @hanghuang, co-founder of InsForge.
InsForge makes it incredibly fast to build powerful fullstack apps with your coding agent. But once you have real users, letting your agent touch your production backend directly gets dangerous fast. One wrong migration and your entire database can be gone in seconds.
That is exactly why we built Backend Branching.
A branch is a clone of your whole backend, not just the database. Your Postgres, auth, storage, edge functions, configs, all of it. Just ask your coding agent to spin one up, and it gets a real, isolated backend to build on at full speed. Your production stays completely safe.
When your agent finishes, it kicks off the merge, but nothing goes live yet. You get a PR-style diff to review first, and it only merges after you approve. If there is a conflict, the merge is blocked so your agent can go fix it. And anytime you want a clean slate, reset the branch back to main.
This is what agentic coding has been missing. Your agents build faster in real, isolated environments, and production is always safe.
We're live today and can't wait to see what you and your agents build. 👉 Got questions? Drop them below, or join our Discord.
Huge thanks to our hunter @garrytan for hunting us 🙏
@hanghuang @garrytan Congrats on the launch Hang. Looks cool, maybe a bit more practical info on conflict handling?
@garrytan @zolani_matebese we will be summarizing and listing the conflicts, and you can directly copying and pasting them into your coding agents :)
@hanghuang @garrytan Love this. The biggest fear with coding agents isn't generating code anymore, it's giving them access to production 😅
The backend branching approach feels like the missing safety layer for agentic development. Curious to know, how long does it typically take to spin up a full backend branch, and are there any limits on the number of concurrent branches?
@garrytan @sagar_deore no limits! And our goal for next quarter is to make branching even cheaper and faster
@bhawna_rajput that’s where diff comes in: you can review diffs
Backend branching sounds obvious in retrospect, but the hard part is always state. Code branches are cheap because diffing text is cheap. What happens when two branches have diverging database migrations, or one branch mutates shared infrastructure that the other branch depends on? Curious how InsForge handles merge conflicts at the data layer, not just the code layer.
@fberrez1 state is the hard part. We run a 3-way diff across backend objects, not text files. If parent and branch diverge on the same table / policy / function / config, merge is blocked with conflict context. User-data rows are isolated and not auto-merged into prod.
@fberrez1 we track the state of the branch and showing diffs (compare to parent)
@fberrez1 We want agent to understand the state and we provide the guidance on the changes by using the state diff. Agent should be understand the state diff and understand which one should go first and how does it resolve in the data layer.
Just like humans will need to look at the conflicts and see if it's just a migration timestamp difference, or it actually is touching the same resource. We provide agent the right context to do so as well.
@fberrez1 Yes — backend branching is fundamentally different from code branching. We've written a blog post that walks through how it actually works under the hood: https://insforge.dev/blog/behind-backend-branching
Agentic coding needs guardrails like this. Speed without isolation is risky.
@lily_liu8 Exactly. Agents can move incredibly fast, but backend state is where mistakes get expensive.
The goal is to give them a real backend to work against, while keeping production untouched until the changes are reviewed and merged.
@lily_liu8 100%
@abod_rehman Thanks Abdul! That’s exactly the safety layer we wanted agents to have.
For parallel branches, we use a three-way diff: parent at branch creation time, parent now, and branch now. If the branch and parent both changed the same object in different ways, the merge is blocked and we surface a conflict report instead of silently overwriting anything. The preview is shown before applying, so the agent or developer can resolve it on the branch and try again.
@abod_rehman we will run 3-way diff to trace diffs and conflicts. If there's any conflicts, the merge will be blocked, and we will provide context of the conflicts to your coding agent, then it will resolve it for you!
Does the PR-style diff show only schema changes, or also auth, storage, function, and config changes?
@ea_z Great question. It’s not schema-only.
The diff covers database schema changes, but also mergeable backend config like auth providers, storage bucket config, edge function definitions, email templates, realtime config, and schedules. We intentionally keep user-data rows out of auto-merge, because branch data is often test data and shouldn’t pollute production.
@ea_z we show everything! And the best part is your coding agents can help you to reivew those diffs!
@ea_z data and config changes as well! and those are considered backend changes that your agent should be aware!
@InsForge is one of the best OSS products launched on Product Hunt this year from my perspective.
S/O for this new launch, @hanghuang and team! Keep up the great work.
@fmerian thank you so much for the kind words!!!
When using Claude Code or Cursor, backend state is usually the scary part. Branching the whole backend makes the workflow feel safer.
@alexia_li Totally agree. With Claude Code or Cursor, frontend iteration is already fast, but backend changes need a safer loop.
That’s why we made the branch a full backend environment instead of just a database copy, so agents can test auth, storage, functions, and database changes without touching production.
@alexia_li this is exactly why we built backend branching XD
The PR-style review metaphor is great. I would make that the center of the demo.
@linglistack fair, next time will 100% do that (probably will update on our website)
@linglistack +1, the PR-style review is really the part that makes the workflow click. We’ll make it more visible in the demo.
Git-style branching for backend logic is a pattern that applies further than just APIs — financial model versioning has the same core problem. When running multiple scenario branches in a DCF or project finance model (base / downside / stressed), you need clean isolation so you can test an assumption without corrupting the live version. Same thing git solves for code.
I build financial modeling tools at ModeLoop (modeloop.net) and the explore-an-assumption-without-breaking-the-main-model problem comes up constantly in real deal work. Do you see demand from quant or finance teams, or is InsForge squarely targeting software infrastructure?
@samir_asadov exactly. Anywhere state matters, branching matters. We’re focused on software infrastructure first, but the same isolation-before-merge pattern definitely applies to financial models too.
@samir_asadov you can build any kind of software / app on top of InsForge, we have clients across so many different industries
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!
@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.