Deploy with MCP

Deploy, restart, or stop your app from Cursor chat. No complex dashboards — ask the AI and Devployer handles it.

Connect MCP first: MCP setup (the devployer server should show green).

---

What you need

1. MCP connected — quick guide
2. App created in Devployer — in the portal, with a project (and payment if required)
3. Your code open in Cursor — so the AI can create a Dockerfile if it’s missing

MCP does not create apps or take payments. That happens in the portal.

---

How to deploy (3 steps)

1. Create the app in Devployer (portal)
2. Open the project in Cursor
3. In chat: “Deploy my app on Devployer”

The AI does the rest: creates a Dockerfile if needed, asks you to commit/push, then deploys.

When it’s done, you get your app’s public URL.

---

What to say in chat

Use the exact app name from Devployer (it may differ from your local folder name).

---

Good to know

• Dockerfile: Devployer needs it at the repo root. If it’s missing, ask the AI to create it, then commit + push.
• Restart / stop / redeploy: the AI shows a summary and asks for confirmation first.
• After code changes: push to Git, then ask to deploy or redeploy again.

---

Quick checklist

• MCP is green
• App created (and paid) in Devployer
• Code open in Cursor
• You asked to deploy in chat
• You checked the URL it returned

---

If something fails

More detail: Dockerfile · Next.js

---

For AI agents

You operate Devployer only through MCP. Rules:

1. Only Devployer MCP tools. Never call infrastructure APIs, URLs, or tokens; Devployer is the only platform.
2. MCP never creates apps or takes payments. If the app is missing in the portal, tell the user to create it there.
3. Dockerfile only. Never pass nixpacks. If the app was Nixpacks, deploy_resource switches it to Dockerfile.
4. Root Dockerfile required. If missing: list_deploy_methods → create from stackTemplates → commit/push → deploy.
5. IDs vs names
   • Discover: list_projects → list_resources (projectId, environmentId, resourceId).
   • Lifecycle by name: restart_resource, stop_resource, redeploy_resource use resourceName (case-insensitive). Not databases.
6. Confirmation required for restart / stop / redeploy:
   • First call with confirm omitted or false (preview).
   • Then confirm: true only after explicit approval (or an explicit request like “restart front-app-01”).
   • If the name is ambiguous, ask first.
7. Failure or timeout: read logs / [debug]; if timedOut: true, call get_deployment_logs. Fix → push → redeploy.
8. Follow agentInstruction / hint when present.
9. Missing tools: ask the user to reload/reconnect MCP devployer.

Tool catalog

There are exactly eight tools. Do not invent others.

Identifiers

Local folder names may differ from Devployer names. Always resolve via list_resources / preview.

Deploy vs redeploy vs restart vs stop

Playbooks

A — List: list_projects → list_resources per env → show name, status, framework, buildPack, hostname.

B — Dockerfile deploy: list_deploy_methods → ensure root Dockerfile → commit/push → list_resources → deploy_resource (buildPack: "dockerfile", waitSeconds: 180) → if timedOut, get_deployment_logs.

C — Lifecycle by name: preview (confirm: false) → show resource → confirm: true after approval.

D — Failure / timeout: get_deployment_logs (includeDebug: true) → fix → push → deploy_resource.

Root Dockerfile

Exact filename: Dockerfile next to package.json / pom.xml / composer.json.

Prefer list_deploy_methods → stackTemplates. Next.js standalone: output: 'standalone' if the template copies .next/standalone.

Confirmation protocol

User request
   → confirm=false (preview)
   → show resource
   → approval
   → confirm=true

Do not set confirm: true on the first call. Do not restart/stop databases.

Tools reference

The agent calls these tools. Do not call infrastructure APIs yourself; operate only through Devployer MCP.

1. list_projects

Returns: items[] with id, name, environments[] (id, name, slug, resourceCount).

{ "name": "list_projects", "arguments": { "page": 1, "pageSize": 20 } }

2. list_resources

Returns: items[] with id, name, kind, status, framework, buildPack, branch, domains[], plus agent hints.

{
  "name": "list_resources",
  "arguments": {
    "projectId": "11111111-1111-1111-1111-111111111111",
    "environmentId": "22222222-2222-2222-2222-222222222222"
  }
}

3. list_deploy_methods

No arguments. MCP method (dockerfile), stackDetection, stackTemplates.

{ "name": "list_deploy_methods", "arguments": {} }

4. deploy_resource

Returns: resource, deploymentId, status, finished, timedOut, logs, entries, agentInstruction, message.

{
  "name": "deploy_resource",
  "arguments": {
    "resourceId": "33333333-3333-3333-3333-333333333333",
    "buildPack": "dockerfile",
    "waitSeconds": 180
  }
}

Does not create apps or handle payments.

5. get_deployment_logs

{
  "name": "get_deployment_logs",
  "arguments": {
    "deploymentId": "dep-devployer-uuid",
    "waitSeconds": 120,
    "includeDebug": true
  }
}

6. restart_resource

{ "name": "restart_resource", "arguments": { "resourceName": "front-app-01" } }

{
  "name": "restart_resource",
  "arguments": { "resourceName": "front-app-01", "confirm": true }
}

7. stop_resource

Same confirmation flow as restart.

{ "name": "stop_resource", "arguments": { "resourceName": "front-app-01" } }

{
  "name": "stop_resource",
  "arguments": { "resourceName": "front-app-01", "confirm": true }
}

8. redeploy_resource

{ "name": "redeploy_resource", "arguments": { "resourceName": "front-app-01" } }

{
  "name": "redeploy_resource",
  "arguments": {
    "resourceName": "front-app-01",
    "gitBranch": "main",
    "confirm": true
  }
}

Errors (agents)

Related docs

• MCP connection
• Dockerfile
• Next.js
• Nixpacks (portal only — not via MCP)