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
Best
congratulations! what inspired the decision to build a PR style review system for backend changes? was this based on customer feedback?
@joshua_martinez7 the inspiration was pretty simple: code already has PRs, but backend state usually does not. Once agents can change schema, auth, storage, and functions, we need the same “propose → review → merge” loop for the backend too.
Report
sounds very interesting! do we get merge conflict here as well? :D
@ashishkingdom Yes we do! We can branch diff so you can easily tell what did the agent do.
Report
Congratulations! This feels like a missing primitive for agentic development.
Do you plan to support protected-branch-style policies for backend changes? Especially, to stop agents from modifying RLS, auth, billing schemas, or other high-risk areas without human approval?
Feels like backend governance is the natural next layer after diffs.
Hey guys! I'm @tonychang430 , co-founder of InsForge 👋
Coding agents are getting incredibly good at building software. The problem isn't capability anymore! It's trust.
Most people still hesitate before letting an agent touch production. And honestly, they should. One bad migration, one accidental deletion, or one wrong configuration can take down critical infrastructure in seconds.
We believe the future isn't about replacing humans. It's about giving humans confidence in what agents are doing.
That's why Backend Branching is so exciting to us.
Instead of giving agents direct access to production, every change happens inside an isolated backend branch!
It is a complete clone of your backend, including your database, auth, storage, functions, and configuration.
Agents can move fast, experiment freely, and build against a real environment without putting production at risk.
Then, just like a pull request for code, humans stay in control. You can review the exact changes, approve them, reject them, or ask the agent to fix conflicts before anything reaches production.
Our vision is simple: agents should be able to move at machine speed while humans maintain visibility, control, and trust.
We're excited to hear what you think and would love any feedback from the Product Hunt community ❤️
Been working with HH and insforge team for a few months!!! Witnessing how fast the team iterate the product and launching campaigns from open source and now product hunt! congrats to your biggg milestone and many ahead!
@yan_labs_ If parent and branch both changed the same object since T0 and the result diverges, we block the merge instead of guessing. The goal is to give your coding agent the conflict context, let it fix the branch, then retry the merge safely.
Report
How do you prevent a branch from drifting too far away from main?
@mia_qiao we don’t auto-sync branches with main. A branch keeps its T0 baseline, then merge uses 3-way diff + conflict checks. If it drifts too far, reset the branch back to its create-time snapshot or recreate it.
@mia_qiao since it's backend setup we don't expect the branch from drifting too far away.
But if it does actually happen, in the future we also plan on adding a rebase functionality.
For now users or agents just discard their branch and tell the agents to create a new one from main
Report
The real unlock here is not just safety it's agent velocity. when an agent does not have to be cautious about breaking production, it moves significantly faster and takes more direct paths to solutions. that speed compounding over hundreds of tasks is the actual ROI and i think it's slightly undersold in how you are positioning this right now.
@imogen_wallace 100%. Safety is the first-order problem, but velocity is the compounding effect. When agents have a real isolated backend, they can take bolder paths without putting production at risk.
Replies
congratulations! what inspired the decision to build a PR style review system for backend changes? was this based on customer feedback?
InsForge
@joshua_martinez7 the inspiration was pretty simple: code already has PRs, but backend state usually does not. Once agents can change schema, auth, storage, and functions, we need the same “propose → review → merge” loop for the backend too.
sounds very interesting! do we get merge conflict here as well? :D
InsForge
@ashishkingdom Yes we do! We can branch diff so you can easily tell what did the agent do.
Congratulations! This feels like a missing primitive for agentic development.
Do you plan to support protected-branch-style policies for backend changes? Especially, to stop agents from modifying RLS, auth, billing schemas, or other high-risk areas without human approval?
Feels like backend governance is the natural next layer after diffs.
InsForge
@jesecamilo Thanks for your feedback! We would definitely consider that to make a safer agentic development workflow!
InsForge
Hey guys! I'm @tonychang430 , co-founder of InsForge 👋
Coding agents are getting incredibly good at building software. The problem isn't capability anymore! It's trust.
Most people still hesitate before letting an agent touch production. And honestly, they should. One bad migration, one accidental deletion, or one wrong configuration can take down critical infrastructure in seconds.
We believe the future isn't about replacing humans. It's about giving humans confidence in what agents are doing.
That's why Backend Branching is so exciting to us.
Instead of giving agents direct access to production, every change happens inside an isolated backend branch!
It is a complete clone of your backend, including your database, auth, storage, functions, and configuration.
Agents can move fast, experiment freely, and build against a real environment without putting production at risk.
Then, just like a pull request for code, humans stay in control. You can review the exact changes, approve them, reject them, or ask the agent to fix conflicts before anything reaches production.
Our vision is simple: agents should be able to move at machine speed while humans maintain visibility, control, and trust.
We're excited to hear what you think and would love any feedback from the Product Hunt community ❤️
This is super cool. Congrats!!
InsForge
@taro_f Thanks!!
this is the way of building AI-native products post AI-era!
InsForge
@dr_alaska Agreed!
Been working with HH and insforge team for a few months!!! Witnessing how fast the team iterate the product and launching campaigns from open source and now product hunt! congrats to your biggg milestone and many ahead!
Kollab
How conservative is the merge blocker when there is a potential conflict?
InsForge
@yan_labs_ If parent and branch both changed the same object since T0 and the result diverges, we block the merge instead of guessing.
The goal is to give your coding agent the conflict context, let it fix the branch, then retry the merge safely.
How do you prevent a branch from drifting too far away from main?
InsForge
@mia_qiao we don’t auto-sync branches with main. A branch keeps its T0 baseline, then merge uses 3-way diff + conflict checks. If it drifts too far, reset the branch back to its create-time snapshot or recreate it.
InsForge
@mia_qiao since it's backend setup we don't expect the branch from drifting too far away.
But if it does actually happen, in the future we also plan on adding a rebase functionality.
For now users or agents just discard their branch and tell the agents to create a new one from main
The real unlock here is not just safety it's agent velocity. when an agent does not have to be cautious about breaking production, it moves significantly faster and takes more direct paths to solutions. that speed compounding over hundreds of tasks is the actual ROI and i think it's slightly undersold in how you are positioning this right now.
InsForge
@imogen_wallace 100%. Safety is the first-order problem, but velocity is the compounding effect. When agents have a real isolated backend, they can take bolder paths without putting production at risk.