Recipes & demos
Copy-paste-ready starter applications, from a minimalist core-only notebook up to a fully opted-in accounting app. Each recipe is a doc page paired with a runnable test under showcases/src/, so you can see the exact services it opts into and copy its createNoydb({...}) setup. The table reads roughly as an upgrade ladder — each recipe opts into more than the one before it.
Every recipe has the same anatomy, so once you've read one you can read them all: an Audience/Bundle header naming every package and with*() service composed, a Setup block with the complete createNoydb({...}), a walkthrough of each capability, and (where one exists) the showcases/src/recipe-* test that keeps the page honest.
| Recipe | What it builds |
|---|---|
| Personal notebook | The minimalist, core-only encrypted notebook — the smallest possible createNoydb({...}) with no opt-in services. |
| React invoice app | An end-to-end React app: reactive lists and filtered views via hooks, encrypted persistence in IndexedDB, lock/unlock — no state library. |
| User preferences | A per-user encrypted profile-and-preferences document in a shared vault — own-only writes, admin pre-fill at invite, cross-user reads, live bindings. |
| Email archive | MIME emails as one queryable record plus blob slots — ingest, threading, inline images, and document revisions across a thread. |
| Email archive — threads & revisions | Threading, inline-image HTML rendering, and cross-revision diffing on the same archive. |
| Collaborative app | CRDT merge, cross-device push/pull replication, live presence, and multi-user grants so every device converges on the same result. |
| Analytics app | Fast filtering, joins, grouped and streaming aggregates, lazy mode for beyond-memory collections, and hot/cold multi-store routing. |
| Accounting app | An auditable, period-sealing accounting app — version history, closed periods, attachments, localised labels, consent logging, and reports. |
| Unlock ceremonies | The full unlock lifecycle — secret root of trust, passkey enrollment and daily no-secret unlock, session policy gating sensitive operations, printed recovery codes. |
| Composing an echo secret | Choosing the three parts of an anti-phishing tier-1 secret — one memorable sentence, an echo no acquaintance could guess, and the warning to teach the user. |
| Passwordless OIDC (AWS Cognito) | Federated passwordless tier-2 unlock with the least infrastructure — AWS Cognito runs the sign-in, one tiny key-connector, the on-oidc split-key client. |
| Production cloud store | Postgres-backed vault, unattended at-env unlock with the mandated Shamir recovery, and hot/cold placement via routeStore. |
| Search & RAG | Lexical, semantic, and hybrid retrieval over encrypted records, then permission-scoped LLM tools via in-ai. |
| Browser durability | A pure SPA that survives a cleared cache — to-browser-idb for the live vault, a .noydb pod for the backup, and two tiers of getting it to disk. |
| Export & portability | Getting data out, three ways — capability-gated CSV/XLSX, the sealed .noydb bundle, and a member's re-keyed portable copy. |
| Attestation verifier | A signed per-field commitment as a QR code, verified fully offline against a published Ed25519 key — six verdict states, revocation included. |
| AWS-KMS attestation | An AWS Lambda that KMS-decrypts a sealed record from S3 and renders a PDF with the attestation QR embedded — gated by signed share links, verifiable offline. |
Beyond the recipes, every documented capability has a runnable proof: see Run the showcases for the full suite — its catalog is generated from the files, so the count there is current — and how to execute it locally in one command.
No recipe matches? Compose your own
Every recipe above is the same four decisions, made in order — make them for your own use case and you have your setup:
- Pick a store — where ciphertext lives: nothing (in-memory default) for prototypes,
to-file/to-browser-idbfor local persistence, or a cloud/SQL backend from theto-*catalog. The store choice changes no other code. - Pick an unlock method — how the vault opens: the built-in secret, or an
on-*method (passkeys, OIDC, TOTP, recovery codes…). Methods stack — a vault can enroll several. - Opt into services — one
with*()factory per capability from the Services catalog:historyStrategy: withHistory(),teamStrategy: withTeam(), and so on. Each page states what the factory adds and what happens when you skip it; anything not opted into tree-shakes away. - Wire your framework — an
in-*binding (React hooks, Vue composables, Pinia stores…) if you want reactive integration; plainawaitcalls if you don't.
The result is always the same shape the recipes' Setup blocks show:
const db = await createNoydb({
store: /* 1 */, user: 'me', secret: /* 2 */,
historyStrategy: withHistory(), /* 3, one per capability */
})
The Orientation map is the interactive version of these four decisions — tick what your app needs and it writes this block for you, with the pnpm add line and the doc links to match.
Browse the pages in the sidebar, or start from the recipe closest to your use case and add what's missing.