epic: native standalone app (no Docker) — macOS / Windows / Linux

[Dewinator]

Goal

Ship mycelium as a native standalone application that a non-tech user can install with a single double-click and update like any other modern app. Cross-platform: macOS, Windows, Linux.

End-state: one installer file per platform (.pkg / .msi / .AppImage), no Docker dependency, no separate Ollama install, auto-update built in. Feels like a real application — Tray icon, Auto-start, Settings UI, lifecycle managed.

Installer format decision (2026-05-04): macOS ships as .pkg (signed + notarized), not .dmg. Reed wants to skip the drag-to-Applications ritual; .pkg is Apple's native installer-wizard format and plays cleaner with Sparkle auto-update + first-launch bootstrap. A Python-based installer was considered and rejected — macOS Sequoia removed system Python and Windows has none, so any Python installer would need a bundled runtime, which just shifts the bootstrap problem one layer deeper. Python stays inside the app as the first-launch setup wizard (init Postgres data-dir, pull llama.cpp models, run migrations) — that's a separate concern from the installer artifact.

Why

Docker Desktop is the single biggest install-time barrier today (~1.5 GB download, Apple-ID prompt, reboot, "Allow Privileged Helper"). Reed's pitch is "your AI — local, sovereign, no cloud", but every prospective user from outside the dev community bounces during the Docker step. The 300k-member FB group is interested; the install flow is the bottleneck.

Architecture (Path A)

Component	Today (Docker)	Native target
Postgres + pgvector	Docker container	Subprocess via @embedded-postgres-binaries/* (npm) — pattern: Postgres.app
Embedding (nomic-embed-text)	Ollama HTTP @ 11434	llama.cpp direct call (node-llama-cpp), model bundled
LLM (qwen3:8b, REM)	Ollama	llama.cpp direct call, GGUF bundled
MCP server	Node + tsc	Single binary (Bun compile or pkg)
Dashboard	Browser → localhost:8787	Tauri window (or sticky Browser tab v1)
Updates	bash scripts/update.sh	Sparkle (macOS) / MSIX (Win) / AppImage-update (Linux)
Data dir	~/vectormemory-openclaw/docker/volumes/	OS-native: ~/Library/Application Support/mycelium/, %APPDATA%\mycelium\, ~/.local/share/mycelium/

Sub-tasks (each ships as its own PR; ordered by dependency)

1. Spike 1: native Postgres subprocess — start/stop/upgrade lifecycle, run all existing migrations, all 920 tests still green. macOS first to validate the approach.
2. Spike 2: node-llama-cpp bridge — replace Ollama HTTP calls with direct llama.cpp embedding + chat. Same API surface (services/embeddings.ts).
3. Tauri shell: native window, tray icon, auto-start, manages PG + MCP-server subprocesses.
4. Cross-platform PG: verify the npm Postgres-binaries package on Win + Linux.
5. Cross-platform llama.cpp: macOS Metal, Windows DirectML/CUDA, Linux Vulkan/CUDA.
6. Auto-update channels: Sparkle XML feed (macOS, delta .pkg), MSIX update (Win), AppImage zsync (Linux). Single GitHub release publishes all three artifacts.
7. Migration story: "Import from Docker install" wizard reads existing ~/vectormemory-openclaw data, pg_dump → restore into embedded PG.
8. CI matrix: build all three installers per release tag (.pkg / .msi / .AppImage), sign + notarize macOS, sign Windows.
9. Update banner refit: PR feat(dashboard): update banner — surface 'behind main' + show users how to update #175's banner currently shows the git-pull command — for the native app it should trigger Sparkle's "Check for Updates".
10. Docs refresh: README + setup.md replace Docker instructions with download links + first-run wizard screenshots.

Realistic timeline

• Spike 1 + 2 (validation): 2–4 days of focused tick work. Answers "is Path A even feasible at the runtime level?"
• Tauri shell + macOS first: 1 week after spikes confirm.
• Cross-platform: another 1–2 weeks (CI matrix, signing, per-platform issues).
• Auto-update infra: separate week (release pipeline + first staged rollout).

So: ~3–4 weeks end to end at tick pace, NOT a single evening (this overrides Reed's "heute Abend fertig" — that estimate is off by an order of magnitude). What CAN realistically ship tonight is Spike 1 fully validated if the tick focuses on it.

Pillar check

• Pillar 1 (no cloud dependency): strengthened — moves from "needs Docker daemon" to "fully embedded".
• Pillar 6 (security): data dir moves to OS-native, can be encrypted via OS keystore in v2.
• No pillar weakened.

Out of scope

• iOS/Android — separate roadmap.
• Cloud-hosted variant (Path C) — explicitly rejected per the swarm sovereignty thesis.
• Replacing Postgres entirely with SQLite — possible later optimization; for now keep schema/migrations identical so we can dual-build during transition.

🤖 Generated with Claude Code

[Dewinator]

Path A pglite pivot — empirically green-lit (2026-05-02 tick)

Update from a re-run of #179's pglite walker against main + PR #181 + PR #183 stacked: 79/79 migrations all green (was 34/78 in the spike PR alone, blocked at 040). Cold-init ~5 s, total migration walk ~1.7 s, pg 17.5 + vector 0.8.1 in-process via WASM.

Concrete consequence for the architecture table at the top of this issue:

• Postgres + pgvector row: change "Subprocess via @embedded-postgres-binaries/*" → @electric-sql/pglite (in-process WASM, ~23 MB, pgvector 0.8.1 built in). The original npm-binaries plan is empirically blocked (no pgvector ships with that bundle, no pg_config, no headers). pglite collapses the entire "no Docker" story into one cross-platform npm dep.

Merge order to unblock the next step: #181 → #183 → #179. After that, Spike 1.5 ("pglite single-connection wrapper + production-tier validation") becomes a clean follow-up.

Spike 2 (#178 / PR #182) — node-llama-cpp validation — is independent and stays in the queue.

[Dewinator]

Spike 1.5 filed (#184)

Per the path-forward in docs/native-pg-spike.md and the comment above:

• ✅ Sub-task 1 — latent migration bug fix (PRs fix(install): minimal trust substrate so fresh installs reach migration 040 (#180) #181 + fix(install): quote position in 077 RETURNS TABLE — fresh-install blocker after #181 #183 — 79/79 migrations green on a fresh PGlite install)
• ✅ Sub-task 1 (Spike 1) — feasibility validated (feat(app): Spike 1 — embedded Postgres subprocess (no Docker), all migrations + tests still green #177 / PR spike(native-pg): validate Path A — embedded-postgres blocked, pglite recommended (#177) #179)
• 🆕 Sub-task 2 — PGlite adapter for production filed as feat(app): Spike 1.5 — PGlite adapter for production (single-connection wrapper, MemoryService integration) #184 (agent-eligible)
• ✅ Sub-task 4 (Spike 2) — node-llama-cpp validated (feat(app): Spike 2 — node-llama-cpp embedding + chat bridge (drop Ollama dependency) #178 / PR spike(native-llm): node-llama-cpp validates as in-process LLM (#178) #182)
• ⏳ Sub-task 3 — drop PostgREST in native build (will be filed once feat(app): Spike 1.5 — PGlite adapter for production (single-connection wrapper, MemoryService integration) #184 lands so it can build on the adapter shape)
• ⏳ Sub-tasks 5–10 — Tauri / cross-platform / auto-update / migration story / CI / docs (not yet filed; sequenced after feat(app): Spike 1.5 — PGlite adapter for production (single-connection wrapper, MemoryService integration) #184)

#184 is sized as a single focused tick that gives the rest of #176 something concrete to build on.