Skip to main content
suchi demo seeds a fresh DATA_DIR from a versioned corpus manifest. SUCHI_DEMO_MODE=1 adds the runtime controls needed for a disposable public showcase. The mechanism ships in the main binary. Corpus and deployment artifacts are maintained separately in johnnybravo-xyz/suchi-demo.

​
Seed data

Useful flags: Without a corpus flag, the command fetches the release tested with this build. The hosted image embeds that tarball and seeds only when its dedicated data volume has no database. Normal suchi serve startup never fetches content. Local and remote corpus archives share the same limits: 256 MiB compressed, 1 GiB extracted, 10,000 entries, and a 4 KiB checksum sidecar. Fixtures may include curated exact-day dates in the manifest:
The seeder validates dates and inserts them with the document and processing job in one transaction. They use the existing fact table with status=accepted and extractor=demo-corpus; no model confidence or human review is invented. Evidence must come from the fixture. Reseeding preserves existing documents; updated fixtures take effect on a fresh demo volume at the next reset.

​
Guided feature tour

The first dashboard visit in a browser redirects to the Demo guide once per session. Its first step runs a real rich query against the anonymized Northstar Cloud renewal cluster. The second step opens Calendar’s read-only examples across all months and years, each linked to its source document. Public demo identities do not invoke Archive research or any model provider. The guide labels Archive research as available on private installations, not a live demo action. It does not substitute a canned answer. A persistent help icon in the top-right returns to the guide after the visitor explores Search or another screen.

​
Runtime controls

Demo mode refuses to start alongside SUCHI_DEV=1 or OIDC. Use a dedicated DATA_DIR; demo credentials and retention rules are intentionally unsuitable for a normal archive.

​
Visitor sessions

POST /api/demo/session returns a signed anonymous token for read-only browsing. It requires no database write. The browser uses an HttpOnly cookie; JavaScript does not store a credential. Header-based read clients can still send the returned token as X-Suchi-Demo-Token. The first mutation receives demo_upgrade_required. The SPA calls POST /api/demo/session/upgrade, receives an HttpOnly session cookie for a scratch user, and retries the request. Concurrent writes share one upgrade. The same session authorizes preview/download links and survives a page reload. It expires at the configured scratch TTL; reload to begin a new visit after expiry. Signing out revokes the session and clears both demo cookies. Scratch users can upload and modify their own documents but cannot read another visitor’s uploads or mutate shared configuration and taxonomy. The seeded corpus remains read-only and visible to every visitor. These demo exceptions apply only to the unnamed original system 1. Demo seeding uses that internal default explicitly; anonymous and scratch principals cannot enter a named system, even if a document grant exists. Do not introduce prefixed taxonomies into a public showcase to broaden demo access. Calendar’s read exception is limited to accepted, curated demo-corpus date facts. Source-document visibility, trash exclusion, and token read scopes still apply before counts and pagination. Pending/rejected facts, date extraction and review, and Archive research remain denied. No capabilities are granted to demo identities, and ordinary users still need archive_intelligence. Cookie-authenticated demo mutations use the same same-origin Fetch Metadata checks as ordinary browser sessions. A scratch cookie does not grant access to account administration, token management, or another visitor’s documents. Both session endpoints use a per-IP token bucket. The default is 5 requests per second with a burst of 10.

​
Shared-state guard

httpx.DemoReadOnly permits reads and document-scoped writes. It rejects mutations to shared surfaces including:
  • admin settings and setup state
  • taxonomy and automations
  • users, groups, ACLs, and tokens
  • storage paths, mail settings, saved views, and share links
Rejected shared writes return 403 with code: "demo_read_only". Document handlers still enforce ownership, so the broader document route allowance does not let a scratch visitor change the corpus or another visitor’s upload.

​
Expiry and cleanup

Scratch users use the visitor-*@demo.local pattern. The reset ticker runs at half the configured TTL and deletes expired matching users, their documents, and cascading session/token records. It cannot select ordinary users or seeded demo rows; disabled visitors are retained for operator investigation. It never deletes CAS bytes: a reference check cannot account for an in-flight upload reusing a blob. Expiry removes access, not physical bytes. Reclaim disk space with the server and all archive writers stopped, using suchi gc, or through the deployment’s full volume reset. The sibling deployment’s nightly reset stops the server, recreates only its dedicated demo volume and lets the image entrypoint seed it again. Suchi does not expose a partial in-place reset that could leave corpus blobs or metadata behind.

​
Deployment boundaries

  • Put the instance behind TLS and an edge request-size limit.
  • Keep BACKUP_INTERVAL=0 unless demo state is intentionally retained.
  • Keep LLM, OIDC, mail intake, and other outbound integrations disabled.
  • Monitor session mint rates, disk use, and audit_events.
  • Treat visitor uploads as untrusted and disposable.
The main repository does not promise a hosted public instance. Availability, fixtures, automations, DNS, image version pairing, and reset operations belong to the separate demo project.