How it fits together

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. If you're a hosted customer it lives at your-account-name.mimeoapp.com; self-hosting, it lives on whatever domain you put it on. 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.

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, plus full CRUD on everything you can author. API docs.
• 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.
• 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.

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.