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
@hanghuang The “one wrong migration and your database is gone” line made my stomach drop in recognition.
I once let an agent run a schema change on what I thought was a staging DB, only to realize 30 seconds later it had been pointed at prod the whole time. The silence while waiting to see if the rollback worked was the longest 30 seconds of my career.
Backend branching isn’t just a safety feature; it’s the psychological permission slip teams need to actually trust agents with real infrastructure.
InsForge
@hanghuang @diana_nadim2 Exactly, I share the same pain! That's why build this agent-safe development flow in the first place.
Really exciting direction. Is there any plan to offer a self hosted or open core version of InsForge? For companies with strict data residency requirements a fully managed cloud solution might be a blocker curious if that's on your radar.
InsForge
@emilia_novak yes! InsForge is open-source and self-hostable, and Backend Branching is rolling out on InsForge OSS 2.1.0+. So teams with data residency requirements don’t have to rely only on managed cloud.
One thing I've noticed with AI-assisted development is that experimentation has become much cheaper, but merging those experiments back into a production codebase is often where things get messy.
Are teams using InForge primarily to speed up individual developer workflows, or are you seeing it change how teams collaborate on larger feature development as well?
InsForge
@samyak_sanklecha I think both. We are using InsForge to build our internal service tools as well, which helps a lot in team collaboration.
Polyvia
Git-style branching for your backend: Backend branching for agents is a really clean safety primitive. When an agent works in an isolated branch, how do you give it enough context about the production state to make good migration decisions without exposing prod itself? Curious how you balance isolation vs. context — it's the exact tension we wrestle with on the agent-memory side.
InsForge
@mateusz_gierlach Context layer is something we've been continously building. Once connected to an insforge project, the agent would automatically gain all the context it needs to understand the project.
InsForge
@matthias_bettin A repo branch only branches code.
Backend Branching gives the agent a separate backend environment too: Postgres, auth, storage, edge functions, realtime, schedules, and config. So the agent can test real backend changes without touching production, then you get a PR-style diff before merging those backend changes back.
Can agents create a branch per task, or is this designed more for manual branch creation?
InsForge
@kris_liu2 Both, but branch-per-task is the intended agent workflow. You can create branches manually, but the better flow is: the agent creates a branch for a task, builds against a real isolated backend, then starts the merge flow when it is done. Production stays untouched until review.
Is there a dry-run step before merge so developers can see exactly what SQL or config changes will apply?
InsForge
@kris_l3 Yes. Merge is not applied blindly. Before it goes to main, we show a PR-style diff / merge preview so developers can review the schema and mergeable config changes first. If there is a conflict, the merge is blocked.
LobeHub
Can this work with existing apps, or does the app need to be built on InsForge from the start?
InsForge
@rika_lee1 It doesn’t have to be a brand-new app, but the backend you want to branch needs to be on InsForge.
An existing frontend can point to an InsForge backend / branch. The branching layer is for backend state, not for replacing the whole app.
LobeHub
A concrete example of an agent making a risky migration safely inside a branch would be very persuasive.
InsForge
@thechaos A good example is schema + RLS + edge function changes. The agent can run the risky migration inside a backend branch, test against real backend APIs, then show a PR-style diff before anything touches prod.
How do you represent auth-provider changes in the diff?
InsForge
@jackiesong We represent auth-provider changes as config diffs in the merge preview.
Mergeable auth config can be reviewed before merge, while environment-specific values like OAuth secrets / API keys stay separate and are not blindly pushed to prod.