MirrorNeuron Documentation
Install, run, operate, and extend MirrorNeuron.
MirrorNeuron Documentation
MirrorNeuron is a runtime for building and operating durable, message-driven AI workflows. It supports single-machine and distributed deployments, with a CLI, REST API, local model integration, and blueprint-based execution.
MirrorNeuron makes AI workflows running locally, easy to build, simple to control, and fully yours to operate. You choose where they run, how they behave, and how your data moves.
Start Here
- Why MirrorNeuron: decide whether the runtime fits your workload and risk model.
- Quickstart: prepare, validate, submit, and inspect a local blueprint.
- Installation: install the local runtime and verify its services.
- Security Model: understand the trust boundaries before running third-party or production workloads.
Choose Your Path
| You are… | Start here | Then |
|---|---|---|
| Evaluating MirrorNeuron | Why MirrorNeuron | Core Concepts, Quickstart, Security Model |
| Running a local workflow | Installation | Quickstart, Examples, Troubleshooting |
| Authoring a blueprint | Core Concepts | Blueprint Standard, Blueprints and Skills, Testing |
| Operating a runtime | Services and Health Checks | Monitor Guide, Reliability Guide, Troubleshooting |
| Contributing | Component Guide | Runtime Architecture, Testing, Contributing |
Documentation Map
| Page | Use it when |
|---|---|
| Installation | You need the supported installer, local-development setup, or uninstall steps. |
| Quickstart | You want to validate a blueprint, start the runtime, and inspect a run. |
| Why MirrorNeuron | You are evaluating fit, boundaries, and non-guarantees. |
| Core Concepts | You need the shared workflow, blueprint, job, and runtime-node vocabulary. |
| Examples | You want to explore one of the checked-in OtterDesk blueprints. |
| CLI Reference | You need exact mn command groups and options. |
| API Reference | You are integrating with the FastAPI gateway. |
| Environment Variables | You need runtime, API, cluster, or model configuration. |
| Model Runtime | You are using Docker Model Runner or a remote model provider. |
| Services and Health Checks | You need service discovery or preflight checks. |
| Resources and Devices | You are configuring CPU, GPU, ports, volumes, or placement constraints. |
| Cluster Guide | You are starting or operating a multi-machine runtime. |
| Redis High Availability | You need Redis Sentinel failover. |
| Deployments | You need rolling, canary, promotion, rollback, or versioned long-running jobs. |
| Schedules and Events | You need cron, delayed, or event-triggered jobs. |
| Runtime Architecture | You want the control-plane and execution-plane mental model. |
| Reliability Guide | You need recovery, leases, backpressure, and retention details. |
| Blueprints and Skills | You are building or extending a blueprint safely. |
| Testing | You need the current test matrix and commands. |
| Troubleshooting | You are diagnosing local runtime, Redis, OpenShell, model, or cluster issues. |
First safe workflow
The checked-in blueprints have different hardware, model, input, and service requirements. Start with the Quickstart, which uses a review-only sample configuration and makes the model preflight explicit. Before any launch, inspect the blueprint's manifest.json, payloads, model requirements, and pass_env entries.
Use Security Model before exposing a runtime beyond your trusted local network or supplying real data.
Contributor Path
- Read Component Guide and Runtime Architecture.
- Run the relevant commands in Testing.
- Make a small focused change and update the affected reference page.
- Use the Contributing checklist before opening a pull request.