Guide
From vibe coding to production
A prototype answers "does this work?". Production for an internal tool answers a different set of questions: where the data lives, who can get in, where the keys go, how you undo a bad change, and who looks after it. This guide goes through each one.
What a prototype usually lacks
"Production" here means an internal tool a team relies on every week: an expense approval flow, a stock tracker, a customer lookup. Not a public product with thousands of users.
The bar is lower than for a public product, but it is not zero, and the gaps are the same each time.
| Question | Typical prototype | What production needs |
|---|---|---|
| Data | A JSON file, local SQLite, or browser storage | A store that is not on someone's laptop and is not shared with other tools |
| Identity | No login, or a hard-coded user list | Real sign-in, roles, and a way to remove people |
| Secrets | Keys in the code or a .env that got committed | Keys stored outside the code, readable only by the server |
| Changes | Edit and refresh | A place to test, and a way back |
| Visibility | The terminal you ran it in | Logs someone can read later |
| Ownership | One person | More than one person who can change it safely |
Data
On Brod, an app with server code (a _worker.js file) gets its own storage with nothing to provision.
env.DBA SQLite database.
query,run, andbatchfor several statements in one transaction.env.KVA key-value store, values up to 128 KB.
env.FILESFile storage for uploads.
- Isolated. No app can reach another app's storage.
- Move browser and file storage. A static app with no server code gets no storage, so move anything stored in the browser or a local file to
env.DBbefore launch. Ask your agent to do it and to keep queries parameterised.
Two honest limits. Rollback restores code, not data. And Brod's published material does not describe backups of app data on brod.sh, so if the data cannot be recreated, ask before you rely on it or keep your own copy. On a self-hosted Brod, backups are the operator's job, and the docs list what to copy.
Identity
Delete any login the agent wrote.
Sign-in at the gateway
Brod signs people in at the gateway (an emailed link, or Google where set up) and checks the app's access mode before each request.
The app reads who is asking
The app reads the person and their role from
x-brod-*headers on the server orBrod.me()in the browser.Roles are enforced by the app
The app still has to enforce roles itself: Brod says who is an editor, and the code decides what an editor may do. Details are in authentication for AI-generated apps.
Secrets
Rotate any key that was in the code or the git history, then set it as a Brod secret.
- Read on the server. Server code reads it as
env.NAME. - Write-only. Values are encrypted, write-only, and cannot be read back by anyone through the API, including your agent.
- Limits. Up to 50 per app, 5 KB each.
Versions, staging and rollback
Every deploy is a version.
Numbered, kept until deleted. Old versions count toward storage.
Updates go to staging.
When an agent updates a live app, the new version goes to a staging address. You try it and publish it. Staging shares the live database, files and secrets, so test data changes with care.
Rollback is one call.
rollbackserves an earlier version on the next request. Nothing is rebuilt.Broken code does not go live.
Before a server version goes live, Brod checks it exports
fetch. If not, the deploy is refused and the live version keeps serving.
Logs
When a colleague says "it broke", your agent can read the failing request and fix it.
Activity log
Each app has an activity log of deploys, access changes and refused requests.
Request logs
Server apps also log recent requests with console output and errors, kept for 7 days.
get_logsShows the last 50 requests and can search.
Audit log
Workspace-wide events are in the audit log.
Ownership
A tool that only one person can change becomes a problem the week they are away. On Brod:
Builders share apps
The builder role is workspace-wide: any builder can manage any app in the workspace, with their own agent.
Concurrent deploys are refused, not merged
When two people's agents deploy from the same version, exactly one goes through. The other gets
409 stale_baseand a list of who changed what.A warning, not a lock
Agents get a warning for two hours after someone else touched the app.
Removal is immediate
Removing someone from the workspace removes their access to every app on their next request.
Write a short note in the project, such as a CLAUDE.md, saying where the app runs, who uses it and which roles exist. The next person's agent will read it.
Where Brod stops
Brod is built for small internal web apps. Check these before you commit to it.
- Server code is JavaScript and WebAssembly only. No Python, containers or long-running processes. A Flask or Django app needs its server side rewritten as a
fetchhandler. - No scheduled jobs, background queues, sending email from an app, or WebSockets.
- No deploy from a GitHub repository yet. Your agent deploys the files over MCP.
- No company SSO. Sign-in is an emailed link or Google. No SAML, OIDC with your own identity provider, or SCIM.
- Not for large public sites, and not a sandbox for hostile code. Brod assumes the people who deploy are trusted members of the team.
If those fit, the remaining work is in your app's own logic. The security checklist covers it step by step.
Questions
Is a vibe-coded app ever production-ready?
For an internal tool, yes, if the data, sign-in, secrets, rollback and logs are handled outside the generated code, and someone has checked the app's own role checks. The code being written by an agent matters less than what it is allowed to touch.
Does Brod write or fix the app?
No. Your coding agent writes the app. Brod runs it, and gives the agent logs and versions so it can fix it.
Can I run Brod on my own server?
Yes. Brod is open source under AGPL-3.0 and runs with Docker Compose. See the repository.
Keep reading
- Internal toolsBrod runs the internal tools your team builds with Claude Code, Cursor or Codex: private address, team sign-in, roles, database, secrets, logs and rollback, deployed by your agent.
- Secure a vibe-coded appA checklist for securing an app built with an AI coding agent: secrets, sign-in, access, roles, staging, logs, outbound hosts, and what is still left to you.
- Vibe-coded appYou vibe-coded a tool and want your team to use it. What happens when it goes online with Brod, what is safe by default, and what is still yours to check.
- AI app runtimeWhy apps written by coding agents need a different kind of runtime: one the agent can deploy to, with identity, data, secrets and versions built in. How Brod's runtime works and where it stops.