Brod

Category

A runtime for AI-generated business applications

Coding agents have made the app the cheap part. The expensive part is everything an app needs to be used by a team. A runtime for AI-generated apps puts that part underneath every app, and lets the agent operate it.

Deploy your first app MCP deployment

What changed

Until recently, an internal app was a project: someone scoped it, an engineer built it, and the cost of hosting, auth and a database was a small part of the total. Now a manager can describe a tool to Claude Code or Cursor and have a working version the same day. The number of small apps goes up sharply, and the cost of the infrastructure around each one becomes most of the work. Three things follow.

  • The builder is often not an engineer.

    They should not have to choose an auth provider or configure a database.

  • The deployer is often an agent.

    It needs an interface it can use directly, not a dashboard.

  • The apps are many and small.

    Per-app setup and per-app bills do not scale to dozens of tools.

What an AI app runtime provides

Brod's answer is that every app in a workspace shares one platform layer, and the app only contains its own logic.

  • The platform layer (Brod)

    Addresses and HTTPS. Sign-in and identity. Access modes, grants and roles. Database, key-value store, files. Encrypted secrets. Versions, staging, rollback. Logs for people and agents.

  • The app (your agent)

    Pages and UI. Business rules. What each role may do. Calls to outside APIs. The data model.

Operated by agents, governed by people

Brod exposes the whole lifecycle as MCP tools and a REST API. The decisions that change who can see what stay with people. See MCP deployment for the tool list.

  • The agent operates the app. The agent that wrote the app can also deploy it, read its logs when something breaks, fix it, and roll it back.
  • People confirm access changes. Widening access, inviting someone and deleting an app need a person to confirm.

How Brod runs an app

An app is a bundle of files. Static files are served as they are. If the bundle has a _worker.js, its fetch handler answers requests in workerd, the open-source runtime behind Cloudflare Workers, in its own V8 isolate.

The handler gets the app's SQLite database as env.DB, a key-value store as env.KV, file storage as env.FILES and secrets as env.NAME. Each request carries the signed-in person's identity, set by Brod's gateway.

// _worker.js: a small server for an internal app
export default {
  async fetch(request, env) {
    const email = request.headers.get('x-brod-user-email');
    const rows = await env.DB.query('SELECT * FROM requests WHERE owner = ?', [email]);
    return Response.json(rows);
  }
};

Server code is limited to JavaScript and WebAssembly. Containers and other languages are not supported, which keeps apps small, fast to start and cheap to run in large numbers.

What it is not for

  • High-traffic customer products

    Customer-facing products with heavy traffic or strict uptime requirements.

  • Other runtimes

    Apps that need Python, a container, background workers or a specific database server.

  • Full infrastructure control

    Teams that want full control of framework, region and infrastructure. General-purpose platforms are better there; see Brod and Vercel.

Your AI already built the app. Put it in your team's hands.

Deploy your first app Read the docs