Getting started

The shortest path from nothing to a live, deployed app. DeployMill is driven entirely by MCP tools, so getting started means pointing an MCP client (Claude Code, Codex, opencode, or any MCP-capable agent) at the server and making a few tool calls.

1. Connect your agent

1. Create an account at the web sign-in page (OAuth needs a browser consent step). The same dashboard later lets you view and manage what your agent builds, but every capability is tool-driven first, so you never have to use it.
2. Add deploymill as an MCP server in your client, pointing at POST https://<your-host>/mcp.
3. Authenticate. Your client performs the OAuth 2.0 + PKCE flow and is issued a bearer access token. Every POST /mcp call carries Authorization: Bearer <token>. The token scopes you to your own org, so you can only see and touch your own apps.

Need client-specific setup steps? See deploymill://docs/connect-mcp-client.

Once connected, your agent can discover everything else: fetch the deploymill://guides resource for the full index of guides, or call search_docs to find one by keyword.

Want to skip straight to a live app? Hand your agent the one copy-paste prompt in deploymill://docs/onboarding-prompt. It reads the docs, ships an example app, and walks you through the core loop, no dashboard clicking required.

2. Go from idea to live app

The single highest-level tool is start_project. One call creates a GitHub repo from a starter template, provisions an app wired to that repo, deploys main, and attaches an auto-generated domain:

start_project({ name: "my-app", stack: "node" })

If any step fails it returns { ok: false, failedAt, partial } so the agent can resume by re-running start_project with the same name (the create steps are idempotent) or, once the repo exists, calling reconcile_project.

When the call seems to hang

The build is the slow part (~1–3 min), and that can outlast your MCP client's request timeout. If the call appears to hang, the deploy keeps running server-side, so just re-run with the same name or poll list_deployments.

To skip the wait entirely, pass wait: false: everything except the build is wired up synchronously and the call returns the moment the build is triggered, with deployStatus: "pending" and a deployEstimate/deployPollHint telling you when to check list_deployments.

start_project({ name: "my-app", stack: "node", wait: false })

3. Put your code in

After scaffolding, commit source with push_files. A commit no longer auto-deploys on its own. Pass the optional deploy: { applicationId } to ship it through DeployMill's health-gated deploy (with auto-rollback) in the same call, which is how you go from "scaffolded repo" to "running site":

push_files({
  repo,
  branch: "main",
  files: [...],
  message: "Build the thing",
  deploy: { applicationId },   // omit for a pure commit; call deploy() yourself later
})

Prefer a real local checkout to build and test against? Call get_clone_credentials for a short-lived authenticated clone URL.

4. Find the URL and confirm it's healthy

• list_domains({ applicationId }) returns the live URL.
• get_app({ applicationId }) returns the app's config plus a live health block (status, edge probe, image drift). It checks the health gate right now. Pass probeEdge:false for a cheap config-only read.
• If a deploy reports status: "error", call get_logs (build source) to see why.

Where to go next

• deploymill://docs/what-is-deploymill: the mental model behind the tools.
• deploymill://guides/project-config: .deploymill/project.json, the config file every other tool reconciles to.
• The per-stack guide for whatever you're building (stack-node, stack-python, stack-static).
• Add a database / object storage / custom domain / secrets: each is a field in .deploymill/project.json plus a reconcile_project call, and the relevant guide walks you through it.
• deploymill://docs/troubleshooting: when something goes wrong.