Dev#39
Conversation
…ocalhost The dashboard WebSocket was hardcoded to http://localhost:8080/ws as fallback. When deployed on a VPS, the browser tried to connect to localhost (user's machine) instead of the server IP, causing CORS errors. Now uses window.location.origin at runtime so it works on any deployment (VPS, Coolify, custom domain) without configuration.
![charliecreates[bot]](https://avatars.githubusercontent.com/in/1140780?s=60&v=4){kind=small}
There was a problem hiding this comment.
The useWebSocketMetrics default URL derivation improves deployability, but it should emit an explicit ws:///wss:// URL rather than using window.location.origin (HTTP/S), to avoid client/library incompatibilities and mixed-content issues. The deployment guide is much more comprehensive, but it currently recommends piping a remote install script to sh without a production caveat, which conflicts with the hardening theme. The troubleshooting guidance around changing EVENTARA_PORT can desync the rest of the doc (firewall/proxy/URLs) unless you add consistency notes.
Additional notes (1)
- Maintainability |
DEPLOYMENT.md:109-124
The “You should see all 4 containers running” example is brittle: Compose project/service names vary by directory name,COMPOSE_PROJECT_NAME, and Compose v2 naming (often includes-1suffix). Also, statuses and port mappings can differ depending on env/ports. This is documentation, but presenting exact names as an expectation can mislead users into thinking something is broken when their output differs.
Summary of changes
What changed
DEPLOYMENT.md
- Rewrote the deployment doc into a VPS-focused, step-by-step guide for Ubuntu/DigitalOcean.
- Added minimum/recommended sizing, rationale for memory needs, and example droplet tiers.
- Expanded operational guidance:
- Docker install, repo clone,
.envsetup docker compose ... up -d --build, verification (ps,curltest), log commands- Updating, troubleshooting, and “nuclear reset” instructions
- Docker install, repo clone,
- Added optional HTTPS/domain setup via Caddy or Nginx + Certbot, plus UFW firewall guidance.
- Added a resource limits table and an updated production hardening checklist.
eventara-dashboard/src/hooks/useWebSocket.ts
- Removed the hardcoded
localhostWebSocket default. - Introduced
getDefaultWsUrl()to derive the WS endpoint from:import.meta.env.VITE_API_URL(if set)window.location.origin(same-origin fallback)- last-resort
http://localhost:8080/ws
- Hook now defaults to
getDefaultWsUrl()for deployment portability.
| ## Step 1 — Install Docker | ||
|
|
||
| You're already SSH'd into the droplet. Run these commands: | ||
|
|
||
| ```bash | ||
| # Update packages | ||
| sudo apt update && sudo apt upgrade -y | ||
|
|
||
| # Install Docker via the official convenience script | ||
| curl -fsSL https://get.docker.com | sh | ||
|
|
||
| # Add your user to the docker group (avoids needing sudo for docker commands) | ||
| sudo usermod -aG docker $USER | ||
|
|
||
| # Apply group change (or log out and back in) | ||
| newgrp docker | ||
|
|
||
| # Verify Docker is working | ||
| docker --version | ||
| docker compose version | ||
| ``` |
There was a problem hiding this comment.
The guide recommends installing Docker via curl ... | sh. That’s convenient, but it’s also a known security risk (piping remote scripts to root) and can be frowned upon for production hardening.
Since this doc includes a “Production Hardening Checklist”, it would be more consistent to either:
- include the official apt-repo installation steps (recommended), or
- clearly label the convenience script as a fast path for demos and point production users to the official install docs.
This is documentation, but it directly impacts operator security posture.
Suggestion
Adjust Step 1 to either (a) use Docker’s official apt repository installation instructions, or (b) keep the convenience script but add a prominent note and link to the official docs.
For example, add:
- "For production, prefer the official apt repo install: https://docs.docker.com/engine/install/ubuntu/"
- "The convenience script is intended for quick setup on fresh VPSs."
Reply with "@CharlieHelps yes please" if you’d like me to add a commit updating the doc accordingly.
| ### Common Issues | ||
|
|
||
| | Service | Memory Limit | | ||
| | Problem | Fix | | ||
| |---|---| | ||
| | Postgres | 1 GB | | ||
| | Kafka | 1 GB | | ||
| | Redis | 512 MB | | ||
| | Eventara (API + Dashboard) | 1 GB | | ||
| | `port is already allocated` | Change `EVENTARA_PORT=3000` in `.env` | | ||
| | Containers keep restarting | Check logs: `docker compose -f docker-compose.prod.yaml logs eventara` | | ||
| | Out of memory (OOM killed) | Upgrade to a larger droplet (8 GB) or reduce JVM: `JAVA_OPTS=-Xms128m -Xmx256m` | | ||
| | Kafka unhealthy | Wait 30-60 seconds, Kafka is slow to start. If persistent: `docker compose -f docker-compose.prod.yaml restart kafka` | | ||
| | Can't connect from browser | Ensure firewall allows port 8080: `sudo ufw allow 8080` | | ||
|
|
There was a problem hiding this comment.
The troubleshooting row suggests fixing port is already allocated by setting EVENTARA_PORT=3000, but elsewhere the document repeatedly assumes 8080 (firewall rules, URLs, reverse proxy examples). As written, a user who changes the port per this advice may end up with mismatched instructions and a broken access path.
If you want to support arbitrary ports, the doc should consistently reference ${EVENTARA_PORT} (or explicitly say “if you change it, update firewall/proxy/URLs accordingly”).
Suggestion
Make the port guidance consistent:
- Change the fix to "Change
EVENTARA_PORTto a free port (e.g.3000)" and - Add a note: "If you change
EVENTARA_PORT, also update UFW rules and reverse proxy upstream (e.g.reverse_proxy localhost:${EVENTARA_PORT}) and the URLs you use to access the app."
Reply with "@CharlieHelps yes please" if you’d like me to add a commit with these doc adjustments.
1 participant
No description provided.