Show & tell: ruflo-hub — I wanted my whole team (and all my machines) to share one ruflo brain, so I wrapped it in HTTP

[jazz-max]

Hey ruvnet & everyone 👋

First, thank you for ruflo — it genuinely changed how I work. The memory + intelligence layer is the thing I didn't know I needed, and now I can't go back. This post is half show-and-tell, half "here's what I learned the hard way," and one honest roadmap question at the end.

The itch

I run Claude across a few places — laptop, desktop, a couple of projects on a server. Each one spun up its own ruflo mcp start, which meant each had its own memory. My laptop didn't know what my server-side sessions had learned. That broke the magic a little: the whole point of the memory layer is that it remembers, and mine was fragmented across processes.

ruflo mcp is stdio-only, so there was no obvious way to say "everyone, talk to this one ruflo." So I built ruflo-hub: a small Docker wrapper that puts an Express + Streamable-HTTP proxy in front of a single long-lived ruflo mcp start. Now every client connects over HTTP (type: "http") to one instance with one shared memory.db:

Clients (Claude Code / Desktop / IDE, any host)
        | HTTP -> /mcp (Streamable JSON-RPC)
        v
┌─────────────────────────────────────────────┐
│ Docker: ruflo-hub                           │
│   server.mjs (Express proxy)                │
│   endpoints: /mcp /health /stats /setup ... │
│      | stdio (one child)                    │
│      v                                      │
│   npx ruflo mcp start                       │
└─────────────────────────────────────────────┘
        | TCP (optional)
        v
pgvector / RuVector

One brain, many clients. (And multi-instance if you want — several hubs on different ports sharing one Postgres, namespaced per project.) It's been running my team's setup for weeks.

What I learned the hard way (maybe useful to you or others)

Running it 24/7 surfaced some sharp edges. Sharing them in the spirit of giving back, not complaining — every one of these taught me something:

1. The memory leak that ate my weekend. Prod RSS kept climbing — 36 GB over six weeks. Turned out it wasn't my proxy and wasn't the JS heap at all (heapTotal was a flat ~24 MB). It was native arrayBuffers: the sql.js Emscripten MEMFS quietly accumulates dbfile_* files — roughly one full memory.db image per DB open — because createDatabase() re-loads the DB into a fresh SQL.Database without close(), and GC of the wrapper never frees the MEMFS file. A heap-snapshot retainer trace nailed it; full write-up in Unbounded native memory leak: orphaned sql.js MEMFS dbfile_* files (~11 MB each) accumulate per database open #2432. I contain it with an RSS watchdog (graceful child respawn) and patch the root at build time (per-path backend cache).
2. Reconnect has to be single-flight. My first auto-reconnect spawned a fresh ruflo mcp start for every concurrent request that hit "Not connected" — 100+ orphaned children and gigabytes over a few days. Killing the old child before spawning a new one fixed it.
3. First-run memory_store crash. On a clean container it threw Cannot convert undefined or null to object until I learned to drop a .migrated-to-sqlite marker next to a stub store.json — otherwise the stub gets treated as a legacy dump and migration null-derefs.
4. WAL bit me during a backup. memory.db is WAL-mode, and copying it without -wal/-shm reads back as database disk image is malformed. (Ask me how I found out 😅 — a corrupted store and a long evening of heap snapshots and raw-page carving to get the data back.)

None of this dimmed my enthusiasm — if anything, digging this deep made me appreciate how much ruflo is doing under the hood.

My one honest question

Is a native HTTP / Streamable transport anywhere on the roadmap — something like ruflo mcp start --http? My proxy works, but the "one shared, networked ruflo" use case feels common enough that it might deserve to be first-class, and then folks wouldn't need a wrapper at all. If there's appetite for it, I'd love to help — I've already got the battle scars. 🙂

Repo: https://github.com/jazz-max/ruflo-hub · related issue: #2432

Thanks again for building something worth wrapping. 🙏