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 — memories.create and memories.search. The only difference is you pass a snapshot instead of a collection_id.
For larger snapshots or server-side storage that remains customer-owned, pass a signed URL snapshot_ref instead of sending the snapshot inline. See Device Memory API.
1. Bootstrap — Call snapshots.export to pull a snapshot from an existing collection. After this, your local copy is canonical.
2. Store — Call memories.create with your snapshot and new content. Nebula processes it and returns an updated snapshot.
3. Search — Call memories.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
