deploy

# Deploy Application Trigger a deployment for an existing Dokploy application. ## Arguments Format: `<app-name-or-id> [--project <project>]` - app-name-or-id: Application name or ID (required) - --project: Project name or ID (helps resolve app by name) Parse from "$ARGUMENTS". ## Process 1. **Resolve application:** - If argument is a UUID, use it directly. - If a name, call `project-all` to list projects, then `project-one` on the matching project (or --project) to find the application by name. 2. **Detect Docker Compose build mode:** Call `project-all` (or `project-one`) and check if the project has a compose service alongside the application. If a compose service exists, the production site likely runs from the compose service — NOT the standalone application. In this case: - Warn the user: "This project has a Docker Compose service (`<compose-name>`). The site likely runs from compose, not the standalone app. Deploy the compose service instead?" - If user confirms, deploy the **compose** service using `compose-deploy` MCP tool (or REST API fallback: `POST /api/compose.deploy` with `{"composeId": "<id>"}` and `x-api-key` header). - If `compose-deploy` MCP tool is not available, use the REST API fallback automatically. - Do NOT deploy only the standalone application when a compose service exists — this silently succeeds but leaves the site unchanged. 3. **Check current state** using MCP tool `application-one` (or `compose-one` for compose) with the ID. Report current status and last deployment. 4. **Pre-deploy checks (application mode only — skip for compose):** - **Environment variables:** MCP redacts `env` by default (since `@dokploy/mcp` 0.30.0): `env: null` still comes back as `null` and means "never set", but `[REDACTED]` means a string — possibly an empty one — so it cannot tell you whether any variable exists. In that case list the variable *names* over REST without printing values (recipe in the `mcp-patterns` skill, "Redaction"), or ask the user. Only if env is genuinely empty, read the project's local `.env.local` or `.env` file and set runtime env vars via `application-saveEnvironment` — it **replaces the whole `env` string**, so never call it to "add one variable" on an application that already has env. Separate build-time vars (e.g. `NEXT_PUBLIC_*`) from runtime-only vars — build-time vars must also go into `buildArgs`. - **Build type:** Check `buildType`. If the project has a `Dockerfile`, ask the user which build type to use (`dockerfile` or `nixpacks`). Default recommendation: `dockerfile` when a Dockerfile exists. Set via `application-saveBuildType` with all required fields (`applicationId`, `buildType`, `dockerfile`, `dockerContextPath`, `dockerBuildStage`, `herokuVersion`, `railpackVersion`). 5. **Deploy:** - **Compose mode:** Use `compose-deploy` MCP tool or REST API fallback. `compose-deploy` / `compose-redeploy` also accept `freshVolumes: true` (v0.30.5+) — it runs `docker compose down --volumes` first and **permanently deletes the stack's volumes**; use it only when the user explicitly asks for a clean slate, after a backup and an explicit confirmation (`docker-compose` type only, not swarm stacks). - **Application mode:** Use `application-deploy` MCP tool. 6. **Monitor until completion:** - Poll `deployment.all?applicationId=<id>` every 30-60 seconds to check latest deployment status. - If status is `done` — report success and verify the app is reachable (check health endpoint or domain). - If status is `error` — read the logs over MCP: build failure → `deployment-readLogs { deploymentId, tail }`; runtime crash → `application-readLogs { applicationId, tail, since, search }` or, for a compose stack, the per-container `compose-readLogs` loop (`/dokploy-dev:compose-logs`). Diagnose, fix it (update env vars, build type, Dockerfile, etc.), and redeploy. Repeat until deployment succeeds. - Show the user the build/runtime logs and errors transparently. ## Example Usage ``` /dokploy-dev:deploy web-frontend --project my-saas /dokploy-dev:deploy abc123-def456 ```