Skip to content
VoxNotch

Docs

Run the local demo before you trust the launch path.

The demo path is for evaluation: dynamic ports, generated secrets, local auth, and a resettable stack that does not require a Supabase account.

Best for
Evaluation without cloud accounts
Auth
Local demo sign-in
Ports
Dynamic allocation
Storage
Local volume or MinIO
shell
./web/scripts/launch/ops.sh dev --with-marketing
./web/scripts/launch/ops.sh urls
marketing/scripts/ops.sh urls
marketing/scripts/ops.sh launch-gates

Use dynamic dev ports for app plus marketing walkthroughs; the marketing URL command echoes sibling app/demo URLs when those env files exist.

Walkthrough

Test one recording before you demo the whole product.

The clean local demo is a short evidence loop. It should show a real app URL, a working worker, one fixture recording, one transcript, one export, and no optional cloud path.

  1. Open the printed app URL

    Use the URL from ops.sh urls rather than guessing port 3000. This avoids stale servers and makes the browser, API, worker, and marketing host under test explicit.

  2. Record or upload a fixture

    Use a harmless thirty-second recording. Name the storage mode before capture so the reviewer knows whether media is in the local volume, MinIO, S3, or R2.

  3. Wait for worker completion

    Open the recording only after the queue reports a completed transcription job. If the worker is not active, fix that before treating the demo as ready.

  4. Review and export

    Inspect the transcript, timeline, notes, and at least one export format. This is the smallest credible path from raw audio to useful output.

  5. Capture metadata-only proof

    Record the manual proof with status, summary, browser, recording ID, storage mode, and export type. Do not put sensitive audio or transcript text into public proof bundles.

Evidence commands

shell
cd web
./scripts/launch/ops.sh worker-recovery status
./scripts/launch/ops.sh manual-proof live-recording --status pass \
  --summary "Browser recorded fixture audio and transcription completed" \
  --field "Browser=<browser/version>" \
  --field "Recording id=<recording-id>" \
  --field "Storage mode=local"
./scripts/launch/ops.sh manual-proof upload-worker-path --status pass \
  --summary "Fixture upload, worker transcription, and export completed" \
  --field "Recording id=<recording-id>" \
  --field "Export=<md|json|srt|vtt>"

These commands capture metadata-only launch evidence without storing private media or transcript text.

A credible local demo shows more than a homepage.

  1. Resolved URLs

    Print marketing, frontend, API, docs, and demo URLs before the walkthrough so port conflicts are obvious.

  2. Readiness evidence

    Run launch gates and app status checks before inviting someone to click around.

  3. One real workflow

    Upload or record one short file, inspect transcription, produce one output, and show where the data lives.

  4. Exit path

    Know the stop/reset command and storage mode before the demo carries anything private.

The demo is an evaluation path, not a launch by itself.