← Back to Open Source

rtcstats-server: Requirements & Operations Guide

What it takes to run rtcstats-server in production: machine requirements, capacity, scaling, availability, security, monitoring, and updates.

1. Introduction

This document describes what it takes to run rtcstats-server in production: the machine requirements, and how to operate the service day to day, including scaling, availability, security, monitoring, and updates.

Use it to plan a first deployment, then keep it as the operating reference for the running service.

2. Scope

This guide covers the rtcstats-server component only: machine requirements, capacity, and operations: scalability, high availability, serviceability, monitoring, updates, security, and privacy.

Out of scope: the database and the file storage service. rtcstats-server requires a PostgreSQL-compatible database (session metadata) and an S3-compatible object storage (dump files). Provisioning, sizing, backup, and high availability of those two services are not covered here.

Out of scope:rtcstats-features (offline dump processing).

3. Architecture overview

rtcstats-js (browser / app)
        |  WSS (TLS)
        v
  Load balancer          <- TLS termination happens here
        |  WS (plain, private network)
        v
  rtcstats-server (1..N instances)
        |  local disk (temp scratch space during active sessions)
        |
        +---> S3-compatible storage   (dump files, on session end)
        +---> PostgreSQL              (session metadata + storage pointer)

Key properties:

  • Each rtcstats-js client holds one persistent WebSocket connection to one rtcstats-server instance for the duration of its session.
  • During the session, events are written to a temporary file on local disk. When the connection ends, the file is uploaded to storage and the database is updated with a pointer to the storage URL.
  • Instances are stateless between sessions: no in-memory data needs to migrate between servers. All durable state lives in the database and the object storage.
  • rtcstats-server does not terminate TLS itself. A load balancer in front handles TLS.

4. Machine requirements

Operating system

  • Linux (x86_64 or arm64): Any distribution able to run a supported and current LTS Node.js runtime.
  • Container deployment is supported.
  • Managed platforms are validated: AWS App Runner and DigitalOcean Apps Platform deployment guides exist in the knowledge base.

Node.js

  • Node.js 22 is the runtime used in the reference deployments. Treat 22 LTS as the supported baseline.
  • Keep your instances up to date with the Node.js release lifecycle.

Baseline sizing

The reference starting point is deliberately small:

Tier vCPU Memory Local disk Intended use
Pilot / staging 1 2 GB 20 GB Validation, low traffic.
Production node 2 4 GB 50 GB Standard production instance in a cluster of 2 or more.

Notes:

  • The 1 vCPU / 2 GB tier is the documented reference configuration. The 2 vCPU / 4 GB tier is a recommended production starting point, not a published benchmark. Validate both against your own traffic before committing (see Concurrent session capacity below).
  • Considerations: Size it for the sum of in-flight session files: concurrent sessions x average dump size x safety factor. Example with assumptions to adjust: 1,000 concurrent sessions x 5 MB average in-flight dump x 4 = 20 GB. Compressed dumps are often smaller (hundreds of KB for short calls); long sessions with many peer connections are larger.

Network

  • One inbound port (default 8080) receiving plain WebSocket traffic from the load balancer.
  • Instances should sit in a private subnet. Only the load balancer is internet-facing.
  • Outbound access required to: the object storage endpoint and the database.

Concurrent session capacity

One session = one persistent WebSocket connection. Capacity per instance is driven by:

  1. CPU load: message parsing, delta decompression of getStats payloads, compression of dump files.
  2. Disk usage: temporary files for every active session.
  3. Concurrent WebSocket connections: file descriptors and memory per socket.

Published guidance (horizontal scaling guide): plan to scale out when an instance approaches 1,000+ concurrent connections, or when CPU or memory utilization sits consistently above 70 to 80 percent.

Practical reading of that guidance: treat ~1,000 concurrent sessions per production node (2 vCPU / 4 GB) as the planning ceiling, and confirm the real number for your workload with a load test. Session weight varies widely. There is no universal sessions-per-vCPU constant.

5. Operations

Day-to-day operation of the service: scaling, high availability, serviceability, monitoring, updates, security, and privacy.

Scalability

rtcstats-server scales horizontally. The requirements for scaling can be found here: horizontal scaling guide.

Note: The database and the file storage must support the rtcstats-server scaling dimension: every instance in the cluster writes to the same two services (out of scope).

High availability

rtcstats-server supports high availability by deploying 2 or more instances behind a load balancer:

  • rtcstats-server is stateless by design: a new instance can be started at any time.
  • Load balancer health checks: an unhealthy instance stops receiving new connections (see the Serviceability paragraph).
  • Maintenance mode: remove the instance from the LB targets, wait for its WebSocket connections to drain, then stop it.

Current limitation: if a rtcstats-server instance goes down, the rtcstats sessions it was collecting are lost.

Serviceability

rtcstats-server exposes a health check endpoint GET /healthcheck that returns 200 OK.

Monitoring

Use the health check endpoint (see Serviceability) to monitor rtcstats-server health.

No additional data is exposed.

Updates

rtcstats-server updates live inside the open source repository (GitHub):

  • The current source acts as the current version.
  • Any bugs are fixed in the main branch.
  • Plan to update rtcstats-server at least every 6 months, and never less than once a year.

Security

Protocols

  • rtcstats-js connects over WSS (WebSocket over TLS) to the load balancer.
  • The load balancer terminates TLS. rtcstats-server does not handle TLS itself (README).
  • The load balancer forwards plain WebSocket traffic to the instances on port 8080. This leg must stay inside a private network (VPC / private subnet, firewall rules restricting ingress to the load balancer).
  • Certificate management (issuance, rotation) therefore lives entirely at the load balancer layer.

Identification, authentication, and authorization

  • Each client presents a JWT carrying the claims user (user id), session (session id), conference (conference id).
  • The client sends the token as a URL query parameter during the WebSocket connect phase.
  • The token is signed with an HMAC (shared secret) and validated by the server. The server rejects connections with a missing, malformed, or expired token.
  • The standard JWT expiration mechanism is used.

Privacy

IP anonymization and PII stripping are configurable but out of scope here. See Configure rtcstats-server for privacy.

Sources

Was this page helpful?

Next Article

How to horizontally scale rtcstats-server in a cluster

Scale rtcstats-server across multiple instances for high-volume WebRTC deployments.