InsForge
The agent-native cloud infrastructure platform
1.8K followers
The agent-native cloud infrastructure platform
1.8K followers
InsForge is the agent-native alternative to AWS.
This is the 3rd launch from InsForge. View more
InsForge Backend Branching
Launching today
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.






Launch Team / Built With



InsForge
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?
@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?
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?
InsForge
@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.
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.
InsForge
@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.
Tabstack
@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.
Triforce Todos
InsForge
@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.
InsForge
@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?
InsForge
@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.
InsForge
@ea_z we show everything! And the best part is your coding agents can help you to reivew those diffs!
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