Deploy Mill docs
The same guides and references your agent reads — browsable here. Every page is also an MCP resource your agent can fetch or search with search_docs.
Getting started & help
Connect an MCP client to deploymill and go from nothing to a live app: authenticate, call start_project, push code, and find the URL. The first thing a new human or agent should read.
The one-page mental model: an agent-first orchestration layer over compute, database, domain, secrets, source, and object storage, driven entirely by MCP tools. What it does, what it deliberately doesn't, and how the pieces fit.
The first place to look when something goes wrong: the deploy/build failure loop, common error codes and what they mean, the health-gate and DNS gotchas, and how to escalate when the docs run out.
Stack templates
Layout, PORT contract, Dockerfile conventions, common modifications, and what NOT to do when modifying a deploymill-managed Node app scaffolded from the `node` template.
Layout, host/port contract, Dockerfile conventions, common modifications, and what NOT to do when modifying a deploymill-managed Python app scaffolded from the `python` template.
Layout, Dockerfile conventions, what the static stack supports and doesn't (no env at runtime, no DB, no runtime mutation), and how to add assets or SPA routing.
Recommended libraries & conventions
deploymill's paved road for Node apps: the libraries the template and database guide already commit to (Hono, pnpm, pg + node-pg-migrate), recommended-but-optional picks for auth/validation/TypeScript, what deploymill has no opinion on, and the `.deploymill/conventions.md` project override. Read before writing non-trivial application code.
deploymill's paved road for Python apps: the libraries the template and database guide already commit to (FastAPI + uvicorn, uv, psycopg + alembic), recommended-but-optional picks for validation/auth/concurrency, what deploymill has no opinion on, and the `.deploymill/conventions.md` project override. Read before writing non-trivial application code.
Project configuration & lifecycle
Full schema for the project config file plus the edit-file-then-reconcile workflow: domain, mounts, rollback, database, dryRun/prune flags, and what reconcile does NOT do.
When and how to give an app persistent disk: choosing a volume vs the managed database, declaring named-volume `mounts` in .deploymill/project.json and reconciling them, the write-under-mountPath rule, why volumes are per-app (no shared volumes — share via a service), how previews get their own fresh volume, and removing/renaming a volume. Read before persisting files to disk.
How PR previews are created, hostname derivation (auto-generated vs wildcard-domain-base), and the shared-prod-database gotcha. Read this before doing destructive migrations on a PR branch.
Enabling rollback via `.deploymill/project.json`, performing an image-swap rollback with `list_deployments` + `rollback`, what rollback does NOT cover (migrations, env vars, data), and when to use it vs forward-fix.
The health-endpoint contract: every web app exposes one endpoint (default /healthz) that returns 200 iff fully healthy; deploy/rollback/get_app_health and auto-rollback all key off it (200 = good, anything else = roll back). Covers the `health` block in .deploymill/project.json (path/retries/intervalMs/timeoutMs), strict vs lenient probe semantics, the N-consecutive-failure rule, the 404 fallback, the orchestrator Swarm HEALTHCHECK, and how to write real readiness checks into the handler. Read before relying on auto-rollback.
How `set_env_vars` / `list_env_vars` / `delete_env_vars` work: merge-vs-replace semantics, `${{project.X}}` template references, the redeploy-required rule, and the previews-share-prod-env consequence.
Where a project's files live and how the storage backend is modeled as a provider-neutral primitive: the file tools (push_files/get_file/list_files), the optional `source` block in .deploymill/project.json, and how a non-GitHub backend (e.g. self-hosted Gitea) would slot in without changing any tool.
How to store org-scoped secrets in the encrypted vault (`request_secret` browser hand-off — values never cross the agent) and get them into apps — `bind_secret` for one-offs or the `secrets` array in `.deploymill/project.json` + `reconcile_project` for config-as-code. Covers what encryption does and doesn't protect, the redaction guarantees, and wiring an app's Google OAuth (client id/secret + redirect URI).
Best practices for adding user accounts / login to a deploymill-managed app: the four platform facts (sessions in Postgres not on the ephemeral disk, host-pinned base URL per environment, signing/OAuth secrets through the vault, Secure cookies need HTTPS), the Node paved road (Better Auth on the managed Neon DB), the Python and hosted-IdP equivalents, and per-preview auth wiring (`${PREVIEW_URL}` base URL + OAuth redirect URIs).
How to read build/deploy logs (`source: "build"`) and runtime container stdout/stderr (`source: "runtime"`) with `get_logs` — `tail`/`grep`/`level`/`since` filtering, when to use which source, the failed-deploy debugging loop, and the runtime source's opt-in log-reader sidecar (degrades to `{ configured: false }` when absent).
Databases
Step-by-step playbook an agent follows after `reconcile_project` provisions a Postgres database for a Node/Hono app: add pg, build a pooled DB module, add a /db health route, scaffold node-pg-migrate, and run migrations at container start.
Step-by-step playbook an agent follows after `reconcile_project` provisions a Postgres database for a Python/FastAPI app: add psycopg + alembic, build a pooled DB module, add a /db health route, scaffold migrations, and run them at container start.
Object storage
Step-by-step playbook an agent follows after `reconcile_project` provisions an R2 bucket for a Node/Hono app: add @aws-sdk/client-s3, build an S3 client from the injected S3_* env vars (R2 endpoint + forcePathStyle), upload/list/serve objects, and what NOT to do (don't park blobs on a volume, don't commit credentials).
Step-by-step playbook an agent follows after `reconcile_project` provisions an R2 bucket for a Python/FastAPI app: add boto3, build an S3 client from the injected S3_* env vars (R2 endpoint + path-style addressing), upload/list/serve objects, and what NOT to do.