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.

Your tutorial app

New workspaces come with one already running: a tutorial app you learn on by changing it. It's a real, deployed app with a real repo — connect your agent, then ask it to edit the site, and watch your change go live. From there the tutorial walks you through previews, logs, rollback, env vars and backups against that same app.

It's free while you're learning: it doesn't use one of your app slots and doesn't draw on your included compute. That also means it isn't permanent — the page and your dashboard both show how long its free window has left. Before that window closes, either keep it (it becomes a normal app in your workspace, counting against your quota like any other) or let it be deleted. Nothing else in your workspace is affected either way.

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 })

One catch with wait: false: for a web app the domain is not attached yet. The response carries domainDeferred: true, and the url it returns is only reserved — there's no ingress route behind it until the build finishes, so it 404s. Poll list_deployments/get_app until the deploy is done, then call reconcile_project (or attach_domain) to attach the route. Skip that step and the URL keeps 404ing.

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.