Sapsan configuration¶

Sapsan and central form an inseparable system and are delivered together. Sapsan is configured through the central API.

This Sapsan manual may present feature parameters as YAML snippets. These snippets can be submitted through the central API. They describe the Sapsan configuration; use the documentation for your chosen solution for the request endpoint and the central API request format.

The configuration structure and the rules for applying it are described below.

See joining streamers for adding a machine to the cluster, join windows and authentication.

Configuration structure¶

listeners:        # ports the server listens on
  http:
    - port: 80
  rtsp:
    - port: 554
  rtmp:
    - port: 1935
  webrtc:
    - port: 5005

streams:          # list of streams
  - name: cam1
    inputs:
    - rtsp:
        url: rtsp://admin:password@10.0.0.5/stream0
    dvr: {}

dvr:              # shared archive storage
  root: /storage
  disks:
  - path: d1

auth: {}            # playback and publish authorization
config_external: {} # external configuration management
rproxy: {}          # Peeklio gateway
api_auth:           # Admin API login/password
  login: admin
  password: secret

Validation¶

Sapsan validates the configuration on load and refuses to start with an invalid one:

• unknown fields are an error (protects against typos);
• every stream input must contain exactly one protocol;
• ports cannot be reused across listeners and streams;
• if a stream has dvr enabled, the global dvr section must exist.

Hot reload¶

Configuration changes are submitted through the central API. At the process level, Sapsan supports reloading sapsan.yaml on SIGHUP without restarting:

• streams, authorization, and DVR are reconfigured in place;
• listeners are rebound only when a port changes;
• the rproxy gateway keeps agent connections across reloads (but changing streampoint_key / endpoint_auth_url requires a process restart).