Skip to content

docs: clarify deployment notes after audio HTTP migration #29

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
revtex merged 1 commit into from
Apr 25, 2026
Merged

docs: clarify deployment notes after audio HTTP migration #29

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/deployment-guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,7 +117,7 @@ Most people already have a web server (Caddy, nginx, Traefik) on their home serv

Two rules to remember when proxying:

- **Forward WebSocket upgrades** on `/api/ws`, `/ws`, and `/api/admin/ws` — the live audio stream and admin events use them. `/api/ws` is the canonical listener endpoint; `/ws` is a compatibility alias kept for legacy clients and should also be proxied.
- **Forward WebSocket upgrades** on `/api/ws`, `/ws`, and `/api/admin/ws` — the live call feed and admin events use them. `/api/ws` is the canonical listener endpoint; `/ws` is a compatibility alias kept for legacy clients and should also be proxied. (Audio is delivered separately as a regular HTTP response from `/api/calls/:id/audio` and does not require WebSocket forwarding.)
- **Send `X-Forwarded-Proto`** so OpenScanner knows whether to mark cookies as secure.

If the proxy is on the same machine, it's also a good idea to bind OpenScanner to localhost only so nothing bypasses the proxy. In your compose file:
Expand Down Expand Up @@ -181,7 +181,7 @@ server {
}
```

After starting the proxy, open the public URL in a browser and confirm the live scanner still plays audio — that's the quickest way to verify the WebSocket forwarding is working.
After starting the proxy, open the public URL in a browser and confirm the live scanner shows new calls and plays audio. New calls arriving prove the WebSocket forwarding is working; audio playing proves the standard HTTPS forwarding (and cookies) are working.

> **Tip:** Make sure your server's clock is accurate (NTP is usually on by default). Login tokens have expiry times, and a clock that's off by several minutes will cause confusing login failures.

Expand Down Expand Up @@ -340,7 +340,7 @@ After deploying, check these to confirm everything works:
- [ ] The browser URL shows the scanner interface (or the setup page on first run)
- [ ] Admin login works and the dashboard loads
- [ ] A test upload from your recorder appears in OpenScanner
- [ ] The live scanner feed plays audio (this proves WebSockets are working)
- [ ] The live scanner feed shows new calls in real time (this proves WebSockets are working) and plays them back (this proves audio HTTP fetches and cookies are working)

---

Expand Down
Loading