MIKE vs Omnara: Two Ways to Self-Host a Durable Agent Harness
Durability is not the same design choice in these two self-hosted agent harnesses. In Omnara, the unit is “one durable conversation”: its state is externalised across Postgres, Redis, an S3-compatible bucket and a shared memory filesystem, with a per-machine daemon installed from the API origin at /install/omnarad.sh and a one-shot migration job that must precede the services. In MIKE, the unit is a kanban card representing a task; documented durability mechanisms include Git worktrees, gVisor sandboxes via rootless Podman, retries, RAM-aware pause/resume and recoverable failures.
That distinction matters more than a feature-count comparison. Omnara documents where key persistent state lives and how its services depend on it. MIKE documents a task-oriented workflow and isolation model, but the available sources do not establish where its durable state is stored. This is an engineering comparison of what the documentation and probes establish—not a claim that either system performs better in practice.
Omnara describes an agent as a conversation with its configuration, tool calls and history, and its self-hosting guide specifies the supporting services (Introduction, self-hosting deployment). MIKE describes each kanban card as a task and documents task workspaces built with Git worktrees and sandboxes (MIKE README, MIKE landing page). The comparison below keeps that difference in view rather than treating “durable” as a single implementation property.
Where durability lives
Omnara: persist the conversation and its supporting state
Omnara’s object model runs from organization to projects to agents. The agent is “one durable conversation with its config, tool calls, and history”; reusable configurations are Profiles. Projects and explicit grants scope access to resources, while machines can be computers connected by the operator or pools of ephemeral sandboxes (concepts).
For self-hosting, the deployment guide describes four long-lived services plus a one-shot migration job, connected to the operator’s Postgres, Redis, S3-compatible bucket and persistent memory filesystem, with one public URL in front. Memory lives at /var/lib/omnara/memory. Across hosts, the same shared filesystem must be mounted into the API, every worker and maintenance, with OMNARA_MEMORY_DIR set. The guide’s backup instruction is direct: “Back up the entire memory directory alongside PostgreSQL.”
That makes Omnara’s durability story concrete, but distributed across components. A durable conversation depends not only on the application services but also on correctly configured external storage, shared filesystem visibility and migration order. The documentation calls for verifying shared locking and file visibility between hosts and keeping the mount private to API, workers and maintenance. These are operational requirements, not incidental deployment details.
Omnara also documents an agent loop on connected machines or ephemeral sandbox pools, driven through a web interface, CLI and REST API. The self-hosted API serves under /api/v1, and the OpenAPI spec is available at GET /api/openapi.yaml (API overview). This is a conversation-centred API model: the persistence boundary is described in terms of conversation state plus its backing services.
MIKE: persist work as cards and recoverable execution
MIKE frames work as a kanban: each card represents a different task. The documented workspace combines Git worktrees with sandboxes and a read-only repository mount. Agent activity runs inside gVisor-isolated containers via rootless Podman; custom extensions may be fenced in with gVisor, iframe and/or WASM sandboxes (README, project site).
The durability emphasis in the available material is therefore on task execution and recovery: worktrees for task workspaces, retries, RAM-aware pause/resume and recovery from failed tool calls, loops, crashes and rate limits. But the sources do not specify MIKE’s durable-state location, database or queue. A card-based work unit does not, by itself, establish what survives a host failure or how that state is backed up. Those questions remain unverified here.
MIKE supports inference from llama.cpp and providers exposing the OpenAI Chat Completions API. It presents a Progressive Web App for high-latency or offline use, but the available evidence does not establish broader offline guarantees. Its README says: “The API and Extension surfaces are still being solidified. No stable API/Extension interfaces will be guaranteeed until version 1.0.” That matters to teams treating integrations as part of their long-lived harness contract.
Head-to-head: documented boundaries, not inferred parity
| Criterion | MIKE | Omnara | Verdict |
|---|---|---|---|
| Unit of work | Kanban card represents a task | “One durable conversation” with config, tool calls and history | Different durability units; choose based on whether work is organised around tasks or conversations |
| Durable-state location | Not stated in the available sources | Postgres, Redis, S3-compatible bucket and /var/lib/omnara/memory shared filesystem |
Not comparable — unverified for MIKE’s durable-state location |
| Workspace and execution | Git worktrees, read-only repository mount, gVisor containers via rootless Podman | Connected machines or pools of ephemeral sandboxes | Different documented execution models; no security ranking established |
| Isolation model | gVisor; extensions may use gVisor, iframe and/or WASM | Daemon on machines; machine pools and grants scope resources | Not comparable — unverified as a security comparison |
| Failure recovery | Retries, RAM-aware pause/resume and recoverable execution failures, as documented in the MIKE README | Durable conversation state backed by documented services; operational ordering and shared-storage requirements | Recovery emphasis differs; no measured recovery comparison |
| Inference | llama.cpp and OpenAI Chat Completions-compatible providers |
Any model, with org-owned model providers described in the docs | MIKE explicitly documents local-first inference options; Omnara documents broader model and machine scope |
| Interfaces and stability | Progressive Web App; author-confirmed RESTful Web API with Bearer tokens; API and extension interfaces not guaranteed stable before 1.0 | Web interface, CLI, REST API and TypeScript SDK; error code is a stable contract |
Omnara documents a stable API contract; MIKE documents pre-1.0 interface instability |
| Self-host footprint | Docker or Podman; quick start uses MIKE_ENCRYPTION_KEY and a privileged container for nested containers |
Four long-lived services plus one-shot migrator; Postgres, Redis, S3-compatible storage, shared memory filesystem and public URL | Different operational footprints; neither source establishes comparative effort |
| Backup story | Not stated in the available sources | “Back up the entire memory directory alongside PostgreSQL” | Not comparable — unverified for MIKE’s backup story |
| Licence | Apache-2.0 in GitHub probe | Apache-2.0 in GitHub probe | Both repos report Apache-2.0 |
The table is deliberately asymmetric where the evidence is asymmetric. In particular, MIKE’s use of gVisor does not establish a security advantage over Omnara’s daemon and sandbox-pool model. The sources do not provide a comparative audit, penetration test or certification basis for such a claim.
The API surface is measurable; the labels do not quite match
The live Omnara spec and docs give a useful example of why readers should distinguish a documented claim from a measured artifact. The API overview calls the spec OpenAPI 3.0, while the probe returned a spec reporting version 3.1.2 — enough to matter if your codegen or validator branches on the version string. The tag inventory drifts too: the docs’ endpoint-group table lists 12 groups, the served spec declares 14 tags, and the operations actually reference 15 distinct tags. The extra one is Memory Stores — used by four memory-file operations (listMemoryFiles, downloadMemoryFile, writeMemoryFile and the store listing) but never declared in the spec’s tags: block, so a client generated from declared tags alone has no home for that whole resource family. Both sources are linked: API overview and served OpenAPI document.
The mismatch does not invalidate the API documentation. It means an integrator should inspect the served contract rather than assume the prose and spec metadata are identical. Omnara’s API guide also documents cursor and sequence pagination, idempotency keys on create endpoints, and an error envelope with error and code. Its instruction is to “Branch on code — it’s a stable contract”; the error text itself may change without notice. Unreadable resources return 404, not 403, according to the API overview.
MIKE’s documented pre-1.0 instability notice points in the other direction: teams that need an integration boundary should account for the stated lack of guaranteed stable API and extension interfaces. Its author does describe a programmatic surface in the Show HN thread — “this features a RESTful Web API using a Bearer token for authorization,” with tokens generated via Settings → About so a cron job can curl a payload to start tasks — while noting “I haven’t spent much time on the documentation for this yet; the current docs were generated by agents.” So the surface exists; what the sources do not establish is its shape, its endpoint list, or a CLI/SDK. The same comment says the author added “configurable client side limits (concurrency and reqs per minute)” to keep runs smooth, which is a client-side guard rather than a server-enforced quota.
Measured this run: probe snapshot dated 2026-11-01
These are source and repository probe values, not performance measurements. None of the sources this guide reviewed reports a task-success rate, a latency figure, a throughput number or a cost-per-task result, and none is reproduced here.
| Probe | Measured result |
|---|---|
| Omnara OpenAPI response | GET https://api.omnara.com/api/openapi.yaml; HTTP 200; 609,469 bytes; OpenAPI 3.1.2 |
| Omnara API surface | 126 paths; 182 operations: GET 78 / POST 61 / PATCH 10 / DELETE 25 / PUT 8; 503 schemas |
| OpenAPI tag groups | 14 declared in the spec’s tags: block; 15 distinct tags referenced by operations — including Memory Stores, which is never declared |
| Omnara documentation index | llms.txt: 54,794 bytes; 225 distinct doc-page links |
| Omnara GitHub repository | 3,339 stars; 260 forks; 12 subscribers; 36 open issues; created 2025-07-09T01:30:55Z; pushed 2026-10-31T23:46:48Z; Go; Apache-2.0; 90,731 KB |
| MIKE GitHub repository | 4 stars; 0 forks; 0 subscribers; 0 open issues; created 2026-06-02T19:16:19Z; pushed 2026-10-29T19:13:34Z; Go; Apache-2.0; 143,274 KB; README shows 4,221 commits |
| Show HN: MIKE | 3 points; 11 comments |
The repository metadata is a dated snapshot, not an adoption or quality assessment. The source probes were the Omnara GitHub REST API, MIKE GitHub REST API and Show HN thread. In particular, stars, issues and comments do not establish production usage or reliability.
Reproduce the measurement
- On 2026-11-01 or another explicitly recorded date, issue
GET https://api.omnara.com/api/openapi.yaml; record the HTTP status, byte count,openapifield,pathscount, operations by HTTP method,components.schemascount, and both tag inventories — the top-leveltags:block and the distincttags: [...]values referenced by operations, which do not agree. - Fetch
https://docs.omnara.com/llms.txt; record the response size and count distinct documentation-page links. - Request
https://api.github.com/repos/omnara-ai/omnaraandhttps://api.github.com/repos/SoftwareRenderer/MIKE; record stars, forks, subscribers, open issues, creation and push timestamps, language, licence and repository size. - Open the MIKE README and record the displayed commit count; request the Show HN item and record its points and comments.
- Keep these source counts separate from performance measurements: the procedure measures document and repository metadata, not agent execution.
Failure modes and operational gotchas
Omnara’s migration order is explicit: “Run the release’s one-shot migrate image before starting its API, worker, and maintenance services.” The migrator must connect directly to the PostgreSQL writer; the deployment guide says not to use RDS Proxy or transaction-pooling PgBouncer. This is a sequencing and connection-path requirement, not a general database recommendation. The repository history also records migration renumbering under contention, including a process-exit migration moving after another branch added a migration.
Daemon versions can affect feature behavior. The repository notes that read fields are stripped for daemons before 0.2.9, that 0.2.9 and 0.2.10 shipped without output windows or no_stdin, moving the gate to 0.2.11, and that older daemons ignore notify_match. The deployment guide also calls out public URL and host handling: OMNARA_PUBLIC_URL must be publicly accessible for email links, OAuth callbacks and browser flows, and the API rejects hosts it does not recognize. Shared memory requires checking locking and file visibility across hosts.
The repository’s background-work notes give examples of operational edge cases: auto-archive could archive an agent and kill the command it was waiting on; fixes added a waiting_on_work state and kept processes counted until they end. A write_process call on a no-stdin command fails with process_stdin_unavailable, while pipe commands get /dev/null stdin by default so prompt hangs fail fast. These are documented implementation details, not evidence of failure rates.
For MIKE, the containerized quick start uses --privileged; its README says privileged access is only needed in that quick start to support nested containers. That qualification should travel with the flag when adapting the setup. The README also states that API and extension interfaces are not guaranteed stable before version 1.0. The Show HN post says notifications are off by default. The sources do not establish MIKE’s backup procedure or state-recovery behavior after host loss.
A six-row decision matrix
| Situation | Product | Documented criterion |
|---|---|---|
| Need a contract-stable API and typed SDK for integrations now | Omnara | Error code is described as a stable contract; spec is served at GET /api/openapi.yaml; TypeScript SDK is documented |
| Want local/offline inference only | MIKE | Supports llama.cpp and OpenAI Chat Completions-compatible providers; local-first by design |
| Need managed or ephemeral machines and org/project access controls | Omnara | Machine pools, grants and org/project scoping are documented |
| Want per-task parallel work with human code review as the core UX | MIKE | Kanban cards are task work units; project material describes a review-oriented PWA |
| Can operate Postgres, Redis, object storage and a shared filesystem | Omnara | These are listed self-hosting dependencies |
| Want a container quick start and extension sandboxing | MIKE | README documents a podman run quick start and gVisor/iframe/WASM extension sandboxing |
FAQ
Where does Omnara store durable state?
Omnara documents Postgres, Redis, an S3-compatible bucket and persistent memory at /var/lib/omnara/memory as components of its self-hosted deployment.
Where does MIKE store durable state?
The available sources do not establish MIKE’s durable-state location, database or queue.
Does MIKE’s gVisor model make it more secure than Omnara’s?
The evidence does not establish a security superiority claim for either system.
What must run before Omnara’s services?
The one-shot migration job must run before the API, worker and maintenance services.
Are MIKE’s API and extension interfaces stable?
No; its README says they are still being solidified and are not guaranteed stable before version 1.0.
Does “SOC 2 Type II” mean Omnara has completed certification?
No; the cited pricing page says only “Observation period in progress.”
How This Guide Was Built
This comparison was built from project documentation, the live OpenAPI spec and the GitHub REST API, with the dated repository and HN probes shown above. No hands-on testing of either product was performed. The 2026-11-01 measurements describe document and repository metadata; they are not benchmarks. MIKE’s durable-state backend and backup story remain unverified, and no comparative security, reliability or production-outcome claim is made. Omnara’s pricing page uses the phrase “Observation period in progress.” for SOC 2; it is not presented here as a completed certification. Both GitHub repository probes report Apache-2.0 licences.
The Bottom Line
The engineering contrast is where the durability is expressed. Omnara makes a conversation durable through explicitly named external services, shared memory, per-machine daemons and a migration step that must precede service startup. That clarity brings operational obligations: PostgreSQL writer connectivity, shared-filesystem behavior, backups and daemon version gates.
MIKE expresses durability around task cards and execution: worktrees, gVisor sandboxes via rootless Podman, retries, RAM-aware pause/resume and recovery from execution failures. Its available sources do not establish the storage and backup layer behind that workflow, so those parts of the durability story cannot be compared. If the implementation decision turns on persistent-state topology, that gap is material; if it turns on the work unit and documented execution model, the distinction is already clear. Neither conclusion requires a winner—only a precise account of what each project documents and what remains unknown.
📖 Related Reads
- ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
- CodeIntel Log — code quality, debugging, and software engineering benchmarks
- Hermes Tutorials — Hermes Agent setup, configuration, and advanced workflows
Cross-links automatically generated from NiteAgent.
← Back to all posts
