InsForge
The agent-native cloud infrastructure platform
1.9K followers
The agent-native cloud infrastructure platform
1.9K 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
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.
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.
Gro
Agentic coding needs guardrails like this. Speed without isolation is risky.
InsForge
@lily_liu8 Exactly. Agents can move incredibly fast, but backend state is where mistakes get expensive.
The goal is to give them a real backend to work against, while keeping production untouched until the changes are reviewed and merged.
InsForge
@lily_liu8 100%
This feels like a missing primitive for coding agents. Production should not be the first place an agent tests a backend change.
InsForge
@song_kirby Exactly. “Try it on production” does not make sense once agents are changing backend state.
We wanted Backend Branching to become that missing primitive: give the agent a real backend to test against, but keep production isolated until the changes are reviewed and merged.
InsForge
@song_kirby exactly! This is the future of agentic engineering