What is deploymill?

deploymill is the neutral, agent-safe control plane for shipping web apps. It turns the messy, multi-vendor work of "create a repo, host it, give it a database, a domain, secrets, previews, and rollback" into a single typed tool surface an AI agent can drive end to end — across provider backends you're never locked into, with the guardrails that make it safe to hand an agent production.

Two things make that more than a convenience wrapper around someone's API:

• Neutral across providers. deploymill sits above the providers it uses,

  as provider-neutral primitives with swappable backends — the tool is called reconcile_project, never dokploy_* or neon_*. You get best-of-breed pieces behind one surface and no lock-in to any of them. (A single-vendor platform can add an agent surface, but it can't be neutral about the compute it sells you — that's the line deploymill is built on.)

• Agent-safe by construction. Previews are fully isolated (copy-on-write

  database branches, fresh per-preview storage), deploys can auto-roll-back on a failed health gate, every change is a diff/plan/apply you can dry-run first, secret values never pass through the agent, and every mutating action is recorded in an audit trail. An agent can operate production without the blast radius.

It is not an infrastructure product you click around in. For deploying — the work of shipping and operating an app — the MCP tool surface is the product: every deploy capability lands as a tool first, so an agent can ship and run an app end to end without ever opening a browser. The web dashboard is a thin read/manage layer over that tool surface: it lets you sign in, watch what your agent built, and take the few human-first actions (stop/start, delete). For a deployed app it never owns a capability the tools don't already have.

The one thing that is not agent-first is running the workspace itself — managing members, roles, invites, seats, SSO, your account settings, and support. That's human work (people invite teammates and file support tickets), so it lives in the dashboard rather than the MCP tools. It's still fully programmable: account & org management is API-first, so everything there has a solid API even though it isn't an MCP tool. In short: deploying is agent-first; administering your workspace is API-first.

The mental model

deploymill abstracts six provider-neutral primitives. You describe what you want; deploymill reconciles the live world to match.

The names and shapes are deliberately provider-neutral — a tool is called reconcile_project, never dokploy_* or neon_* — so a backend can be swapped without changing how you drive it.

For exactly which third parties back the default managed stack and what data each one receives, see deploymill://docs/subprocessors — the subprocessor / data-flow inventory.

How the pieces fit

1. Every project carries a .deploymill/project.json in its repo. This file

   is the contract: it declares the prod domain, named-volume mounts, rollback policy, optional managed database, object storage, and secrets.

2. You edit the file and call reconcile_project. The tool diffs your

   declared config against the live app, shows the plan, and applies it. This is the single write path for those fields — config as code.

3. Day-2 primitives handle the rest: deploy, rollback, create_preview,

   set_env_vars, bind_secret, get_logs, and friends.

Two design commitments

Everything deploymill does holds to two principles — together they're why it's a control plane you can stand on, not a wrapper you'll outgrow:

• Agent-safe, agent-first interface for deploying. Every deploy-lifecycle

  capability is an MCP tool with typed, structured output and machine-readable error codes. Multi-step workflows return { ok: false, failedAt, partial } so an agent can recover by re-calling the failed primitive — never an opaque failure, never a "go click something in a dashboard" dead end to ship an app. And the guardrails (isolated previews, auto-rollback, dry-runnable plans, the audit trail, the secret hand-off the agent never sees) make it safe to let an agent operate production. Workspace administration (members, roles, SSO, account, support) sits outside this — it's API-first, not agent-first: driven by humans in the dashboard, but with a solid API behind everything.

• Provider-neutral abstraction. The six primitives are modeled as neutral

  interfaces with swappable backends, so the tool you call today keeps working if the backend changes underneath it — and you're never locked into any single provider.

What deploymill deliberately doesn't do

• It is not a "pick your cloud" wizard — the default stack is the product.
• It does not pass commands through to flyctl / wrangler / raw provider CLIs.
• It does not let the dashboard own a deploy capability the tools don't have;

  every new deploy capability lands as an MCP tool first, and the dashboard is a read/manage view on top. If a way to ship or operate an app isn't reachable as a tool, it doesn't exist yet. (Account & org management is the deliberate exception — it's human work, so it's API-first rather than agent-first.)

Next

• deploymill://docs/getting-started — connect a client and ship your first

  app.

• deploymill://guides — the full index of operational guides.