InsForge Backend Branching - Git style branching for your backend

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.

Add a comment

Replies

Best

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?

 I think both. We are using InsForge to build our internal service tools as well, which helps a lot in team collaboration.

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.

 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.

I’m a bit confused on what your product does in comparison to just making another branch in your repo for your agent to work on. are they more rules or safety features for your agent

 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?

 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?

 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.

Can this work with existing apps, or does the app need to be built on InsForge from the start?

 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.

A concrete example of an agent making a risky migration safely inside a branch would be very persuasive.

  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?

 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.

I have seen too many AI coding demos stop at the frontend. This tackles the scarier backend part.

 exactly. Frontend demos are the easy part. Backend state is where mistakes get expensive, so we wanted agents to have a real backend to work on without touching production.

How does reset-to-main work if the branch has generated test data or modified storage objects?

 Reset-to-main gives the branch a clean slate from main again.
Test data generated inside the branch is discarded, and branch-side storage changes stay isolated from production. So if an agent makes a mess while experimenting, you can reset the branch and start over without touching main.