Skip to content

HASMAC-AS/DayList-Signaling-

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

WebRTC Signaling Server (Render-ready)

This is a tiny WebSocket signaling server for WebRTC. It forwards messages between peers in the same room.

Deploy to Render

Render can deploy this directly from your GitHub repo as a Web Service. Render supports WebSockets for web services.
If you use a Blueprint, keep render.yaml at the repo root. citeturn0search0turn0search2turn0search3

Option A: Blueprint (recommended)

  1. Commit these files to the root of your repo.
  2. In Render: New → Blueprint and point to your repo.
  3. Set the env var AUTH_KEY in the Render UI (global gate), and optionally SIGNALING_TOKEN (WebSocket token auth).

Option B: Create a Web Service (no Blueprint)

  • Runtime: Node
  • Build command: npm ci
  • Start command: npm start

(These are the standard values Render recommends for Node services. citeturn0search1turn0search5)

Usage

Connect:

  • Local:
    • ws://localhost:3000/ws?room=test
  • Render (TLS-terminated, so use wss://):
    • wss://YOUR-SERVICE.onrender.com/ws?room=test

Global auth key (if AUTH_KEY is set)

All endpoints require the query param:

?auth_key=YOUR_AUTH_KEY

Examples:

  • http://localhost:3000/?auth_key=YOUR_AUTH_KEY
  • wss://YOUR-SERVICE.onrender.com/ws?room=test&auth_key=YOUR_AUTH_KEY

Optional shared token auth

If you set SIGNALING_TOKEN on the server, clients must include:

wss://YOUR-SERVICE.onrender.com/ws?room=test&token=YOUR_TOKEN

Messaging

Anything you send (JSON preferred) is forwarded to other peers in the same room.

Example payloads from a WebRTC client:

{ "type": "offer", "sdp": "..." }
{ "type": "answer", "sdp": "..." }
{ "type": "candidate", "candidate": { "candidate": "...", "sdpMid": "0", "sdpMLineIndex": 0 } }

The server will automatically attach:

  • from: sender socket id
  • room: room id

Direct messages

If you include "to": "<peerId>", the server will route the message only to that peer (if present).

Local dev

npm ci
npm start

Then open:

  • http://localhost:3000/?auth_key=YOUR_AUTH_KEY (info)
  • http://localhost:3000/healthz?auth_key=YOUR_AUTH_KEY (health)

Notes / limitations

  • Rooms are kept in-memory. If the process restarts, everyone reconnects.
  • Multiple instances won't share room state without a shared pub/sub layer (Redis, etc.).

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors