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

The PR-style diff before merge is the part that really clicks for me. Agents can experiment, humans still approve.

 Yes, that’s the core idea: let agents experiment freely, but keep the final decision human-reviewed.

The branch can carry real backend changes, and the merge preview makes those changes explicit before anything reaches production.

 yep, human-in-the-loop is the most important part

This could be even clearer if the first screenshot showed everything included in a branch: DB, auth, storage, functions, config.

 that's fair

How do you handle secrets and environment variables across branches?

 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.

 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.

We shipped many incredible features in this launch! Agentic development on InsForge is even more versatile now - with monetization, branching, and custom compute services. Come and try them out, make sure to leave your feedbacks so we can make it better!

 we will ship faster and faster :)

Congratulations for your product

 thank you so much!

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

 yes, it needs to on InsForge, because we built the branching for InsForge's primitives

Really love the concept. How does InsForge handle schema migrations across branches? If I run a migration on a feature branch and then want to merge back is there a conflict resolution mechanism or does that still live on the developer to manage?

 We run a 3-way diff across parent at T0, parent now, and branch now. If both sides changed the same schema object differently, merge is blocked with conflict context, then the developer or agent resolves it on the branch and retries.

 yes if there’s a conflict, then merge will be blocked. And yes we have conflict resolution mechanism

Curious how teams are using this today. Is the most common use case schema changes, auth config, or edge functions?

 The first use case is usually schema / RLS / migration changes, because that’s where touching prod is scariest. But the branch is the whole backend, so auth config, storage buckets, edge functions, realtime, schedules, and config changes are all part of the same workflow.

 every write operation - e.g. you are developing a new feature, or want to start a dev / staging environment

What parts of auth and storage are mergeable back to main, and what stays environment-specific?

 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.

👏🏻My team has been using insforge for almost a year now. It just works. I literally stop hiring any backend engineer. The new payment and compute feature is a killer!

 thanks bary as always for being our early supporter!

 thank you Bary!