InsForge Backend Branching - Git style branching for your backend
by•
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.
Replies
👏🏻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!
InsForge
@bury_huang1 thanks bary as always for being our early supporter!
InsForge
@bury_huang1 thank you Bary!
This is useful once an app has real users. Before that, everyone moves fast; after that, backend safety matters.
InsForge
@joe_0417 absolutely, that's why agents shouldn't touch production
I really suffered when i had to deal with backend problem in vibe coding until i found InsForge!! Quite useful for non-tech coders
InsForge
@barry_wang3 thank you for your support!
I like the Git-style mental model here. It makes backend changes feel reviewable instead of scary.
InsForge
@chengfeng yes, that's the goal :)
This makes AI-assisted development feel more mature. It is not only about faster code generation.
InsForge
@jocky Once agents can change backend state, the workflow needs review, isolation, and rollback, not just faster code generation.
@jiaqichen That's pretty cool! Congrats to the launch!
YouMind
Congrats on the launch!
This is such a smart way to solve the production safety issue with coding agents. Giving them an isolated backend to test changes is a huge game changer. I have a quick question: how does the system handle massive databases? If our production database is extremely large, does spinning up a new branch clone all that data, or does it use seed data instead?
InsForge
@jaredl We support both `full` and `schema-only` modes. Full copies schema + data at T0 for realistic testing; schema-only copies the schema and backend config but leaves user-data tables empty, so it’s much lighter for huge prod DBs. Then you can add seed/test data for the agent.
How deeply does this integrate with existing CI/CD pipelines? For example can a GitHub Actions workflow automatically spin up a backend branch on PR open and tear it down on merge similar to how Vercel handles preview deployments?
InsForge
@andrew_paul11 yes, that’s exactly the workflow we want to support. Today branches are available from the dashboard and CLI, so a GitHub Actions flow can script branch create / preview deploy / dry-run merge / delete. It’s not a native GitHub App yet, but the CLI already gives teams the pieces to wire it into CI/CD.
For frontend preview deployments, you’d redeploy against the branch app key, similar to how you’d point a Vercel preview at a staging backend.
InsForge
@andrew_paul11 GitHub Actions is on the way! Now is triggered manually or your agent creates the branch for you
InsForge
@andrew_paul11 this is exactly the next enhancement we are working on 👀
Impressive concept. Curious about the infrastructure side when a branch is created is it a true isolated environment or more of a logical separation? And does spinning up a branch introduce any latency for time sensitive staging workflows?
InsForge
@antonio_manuel1 it’s a true isolated backend environment. Each branch runs on its own EC2 with its own Postgres, auth config, storage, functions, realtime, and schedules, restored from the parent at create time. Create time has the restore cost, but after the branch is ready it runs on dedicated infrastructure with no live coupling to the parent.
InsForge
@antonio_manuel1 as of today, creating a branch still takes around 2 mins, but we are working on optimizing it to bring it down to instantly (~5s)
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.
Mailwarm
Congrats on your launch!! I've been following Insforge for a while, and what you guys are doing is amazing.
InsForge
@thamibenjelloun Thanks for your continuous support!! Really appreciated