Skip to main content
Monk is the operations agent for your app, and you use it from your coding agent. Your coding agent reads and writes code. Monk plans, provisions, deploys and keeps track of what is running. The resources run in your own cloud account.

​
The pieces

  • The plugin or MCP entry. The installer adds it to each coding agent it finds. See Supported agents.
  • The local companion (monk-agent). A small server on your computer. It exposes Monk’s tools to your coding agent over MCP. It also serves the local dashboard, where you review plans, approve changes and enter credentials.
  • The orchestrator (monkd). It runs your workloads, on your machine in local mode or on the nodes of a cluster in your cloud account. It keeps the state of what it manages.
  • Your cloud account. Machines, managed databases and other resources are created there, and your provider bills you for them directly.

​
Who writes what

Monk does not edit your application code. When code has to change before something will deploy, your coding agent makes that change, in the same way it makes any other code change.

​
The loop

1

Analyze

Monk checks whether the project already has a MANIFEST. If it doesn’t, your coding agent reads the repository to work out the services, their connections and the configuration they need.
2

Configure

Your coding agent writes the MANIFEST, the templates and any missing Dockerfiles. Before it writes services such as PostgreSQL or Redis by hand, it looks for an existing Monk package. Monk’s analyzer checks the result.
3

Plan

Monk works out what a deploy would change: the workloads, any warnings and the cost impact. Nothing is built or created at this step.
4

Approve

The plan opens in the local dashboard. If credentials or secrets are missing, Monk asks for them there through a form. Nothing is created until you approve.
5

Deploy

Monk builds the images and starts the workloads, either locally or on the cluster. It then checks their status and readiness.
To start, ask:
The two starting paths, a new app and an app that’s already running, both follow this loop. For a running app, Monk builds new infrastructure from source alongside the original and leaves the original alone.

​
The model Monk keeps

The orchestrator keeps a record of the workloads, entities, connections and cluster nodes it manages. That record doesn’t depend on your chat history, so a new session can read the app’s current state and status without being told how it was deployed. The deploy review in the local dashboard draws the planned app from the same model. You can ask about it at any time:

​
Approvals and limits

Monk’s tools check every request and the permissions behind it before acting. Actions that create, change or delete infrastructure ask for your approval in the local dashboard. Security describes what Monk’s tools can and can’t do, and what your coding agent can do on its own.

Talking to Monk

How to phrase requests and what Monk asks back

Deployments

MANIFEST, plans, redeploys and rollbacks

Security

Credentials, approvals and what each tool can do

Local dashboard

Where you review and approve