Agent App Builders

Ship a backend per user the moment the agent generates one, on Rivet Actors.

When your product’s output is an app, the backend has to appear the moment the agent writes it — one per user, isolated from every other user, live enough to click on in the same chat turn. Rivet gives each generated app its own Actor and its own persistence, so provisioning is a key lookup rather than a deploy pipeline.

Two shapes, depending on whose code it is

Run the generated code in place. A code agent Actor keeps the chat history and the current revision of the generated source in its own SQLite database, so every key has an isolated transcript and an isolated codebase. A dynamic Actor fetches that source from the matching code agent and executes it in a Secure Exec sandbox, so the user can call their app the moment it compiles and iterate on it without a redeploy.

Deploy it into its own namespace. For code that should outlive the chat, create a Rivet namespace per user, package the generated registry.ts and frontend into a project, deploy it to a serverless host such as Freestyle, and configure that host as the namespace’s worker. Each user’s Actors then run under their own credentials, in their own namespace, with nothing shared but the control plane.

Start from the examples

Next steps

• Dynamic Apps — the managed version of this pattern: deploy a generated app and backend per user, with SQLite, workflows, and multiplayer built in.
• Actor Keys — how one key per user becomes one backend per user.
• Deploy — Rivet Cloud, your own cloud, or self-hosted.