Your agent wrote the app. Here's what drobek actually runs.

An agent can produce a working React app and a very optimistic explanation of why it is ready for production. I still want to know where its code will run, what it can access, and what happens when the next edit breaks the build.

Those questions shaped drobek. I introduced it here: a place to host small apps built by your own coding agent. The build and deployment flow is worth a closer look.

drobek compiles and serves the app's frontend. The app's JavaScript runs in the browser. Backend work goes through platform modules installed by the server operator.

A write includes the build result

The agent connects over MCP and calls create_app. It gets a starter, an app ID, a preview URL, and a briefing describing the environment. It can ask skill_info for the current module contracts instead of guessing an SDK from an old example.

The next step is write_files. The call contains changed text files and a short reason for the edit. drobek applies those changes to the latest version and compiles the result in-process with esbuild.

The response includes compile.ok and compiler errors with file, line, column, and message. The agent can make its next correction from that response. It doesn't need a separate terminal session to discover that an import failed.

A failed compile is still stored as a version. The preview keeps serving the last version that compiled successfully. The broken source isn't lost, and the agent can fix it with another write.

This is the documented flow, rather than a transcript from a particular run:

create_app
    -> app ID, starter, briefing, preview URL
write_files
    -> numbered version, compile result
    -> on failure: fix the source and write again
    -> on success: inspect the preview
publish
    -> chosen compiled version becomes production

The agent contract describes the tools and their return values.

Preview and production have different jobs

App hosts look like this:

<slug>.<APPS_DOMAIN>             production
<slug>--preview.<APPS_DOMAIN>    latest successful build
<slug>--v<N>.<APPS_DOMAIN>       a specific version

Publishing moves a pointer to a compiled version. Publishing an older version rolls production back. restore_version does something slightly different: it creates a new working version from older files. It doesn't rewrite history or publish that result automatically.

I want that distinction to stay visible. An agent can keep editing while the production URL serves the version people have already checked.

But preview is not an isolated staging environment. Preview and production share the app's backend data. If you test a delete operation in preview, changing the production code pointer later will not bring the record back. Use separate test data or a separate app for that kind of experiment.

Backend behavior comes from modules

The built-in modules cover authentication, records, forms, email, files, and API proxying. The frontend imports the browser SDK:

import { drobek } from 'drobek';

const todos = await drobek.data.collection('todos').list();

That import resolves to drobek's SDK. You don't install a separate package into each hosted app.

The collection's server-side configuration controls access. For example, this configuration lets signed-in users create records, then read and modify their own records. App admins can work across those records:

{
  "collections": {
    "todos": {
      "rules": {
        "read": "owner|admin",
        "create": "user",
        "update": "owner|admin",
        "delete": "owner|admin"
      }
    }
  }
}

Here, owner means the record's owner. It does not mean every person who can edit the app in the dashboard. App-user authentication and dashboard workspace roles are separate concerns.

The module checks these rules when a request reaches the backend. A frontend that forgets to hide a button doesn't grant permission. Broader access changes can require owner confirmation through the dashboard. The module documentation lists those cases.

Keys don't belong in the agent's output

For an external API, the workspace administrator registers an upstream. Its secret goes into the dashboard, and the proxy uses it server-side. MCP can report whether a secret is present without returning its value.

Each app also has its own origin, separate from the dashboard. These are useful boundaries, but they don't make an arbitrary generated frontend trustworthy. It can still have bugs, render misleading information, or make requests allowed by an overly broad configuration.

The modules themselves are trusted server code. Installing a third-party module is an operator decision, not something an app's agent can do by writing frontend files.

What this leaves out

drobek isn't intended for arbitrary server applications, per-app background workers, or a private dependency installation for every app. If your app needs those, this hosting model may not fit.

For the smaller tools my colleagues build, I want a workflow where the agent gets useful build feedback, the person gets a preview, and publishing selects a version we have actually looked at. You can inspect the implementation in the architecture guide and source.