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
Congrats on the launch! Can you plz tell how does the semantic layer handle it when the agent makes a wrong assumption about the schema? does it self correct or does it need manual intervention?
InsForge
@munis_abbas We don’t rely on the system “guessing” the right schema semantics. The branch gives the agent a safe backend to try the change, then merge uses structured diff + conflict checks. If the agent made a wrong assumption, you can review the diff, let the agent fix it on the branch, or reset the branch back to T0 and retry.
Congrats on the launch! Curious how InsForge handles multi tenant architectures where data is logically separated within a single database rather than across separate instances. Does branching still work cleanly in that model or is it optimized for single tenant setups?
InsForge
@diego_joaquin1 Branching works at the backend/project level, so it also works for multi-tenant apps where tenants live inside one database.
In `full` mode, the branch gets the parent schema + data at T0. In `schema-only`, user-data tables are empty, which is often better if tenant data is sensitive. On merge, schema/config changes can go back, but tenant data rows are not auto-merged into prod.
Smart product. One thing I'm wondering when branching a backend with large storage volumes does InsForge use copy on write semantics to avoid duplicating unchanged data? Or is each branch a full physical copy? That distinction could be a big deal for storage heavy apps.
InsForge
@ding_hao For storage objects, we intentionally don’t copy all objects at branch creation. Existing parent files are readable from the branch, while new branch writes stay isolated. For the database, `full` mode copies schema + data at T0; `schema-only` is the lighter path for large projects.
This is exactly what agent driven development needs. For teams in regulated industries fintech, healthtech is there an audit log of every action taken within a branch? Being able to trace exactly what an agent did in an isolated environment would be critical for compliance sign-off.
InsForge
@dominic_cruz Totally agree! auditability matters a lot for regulated teams. Today the merge flow gives a structured diff and conflict context before changes reach production. I wouldn’t overclaim it as a full compliance-grade per-agent audit trail yet, but branch-level visibility and accountability are definitely core to where this should go.
Love the concept. Once a branch is running what does observability look like? Can I pipe branch level logs, query traces and error events into my existing monitoring stack Datadog, Grafana, etc. or does InsForge have its own builtin observability layer?
InsForge
@elena_fischer1 Today InsForge has built-in logs / diagnostics that agents can read, and a branch runs as its own backend environment.
Native branch-level export into Datadog/Grafana isn’t something I’d claim as built-in yet, but it’s a very natural direction for teams that want branch observability inside their existing monitoring stack.
Really impressive. If two feature branches both modify the same table schema independently and then try to promote to production how does InsForge detect and surface those conflicts? Is there a diff view or a merge review step built into the workflow?
InsForge
@elijah_smith6 yes, there’s a merge review step. We run a 3-way diff: parent at branch creation, parent now, and branch now. If two branches both changed the same table schema differently, the later merge will be blocked with a conflict report instead of silently applying. The diff shows which table / policy / function / config object diverged and why.
Congrats on shipping! What's the typical spin up time for a new backend branch in practice? If it takes several minutes it might interrupt fast iteration loops. If it's under 30 seconds it becomes genuinely seamless. Would love a real world benchmark.
InsForge
@elsa_williams It depends on project size and branch mode. `schema-only` is much faster; `full` mode restores schema + data at creation time, so large databases naturally take longer. I don’t want to give a fake universal benchmark here, but the tradeoff is exactly why both modes exist.