What is Device Memory?
In the standard Nebula model, your memory graph lives on Nebula’s servers. Device Memory inverts this: your application owns the canonical graph state, and Nebula operates as a stateless compute engine.
Your app stores a portable snapshot locally — on-device, in your database, wherever you choose. When new content arrives, you send it to Nebula. Nebula processes the content and returns an updated snapshot. Nothing is persisted server-side.
When to Use Device Memory
- Privacy — user data stays on-device or in your own infrastructure
- Offline-first — local memory graph that syncs when connectivity is available
- Portability — the snapshot is a self-contained file you can move anywhere
- Edge deployments — no server-side state to manage
If you’re fine with Nebula managing your state, the standard hosted API is simpler. See the
Quick Start.
How It Works
The API is the same one you already know — store_memory and search. The only difference is you pass a snapshot instead of a collection_id.
1. Bootstrap — Export a snapshot from an existing collection. After this, your local copy is canonical.
2. Store — Call store_memory with your snapshot and new content. Nebula processes it and returns an updated snapshot.
3. Search — Call search with your snapshot and a query. Nebula scores it and returns results. Nothing is stored server-side.
4. Export / Import — Serialize the snapshot to portable bytes for backup or transfer between devices.
Limitations
Device Memory is a single-writer protocol. If multiple devices mutate the same snapshot concurrently, writes will conflict. Use one writer at a time.
Next Steps
