Skip to content

Run your whole monorepo
from one terminal.

curl -LsSf https://get.modmon.org/install.sh | sh

mm builds your containers, resolves environments and secrets, serves trusted local HTTPS, and deploys from a plan you review first. On Docker Compose, Podman Compose, and Docker Swarm.

mm · ~/code/acmetour
mmacmedevelopmentlocal·docker compose
no issueslive
Workspace
Health
Security
Automation
Setup
Services
0/0
running
Routes
0
of 0 services routed
Issues
0
all checks passed
HTTPS
trusted
2 hosts
Workspace2 environments
Root~/code/acme
Runs onthis machine
Configvalid
Runtimedocker compose
Engine28.1.1
Env deliveryenv-file · development-default
Environments3 · 2 remote
Needs attention
The stack is not running
u reviews and starts it

This terminal is interactive. Click it, then press3jenterl2?

Runs on
  • Docker Compose
  • Podman Compose
  • Docker Swarm
  • Linux
  • macOS
Supported features

Decide what a coding agent may do
in each environment.

mm agent setup connects Claude Code, OpenCode, Codex, or Cursor to mm's MCP server. An agent can deploy and run commands in local, restart jobs in staging, and only read status and logs in production.

  • One reviewed block sets the limits

    The agents block in .config/mm.yaml gives each environment a level and, separately, exec. It takes effect only after you trust it on your machine, and again after every edit.

  • Past the limit, the agent hands you the command

    A call outside the grant changes nothing. It returns the exact mm command, and the agent asks you to run it in your own terminal.

  • Remote hosts enforce the block themselves

    An agent connects with its own key and gets only what the deployed commit allows, whatever a checkout says.

  • Agents use the tools and never the CLI

    mm refuses to run inside a coding tool's shell, and every call that names an environment is written to the local audit journal.

.config/mm.yamltrusted
agentschange a level
  • local
  • staging
  • production
agents:
"*": view
local: { level: deploy, exec: true }
staging: operate
production: view
agent session
  • agentmm_deploy_apply plan 7c1e9a4f local
    mmapplied · api 3/3 healthy
  • agentmm_job_apply run migrate staging
    mmstarted · migrate attempt 1/1
  • agentmm_exec api -- rails db:migrate production
    mmhandoff · needs exec, you run:mm --environment production service exec api -- rails db:migrate

Everything a monorepo needs around Docker Compose.

Keep container commands, health checks, and volumes in Compose. mm adds what a monorepo needs around them, and shows you each change before it happens.

mm deploy plan

Nothing changes until you have read the plan.

Builds, deployments, and shared services each produce a plan and print its hash. Apply takes the hash of the plan you reviewed. If the config, a secret, or the target moved in between, mm stops and asks you to plan again.

How plans work
$mm deploy plan
~apiimage5d0c… → 9b1e…
~webenvAPI_URL
=workerunchanged
plan7c1e9a4f
$mm deploy apply --plan 7c1e9a4f --yes
applied
mm dev tls

Real HTTPS on your laptop.

Wildcard .test DNS and a local certificate authority your machine trusts. Every routed service gets a hostname. No hosts-file entries, no browser warnings.

https://web.acme.mm.test
  • ↗api.acme.mm.test8080
  • ↗web.acme.mm.test3000
  • Trusted by your user certificate store
Local HTTPS
mm secret

Secrets never touch the repo.

Config holds references. Values live in a separate store: local, OpenBao, or Vault. Plans include the reference and never the value.

DATABASE_URLconfigpostgres://postgres:5432/acme
SESSION_SECRETsecret••••••
LOG_LEVELlocal overridedebug
Environments and secrets
.config/mm.yaml

Your Compose files stay exactly as they are.

Image repositories, environments, secret references, and routes go in one file next to them. Commands, health checks, and volumes stay in Compose.

modules:
  backend:
    path: backend
    build:
      image: ghcr.io/acme/api
    services:
      api: { stack: app, role: http }
What goes where
mm target

From one laptop to a cluster.

The same project runs on Docker Compose, Podman Compose, or Docker Swarm across nodes. Remote hosts run a small daemon and deploy exactly what is committed.

Targets and runtimes
mm job

Jobs and schedules

Declare migrations, cleanups, and recurring work next to your services. Run, retry, and cancel them from the CLI or the terminal interface.

mm dev dashboard

A dashboard and a mailbox

A local web dashboard shows status across projects, and Mailpit catches every email your services send in development.

mm dev mounts

Live code in running containers

Development mounts map module source into running containers, with presets that keep dependencies and protected files out of the way.

Install mm with one command.

The installer fetches a verified release and puts mm on your machine. Workstation setup is a separate step that shows its plan and asks before it changes anything.

install
curl --proto '=https' --tlsv1.2 -LsSf https://get.modmon.org/install.sh | sh
mm dev setup# local trust, ingress, dashboard, Mailpit
mm# open the guided interface
--version pin a release--install-dir choose where--with-daemon also install mmd
you need

x86-64 or ARM64

  • curl or wget, and tar
  • Docker with Compose, or Podman Compose
  • systemd, for local HTTPS and the dashboard
the installer
  • Downloads the release for your platform over HTTPS.
  • Checks the archive's size and SHA-256 against the release manifest before extracting it.
  • Installs mm in ~/.local/bin. No sudo, and no toolchain to build.
  • Replaces an existing mm atomically, and refuses to downgrade unless you pass --force.