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



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.
How does reset-to-main work if the branch has generated test data or modified storage objects?
InsForge
@nicole_h94 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.
How do you handle secrets and environment variables across branches?
InsForge
@xiao_zhang9 We treat secrets and environment-specific values very conservatively.
A branch gets its own environment, and values like API keys are regenerated so requests don’t accidentally point at the wrong backend. During merge, env-specific fields such as API keys, OAuth client secrets, redirect URLs, and similar config are excluded from being pushed back to production. So the branch can be realistic for testing, but it can’t accidentally overwrite prod secrets.
InsForge
@xiao_zhang9 we will create entire new env variables, and encrypted, then send to your coding agent. So your coding agent will switch to the dev branch automatically.