AI internal tools platform
Deploy AI-built internal tools without building the infrastructure around them
Your coding agent can write the expense tracker in an afternoon. The sign-in, the permissions, the database, the secrets and the place to run it are the part that takes weeks. Brod is that part, and your agent deploys to it directly.
Deploy this expense tracker for the finance team. Managers approve, everyone else submits.
deploy_app → expenses.acme.brod.sh (private, version 1)
Deployed at expenses.acme.brod.sh. It is private to you for now. I've asked Brod to share it with the Finance group: confirm in the link Brod shows you.
The gap between "it works on my laptop" and "the team uses it"
An internal tool built with an AI coding agent usually stalls at the same point. The app works. Then someone asks:
Where does it run, and at what address?
How do people sign in, and how do we keep everyone else out?
Who can approve, who can only look?
Where is the data, and is it backed up?
Where does the API key go, if not in the code?
What happens when the next AI edit breaks it?
Each answer is a small project: an auth provider, a hosting account, a database, a secrets store, a deploy pipeline. For a tool that ten people use, that work is out of proportion to the app itself, so the tool stays on someone's laptop or goes out with a shared password.
What Brod gives every app
Brod is a runtime for small internal web apps. Every app deployed to a workspace gets the same set of things, with no setup per app.
| Need | What Brod does |
|---|---|
| An address | Each app is served at <app>.<workspace>.brod.sh over HTTPS. Custom domains are supported. |
| Sign-in | People sign in once per workspace with an emailed link or Google. The app reads who they are with one call; it never stores passwords. |
| Access | Each app is private, open to the workspace, open to people who sign in, or public. Grants by person, group or email domain. |
| Roles | Apps declare their own roles (for example viewer, approver) and read the visitor's role on each request. |
| Data | Apps with server code get their own SQLite database, a key-value store and file storage. One app cannot read another's data. |
| Secrets | Encrypted at rest, readable by the app's server code as env.NAME, and never readable back through the API. |
| Versions | Every deploy is a numbered version. When an agent updates a live app, the new version goes to a staging address first. Rollback takes effect on the next request. |
| Logs | Deploys, access changes, refusals and, for server apps, recent requests with console output and errors, readable by the agent. |
Your agent deploys, people decide who gets in
Brod is an MCP server.
Agents connect over MCP
Claude Code, Cursor, Codex and other agents that speak MCP over HTTP connect to it and get tools such as
deploy_app,get_logs,set_secretandrollback.Scripts use the REST API
There is also a REST API for scripts.
People confirm wider access
Agents can deploy and fix apps, but they cannot quietly widen access. Sharing an app more widely, inviting someone, or deleting an app waits for a person to confirm. See the security model for the full list.
What kind of apps run on Brod
Web apps
HTML, JavaScript and CSS, or the output of a build (React, Vue, Svelte and so on, built to static files).
Optional server code
A
_worker.jsfile that answers requests and uses the database, files and secrets. Server code runs in workerd, the open-source runtime behind Cloudflare Workers.
Containers, Python, Ruby, Go or long-running processes. Server code is JavaScript (and WebAssembly). If your agent built a Flask or Django app, Brod is not the right fit today; ask it to rebuild the server side as a Worker-style fetch handler, or host it elsewhere.
Pricing
- Free plan. 10 running apps, 10 people and 250 MB of storage, with sign-in, roles, database, secrets, rollback and logs.
- Larger plans. Planned but not available yet.
- Open source. Brod is open source (AGPL-3.0) and can be self-hosted with Docker Compose.
- Details. See pricing.
Questions
Do I need to change the app my agent built?
Static front ends usually deploy as they are. Apps that need a backend use a _worker.js file with a fetch handler; your agent can write it, and it gets the database, files and secrets from Brod rather than from a separate service.
Does every app need its own login page?
No. Brod signs people in once per workspace and checks access before a request reaches the app. The app reads who the person is and their role with a single call.
Can people outside the company use an app?
Yes. Guests can be invited to a single app, or an app can be protected by a password, open to anyone with a Brod account, or public. Those choices are made per app, and when an agent asks to widen access a person has to confirm.
Is Brod a replacement for Vercel or Netlify?
No. General-purpose platforms give you full control over frameworks and infrastructure. Brod is narrower: it runs internal apps and gives them sign-in, permissions, data and secrets without setup.
Keep reading
- DeployDeploy an app from Claude Code, Cursor, Codex or any MCP client to a private address with sign-in, data and rollback. Pick your tool and follow the steps.
- SecurityHow Brod protects AI-generated internal apps: access checked before every request, private by default, human confirmation for sharing, encrypted secrets, per-app data, and what it does not protect against.
- Vibe coding to productionHow to productionize a vibe-coded internal tool: data, sign-in, secrets, versions and rollback, logs and ownership, plus the limits of running it on Brod.
- Use casesWorked examples of internal apps built with a coding agent and run on Brod: expense approval, customer lookup and inventory, with roles, data and secrets.