[FEATURE] Docker Compose one-command demo with sample data

[NovaCode37]

Make it trivial to try PRISM: a docker compose up that boots the stack pre-seeded with a couple of example scans, plus a short section in the README.

Acceptance criteria

• docker-compose.demo.yml (or a profile) that runs end-to-end with no API keys.
• README "Try in 60 seconds" snippet.

[stevesagronegocios673-ux]

Quick demo-path note after reading the current README, .env.example, docker-compose.yml, Dockerfile, and web/app.py: I would make the demo compose file prove the frontend + API + preloaded results path, not just that the FastAPI container starts.

Right now the README says Docker users can open localhost:3000 and localhost:8080, but the current docker-compose.yml only defines the backend service on 8080. Also, the README says the backend rejects requests without a valid X-API-Key by default, while .env.example leaves API_KEY= empty. Those are exactly the two places a “Try in 60 seconds” flow can stall.

Suggested shape:

# docker-compose.demo.yml
services:
  api:
    environment:
      API_KEY: demo-key
      ALLOW_ANON_API: "false"
      # no paid provider keys required
    volumes:
      - ./demo/scan_data:/app/scan_data:ro
  frontend:
    environment:
      NEXT_PUBLIC_API_URL: http://localhost:8080
      NEXT_PUBLIC_API_KEY: demo-key

Then the README snippet can be very literal:

docker compose -f docker-compose.demo.yml up --build
# open http://localhost:3000
# sample domain/IP/email scans are already visible

For the sample data, I would avoid making first-run depend on live OSINT lookups. Seed 2-3 completed scans into scan_data/ with safe targets and representative fields: one domain, one IP, one username or email-style example. The demo should show the dashboard, OPSEC score, graph/report affordances, and module skip behavior without requiring Shodan/VirusTotal/OpenRouter/etc.

One acceptance-criteria tweak: add “demo does not require external API keys or live network lookups beyond building/pulling images.” That keeps the demo from becoming flaky and makes it safer for reviewers to run.

Want the fuller pass? I can turn this into a compact paste-ready README “Try in 60 seconds” section plus a demo compose outline, seed-data manifest, and checklist for frontend/API/key wiring.

[NovaCode37]

Quick demo-path note after reading the current README, .env.example, docker-compose.yml, Dockerfile, and web/app.py: I would make the demo compose file prove the frontend + API + preloaded results path, not just that the FastAPI container starts.

Right now the README says Docker users can open localhost:3000 and localhost:8080, but the current docker-compose.yml only defines the backend service on 8080. Also, the README says the backend rejects requests without a valid X-API-Key by default, while .env.example leaves API_KEY= empty. Those are exactly the two places a “Try in 60 seconds” flow can stall.

Suggested shape:

docker-compose.demo.yml

services:
api:
environment:
API_KEY: demo-key
ALLOW_ANON_API: "false"
# no paid provider keys required
volumes:
- ./demo/scan_data:/app/scan_data:ro
frontend:
environment:
NEXT_PUBLIC_API_URL: http://localhost:8080
NEXT_PUBLIC_API_KEY: demo-key
Then the README snippet can be very literal:

docker compose -f docker-compose.demo.yml up --build

open http://localhost:3000

sample domain/IP/email scans are already visible

For the sample data, I would avoid making first-run depend on live OSINT lookups. Seed 2-3 completed scans into scan_data/ with safe targets and representative fields: one domain, one IP, one username or email-style example. The demo should show the dashboard, OPSEC score, graph/report affordances, and module skip behavior without requiring Shodan/VirusTotal/OpenRouter/etc.

One acceptance-criteria tweak: add “demo does not require external API keys or live network lookups beyond building/pulling images.” That keeps the demo from becoming flaky and makes it safer for reviewers to run.

Want the fuller pass? I can turn this into a compact paste-ready README “Try in 60 seconds” section plus a demo compose outline, seed-data manifest, and checklist for frontend/API/key wiring.

This is a great breakdown - thanks for actually reading through the compose/Dockerfile/app.py before commenting. You nailed the two spots where a "Try in 60 seconds" flow would stall:

1. Missing frontend service - the current docker-compose.yml only defines the backend on 8080, so the README's "open localhost:3000" doesn't hold. The demo compose must bring up frontend + API together.
2. Auth wiring - backend rejects requests without a valid X-API-Key while .env.example ships API_KEY= empty. The demo needs a baked-in demo-key shared between API and frontend (NEXT_PUBLIC_API_KEY), exactly as you sketched.

I also agree on seeding 2–3 completed scans into scan_data/ (one domain, one IP, one email/username) with safe targets, so first-run shows the dashboard, OPSEC score, graph/report and module-skip behavior without any live lookups.

Adopting your acceptance-criteria tweak: "demo does not require external API keys or live network lookups beyond building/pulling images." That keeps it from getting flaky.

If you're up for it, the fuller pass would be very welcome - a paste-ready "Try in 60 seconds" README section, the docker-compose.demo.yml outline, a seed-data manifest, and the frontend/API/key wiring checklist.

[stevesagronegocios673-ux]

Thanks — I can do that as a compact $5 pass.

Scope: paste-ready Try in 60 seconds README section, docker-compose.demo.yml outline, seed-data manifest, and frontend/API/key wiring checklist. Docs/spec only; no PR or code changes in this pass.

If that scope and $5 price works, confirm here and I will send payment options.