m9m
How it works

One binary, five layers.

There is no cluster, no message broker, and no external database to stand up. Everything a workflow needs — scheduling, execution, agent sandboxing, an MCP interface, and audit — lives inside the same ~30 MB Go binary.

          ┌───────────── m9m binary (~30 MB, Go) ─────────────┐
 cron  ──▶ │  Triggers ─▶ Executor ─▶ [ node · node · node ]   │ ──▶ HTTP / DB
 webhook ▶ │                 │                                 │ ──▶ Slack / S3
           │                 ├─▶ Agent sandbox (namespaces)     │
 LLM ────▶ │  MCP server ◀───┤   Claude Code · Codex · Aider    │
 (37 tools)│                 └─▶ Audit log + Git versioning     │ ──▶ Prometheus
           └───────────────────────────────────────────────────┘
1

Triggers

Cron schedules and HTTP webhooks start runs. No separate scheduler process — the binary owns its own event loop.

2

Executor

32+ built-in node types run in-process on the Go runtime — HTTP, databases, transforms, control flow. No V8, no per-node subprocess.

3

Agent sandbox

CLI nodes launch Claude Code, Codex, or Aider inside Linux namespaces with CPU, memory, and network limits.

4

MCP server

A built-in MCP server exposes 37 workflow-management tools so an LLM can list, edit, run, and debug workflows.

5

Audit & versioning

Every run is written to the audit log; every workflow edit is versioned in Git. Prometheus metrics and OpenTelemetry traces come standard.

Need help shipping agents or migrating off n8n?

Neul Labs — the team behind m9m — takes on a limited number of consulting engagements each quarter. We help teams migrate n8n workflows, build custom Go nodes, sandbox AI agents in production, and design automation platforms that don't collapse under load.