InsForge
The agent-native cloud infrastructure platform
1.8K followers
The agent-native cloud infrastructure platform
1.8K 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
Congratulations to the whole team!
can developers manually edit branches alongside AI agents?or is the workflow designed primarily for agents?
InsForge
@fletcher_oliver yes, developers can work on branches manually too. The workflow is agent-native, but the branch is a real isolated backend environment, so humans can inspect, edit, test, and review alongside agents.
InsForge
@fletcher_oliver Build for agents to understand and operate! but humans have the full visibility and can do edits as well!
congrats!
quick question:can branches be shared between teammates for collaboration? or are they tied to a single user?
InsForge
@croft_benjamin today branches are managed at the project level, but we don’t have a dedicated “branch sharing” workflow yet. It’s a very natural direction though, especially for teams where multiple agents and teammates are working in parallel.
InsForge
@croft_benjamin as long as you add the teammates to the org! we can share the project and the branches!
The 3-way diff on schema and config makes sense. What stops an edge function on a branch from firing real side effects though? Solid product!
InsForge
@artstavenka1 Branch edge functions run in the branch environment, with branch-specific keys/env values. For third-party side effects, the important pattern is to use dev/test credentials or webhooks on the branch. InsForge isolates backend writes, but we still don’t want a branch function calling a real production Stripe/email/etc endpoint by accident.
What parts of auth and storage are mergeable back to main, and what stays environment-specific?
InsForge
@alstonzhuang Auth provider settings and storage bucket config are mergeable. Secrets, OAuth credentials / redirect URLs, API keys, users, sessions, and storage objects stay environment-specific. So config can move back to main, but prod credentials and real user/file data don’t get overwritten.
congrats!how long does it typically take to create a fresh backend branch?is the provisioning process instant or dependent on project size?
InsForge
@dylan_russell It depends on project size and branch mode. `schema-only` is lighter and faster; `full` mode has to restore schema + data at creation time, so large databases take longer. Once the branch is ready, it runs on its own backend infrastructure with no live coupling to prod.
InsForge
@dylan_russell it depends on project size right now but we are doing a lot of exciting updates to really speed up the process!
congrats on the launch!how does backend branching handle schema migrations that affect large production databases? is there any downtime risk during merges?
InsForge
@james_carter35 Branching lets you test the migration on an isolated backend first, then merge shows a SQL preview before touching prod. For very large tables, the same Postgres migration rules still apply: split risky changes into safe steps / backfills. Branching reduces risk, but doesn’t make heavy migrations magically zero-downtime.
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.