# How it fits together The five-minute map of Mimeo: your Mimeo, your manager repo, the CLI, the MCP server, git, and your sending provider — and how they talk. One Mimeo — yours — one API, four ways in. Five minutes here saves an hour of wondering which piece does what. ## The pieces **Your Mimeo** is the product itself, running as your own instance — one install, one customer, yours. It runs on your own server, on the domain you choose. Everywhere else in these docs, "Mimeo" means this. It holds your people, content, history and settings, serves the web UI, and does the sending. Your Mimeo instance is the runtime source of truth — everything that *happens* (events, sends, opens, clicks, money) lives there and only there, in your database. **Your manager repo** is a git repo on your machine holding everything you *author* — flows, segments, guards, sequences, emails, templates and settings — as plain files. It ships with the `mimeo` CLI (a single file at `bin/mimeo`), a committed `.mcp.json` that points your coding agent at your Mimeo, and agent skills for the recurring work. See [Your manager repo](https://mimeohq.com/docs/manager-repo/). **Your sending provider** (Postmark or Resend) is the delivery pipe. Mimeo writes, personalizes, schedules and tracks every email; the provider gets it into inboxes and reports delivery, bounces and complaints back by webhook. **GitHub** — or any git remote, or none — is where your repo's history lives. That's all it is: your Mimeo never reads your git repo, and git never carries a change to it.

The dashed lines are optional. The one line that never exists: **GitHub and your Mimeo are not connected.** No deploy hook, no webhook, no sync. Every change reaches your Mimeo through its API — pushed by the CLI, called by the MCP server, or clicked in the web UI. ## One API, four ways in Everything talks to the same HTTP API on your Mimeo, and the three programmatic doors take the same `mm_` API token (created under **Settings → Agents & API**): - **The web UI** — you, in a browser. Full parity with everything below. - **The HTTP API** — your app and your integrations. Mostly [POSTing events](https://mimeohq.com/docs/api/events), plus full CRUD on everything you can author. [API docs](https://mimeohq.com/docs/api/). - **The `mimeo` CLI** — syncs the manager repo's files with your Mimeo: `pull` writes what it has, `push` applies your edits through a diff, a validation and a rehearsal. It's how file changes ship. [CLI docs](https://mimeohq.com/docs/cli/). - **The MCP server** — runs on your Mimeo itself at `/mcp`, nothing to install. It's how your agent asks questions and makes one-off changes without touching files. [MCP docs](https://mimeohq.com/docs/mcp/). Because the CLI and MCP call the same services with the same validation, they can't disagree about what's valid — and anything applied by one shows up live for the other (and on any open admin page). ## Files or MCP? Not a capability question — an MCP-connected agent can do nearly everything the app can: author and activate flows, write emails, build sequences and segments, schedule broadcasts, even pull and apply the whole definition tree. The files can express all of that too, and both routes pass the same validation. The real question is what a change should leave behind. **Prefer files (the repo + CLI)** when the change deserves a paper trail: building a flow, rewriting a sequence, editing copy, changing settings. You get a reviewable diff, a rehearsal before apply, and a commit that says why. **Prefer MCP** for questions ("who's in this segment?", "how did Tuesday's broadcast do?") and for changes that don't need a commit: firing a test event, pausing a flow, forking an email, drafting something conversationally. Whatever it changes shows up on your Mimeo immediately — and in your files on the next `mimeo pull`, so the repo never falls out of the story. ## Where git fits `git pull` and `git push` move files between your machine and your remote. `mimeo pull` and `mimeo push` move definitions between your working tree and your Mimeo. They share two verbs and nothing else. Commit whenever you like, branch however you like, or skip the remote entirely — Mimeo neither knows nor cares. What the history buys you is an audit trail of every authored change, in your hands.