Deploy any AI-built app
Whichever tool wrote it, an AI-generated app reaches your team the same way on Brod: the agent sends the files over MCP, Brod gives back a private address, and you decide who can open it. This page covers what the app has to look like and what happens after it is deployed.
Brod runs two kinds of app. Many AI-built tools are already one of them, and the rest usually need a small change.
| Part | What Brod expects |
|---|---|
| Front end | Any bundle of files: HTML, CSS, JavaScript, images, or the output folder of a React, Vue, Svelte or Astro build. Each file is served as it is. |
| Server code (optional) | A _worker.js ES module at the top of the bundle, or a _worker/ folder with an index.js. It exports default { async fetch(request, env, ctx) }. This is the Cloudflare Pages layout. |
| Languages | JavaScript and WebAssembly. Server code is never served to visitors. |
| Data | Server code gets env.DB (the app's own SQLite database), env.KV (key-value) and env.FILES (file storage). No app can reach another app's storage. |
| Sign-in | Brod signs people in. Server code reads the person from the x-brod-user-email and x-brod-role headers; the browser calls Brod.me() from /_brod/client.js. The app should not have its own login page or user table. |
A static app has no database. If the app needs to save anything, it needs server code.
Files sent inline with deploy_app: 1 MB in all. Bigger builds go through a one-time upload address, up to 25 MB compressed.
60 MB and 2,000 files. One file: 10 MB.
30 an hour per workspace.
Coding agents default to an Express or Python backend with its own login. Paste this into the project's instructions file (CLAUDE.md, .cursor/rules, AGENTS.md) before asking for the app.
The last line matters. Brod tells the app each person's role (by default owner, editor or viewer), but it is the app's server code that has to refuse a viewer who tries to change data.
This app will run on Brod.
- Front end: static files (a build output folder is fine).
- Back end: one _worker.js exporting fetch(request, env). No Express, no long-running server.
- Data: env.DB (SQLite: query/run/batch), env.KV, env.FILES. Secrets: env.NAME.
- The signed-in user arrives in x-brod-user-email and x-brod-role headers. Do not build a login.
- Brod passes the role; the server code decides what each role may change.Follow the page for Claude Code, Cursor or Codex, or point any MCP client at https://brod.sh/mcp.
The agent builds locally if needed, then calls deploy_app and gets back the address.
Before a version goes live, Brod loads _worker.js and checks it exports fetch. If it does not, the deploy is refused and the version already live keeps serving.
Only you and the workspace admins can open it until you share it.
Once an app is live, an agent's next deploy goes to a staging address by default. The live app stays as it is.
The staging address looks like expense-approvals--staging.acme.brod.sh. You open staging, try the change, and ask the agent to publish it (publish_staging) or discard it.
Staging uses the same database, files and secrets as the live app. What you change while testing is real, so be careful with test data and with changes that rewrite tables.
Every deploy is a numbered version. rollback serves an earlier one from the next request, with nothing rebuilt. It restores the code, not the data.
If two people's agents work on the same app, each deploy passes the version its files started from. If the app has moved on since, the deploy is refused rather than merged, so nobody silently undoes someone else's change.
Brod checks access before the request reaches the app.
private (the default), people (named people, groups or email domains), workspace, password, signed_in (anyone with a Brod account) and public.
Someone who is not allowed in gets the same "App not found" page as an address with no app behind it.
An agent can narrow access straight away. Widening it, or inviting someone, returns a link that a person has to open and confirm within 24 hours.
On brod.sh, a new free workspace cannot use password, signed_in or public for its first 24 hours; sharing inside the workspace works from the start.
API keys go in with set_secret, not in the code.
env.NAME from the next request.get_files never includes them.For a small internal tool, porting a backend to one fetch handler is usually a short job for the agent that wrote it. See how Brod runs an app for the details.
No. Your coding agent writes the app. Brod runs it and gives it sign-in, storage, secrets and versions.
A static export will, as plain files. A Next.js server will not, because Brod does not run Node.js servers. Ask the agent to export the front end and move any server routes into _worker.js.
Yes, with fetch from the server code. List the hosts in the app's brod.json under network (up to 30). Each app's Network tab shows hosts it reached that were not listed.
Yes. A person can deploy from the dashboard, and scripts can use the REST API with a token. A dashboard deploy goes live directly rather than to staging.