Self-hosting
What Mycel is, and whether you need it
Using the hosted product? This page is about running the kernel yourself. If you signed up at app.mycelai.dev, start with Your first deliverable.
You want to sell a service where an agent does the work — chase invoices, reply to leads, close the books, source property. You will write the interface: your brand, your forms, your chat. That part you want to own.
The decision is what sits behind it. An agent that produces text is a demo. An agent that sends the emailis a business, and the distance between the two is a pile of infrastructure you did not set out to build: a sandbox to run it in, grounding so it stops guessing, a gate so a human signs off before money moves, somewhere to keep the Stripe key that is not the agent's context window, a stream so the customer can watch, and a durable record of who approved what.
Mycel is that layer, extracted and open. You bring the judgment — how the job is actually done. It brings the machinery.
Rent the engine. Own the judgment.
The three ideas everything else follows from
If you read nothing else on this site, read these. Most of the API stops looking arbitrary once they land.
1. The gate is the product, not a setting
Actions that touch the world — send, charge, refund, file — suspend the task and wait for a human. There is no global "autonomous mode" switch to flip. A wedge can declare narrow auto-approve envelopes (this action, under this amount, this many times a day) and anything outside a declared envelope stops. No policy at all means everything stops.
That default is deliberate: the gate is what you sell. It is what lets you charge for work an unsupervised bot could not be trusted with. And when a founder edits a draft before approving, the correction is stored as grounding — so the gate is also how the system learns.
2. Credentials never enter the sandbox
The agent runs with no Stripe key, no mailbox token, no database URL. When it wants to send an email it calls a proxy endpoint with an opaque per-task nonce; the harness holds the real secret, runs the approval gate, and makes the call itself.
This is why connections are referenced rather than handed over. A prompt injection can make the agent ask to send something — which is exactly what the gate is for. It cannot exfiltrate a credential the agent never held.
One honest exception: by default the model provider key is passed into the sandbox so OpenCode can call the model directly. Set MYCEL_PROXY_MODE=1 and model calls route back through the harness with only a nonce inside. See The trust boundary.
3. The durable event log is the bus
Every step is appended to a per-task event log before anything is streamed. The log is the source of truth; the in-process emitter is only a latency optimisation. That is why a client can drop its connection, reconnect with Last-Event-ID: 42, and get an exact replay — and why there is no Redis anywhere in the stack.
Durability follows the store. With MYCEL_DATABASE_URL set the log is Postgres, and the job queue (graphile-worker) lives in the same database — one datastore, no broker. Without it, the log is an in-memory array that dies with the process.
Who this is for
- Yes — founders selling a service (bookkeeping, AR chasing, enrolment ops, property sourcing, outbound) where an agent does repeated work under supervision and you bill for the outcome.
- No — a generic production wrapper for any agent demo. Mycel assumes tasks with typed inputs and outputs, a human who signs off, and clients who own connections. If none of that is true, it will feel like ceremony.
What actually ships today
One Node process, mycel-harness, serving /v1. Wedges are folders on disk. Postgres is optional and is what makes anything durable.
| Built | Not built |
|---|---|
| Tasks, SSE with replay, approvals, edit-as-feedback | Mid-run resume — a restart fails interrupted tasks |
| Connections, action + read proxies, AES-256-GCM vault | Native Stripe / SMS / calendar — those go through Composio |
| Sandboxes: local, Docker, Daytona | local is not isolation; Daytona is the least exercised |
| Org / project tenancy, roles, per-project keys | Per-tool ACLs — the gate is the enforcement, not a tool allowlist |
| Postgres queue and workers, scheduler, cases, records, audit chain | Cancel and approval TTL are process-local across replicas |
Status: pre-alpha. The routes in kernel/harness/src/server.ts are authoritative. These pages are checked against that code, but the API still moves — do not pin production to it yet. Limitations & roadmap is the unflattering list.
How the pieces fit
┌─────────────────────┐ server proxy ┌──────────────────┐
│ Your product │ ─────────────────────► │ Mycel kernel /v1 │
│ (create-mycel-app) │ MYCEL_KERNEL_URL │ localhost:4000 │
└─────────────────────┘ + MYCEL_API_KEY └────────▲─────────┘
│
┌─────────────────────┐ member session │
│ Founder portal │ ────────────────────────────────┘
│ (approvals, tasks) │
└─────────────────────┘There is no @mycel/react package and no UI to import. The hard artifact is the /v1 contract; frontends are written — or generated — against the event stream. The kernel itself is never public: only your app and the portal reach it.
What to read next
Quickstart — boot the kernel, run one task, resolve one approval. Ten minutes, and no model key required.