What is deploymill?
deploymill is an agent-first orchestration layer 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.
It is not an infrastructure product you click around in. The MCP tool surface is the product; the web UI exists only because OAuth needs a browser.
The mental model
deploymill abstracts six provider-neutral primitives. You describe what you want; deploymill reconciles the live world to match.
| Primitive | What it gives you | Backed today by |
|---|---|---|
| Compute | A running, auto-deployed app | Dokploy |
| Database | A managed Postgres database + connection string | Neon |
| Domain | A validated custom domain with TLS | Dokploy ingress |
| Secrets | An encrypted, org-scoped vault | Dokploy-backed store |
| Source | Your repo and its files | GitHub |
| Object storage | An S3-compatible bucket for blobs | Cloudflare R2 |
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.
How the pieces fit
- Every project carries a
.deploymill/project.jsonin its repo. This fileis the contract: it declares the prod domain, named-volume mounts, rollback policy, optional managed database, object storage, and secrets.
- You edit the file and call
reconcile_project. The tool diffs yourdeclared config against the live app, shows the plan, and applies it. This is the single write path for those fields — config as code.
- 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:
- Agent-first is the actual interface. Every 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. - Provider-agnostic 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.
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 grow the web UI into a dashboard; if a capability isn't reachable
as a tool, it doesn't exist yet.
Next
deploymill://docs/getting-started— connect a client and ship your firstapp.
deploymill://guides— the full index of operational guides.