Drobek

What the Drobek MCP server does

The Drobek MCP server gives an AI coding agent a workflow for creating and hosting browser applications. An agent can create an app workspace, write its files, inspect compilation results, and publish a selected version. Drobek stores each write as an immutable version and serves successful builds from preview and published hosts.

The application runtime is browser-based. Drobek compiles and serves the submitted frontend, but it does not execute application code on the server. Backend behavior comes from platform modules rather than arbitrary app server code. Available built-in modules cover sign-in, structured data, forms, owner notifications, uploads, and controlled calls to external APIs.

How it works

Connect an agent to an instance using MCP. The hosted service exposes a Streamable HTTP endpoint at https://drobek.app/mcp and uses OAuth 2.1. A self-hosted deployment provides the same /mcp connection pattern on its own server.

A typical build cycle is:

1. The agent calls create_app to obtain a starter app and the rules for working with it.
2. It calls write_files to add or change source files.
3. Drobek compiles the submitted files with esbuild and returns errors with the write result, allowing the agent to correct them.
4. A successful build becomes available at a preview URL.
5. The agent calls publish when the owner is ready to make a version live.

The Drobek MCP server keeps preview and published applications on separate hosts. Publishing an earlier immutable version provides a rollback path. App secrets are entered by the owner in the dashboard and are used by modules on the server rather than being passed through the agent.

Setup and configuration

You can use the maintainer’s hosted instance or run the public container yourself. Self-hosting requires a Linux/amd64 server with internet-reachable ports 80 and 443, Docker Compose, a dashboard domain, a wildcard domain for app hosts, and email delivery through SMTP or Resend. A local test setup can use DOMAIN=localhost with Caddy’s internal certificate authority.

A self-hosted deployment uses the Drobek container together with Postgres and Redis; Caddy is used for TLS. DNS records for the dashboard and wildcard app domain must be prepared before certificate provisioning. The README states that there is no ARM image for version 1.

Platform modules are enabled through the deployment configuration. Operators can also create custom modules from the public module contract using the documented npm scaffolding command. Installing an agent plugin and installing a server-side module are separate operations.

Tools and capabilities

The documented MCP workflow includes these tools:

• create_app — starts an app and provides build guidance.
• write_files — writes app files, creates a version, and reports compilation results.
• publish — makes a chosen compiled version live.

The Drobek MCP server supports apps that use the built-in auth, data, forms, email, files, and proxy modules when those modules are enabled. Module behavior includes email-code sign-in, rule-based collections, protected form handling, owner notifications, uploads with quotas, and server-side secrets for external API requests.

Limitations and notes

Apps cannot rely on arbitrary backend code or per-app npm install; custom backend integrations must be implemented as platform modules. The server does not run submitted app code, so compiled output executes in the browser. The proxy module includes an SSRF guard, and its credentials are configured by an administrator rather than supplied by the agent.

Self-hosting requires the infrastructure listed above, and the released image targets Linux/amd64 only. The core project is licensed under AGPL-3.0, while the separately referenced agent plugins are MIT-licensed.