Configuration
Cambridge is configured using TOML files and optional environment variable overrides. This page describes the configuration file format, available settings and how to override values using environment variables.
Config File
By default, Cambridge looks for a file named device_config.toml in the working directory. You can specify a different path using the --config (or -c) flag:
nabto-cambridge --config /path/to/custom_config.toml
Multiple config files can be specified. When the same key appears in more than one file, the last file on the command line wins:
nabto-cambridge -c base.toml -c service.toml -c device.toml
If no --config flag is given and device_config.toml does not exist, Cambridge starts normally, allowing environment-variable-only configuration. However, if you explicitly specify a file that does not exist, Cambridge will exit with an error.
Precedence
Configuration values are resolved in this order (highest to lowest priority):
- Environment variables (
CAMBRIDGE__*) - TOML config files (last file wins for duplicate keys)
- Built-in defaults
Logging
The [logging] table configures log level filtering. Valid log levels from most to least verbose are: trace, debug, info, warn, error, none.
Log levels can be configured globally and on individual modules. Multiple configurations are separated by ,. For example: "none,nabto_cambridge=info,nabto_webrtc=info" configures the global log level to none and then sets the log level of the nabto modules nabto_cambridge and nabto_webrtc to info. This means only the nabto modules will produce logs and will do so at info level.
[logging]
level = "warn,nabto_cambridge=debug"
| Key | Default | Description |
|---|---|---|
level | "error,nabto_cambridge=info,nabto_webrtc=info" | Log level filter string |
Signaling Configuration
The [signaling.nabto] section defines the credentials Cambridge uses to connect to the Nabto WebRTC Signaling Service. See the Signaling Configuration guide for a full description of how these values are provisioned.
[signaling.nabto]
product_id = "pr-xxxxxxxx"
device_id = "de-xxxxxxxx"
shared_secret = "aaaabbbbccccddddeeeeffffgggghhhh"
private_key = """
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIABxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxQ==
-----END EC PRIVATE KEY-----
"""
# server_url = "https://custom.signaling.example.com" # optional, for testing
| Key | Required | Description |
|---|---|---|
product_id | Yes | Product ID assigned to the product in the Nabto Cloud Console |
device_id | Yes | Device ID assigned to this device |
shared_secret | Yes | Shared secret for mutual authentication of signaling messages |
private_key | Yes | PEM-formatted EC private key for device authentication |
server_url | No | Custom signaling service URL (for testing) |
HTTP Services
HTTP services are defined as named TOML tables under [services.http]. Each table name becomes the service name that clients use when sending http.request calls.
[services.http.my_camera_api]
description = "Camera management API"
protocol = "http"
port = 80
address = "127.0.0.1"
[services.http.secure_api]
description = "Camera HTTPS API"
protocol = "https"
port = 443
address = "127.0.0.1"
| Key | Required | Description |
|---|---|---|
description | Yes | Human-readable description of the service |
protocol | Yes | "http" or "https" |
port | Yes | Port number on the target host |
address | Yes | DNS hostname or IP address of the target service (use 127.0.0.1 when Cambridge runs on the same host) |
RTSP Services
RTSP services follow the same named-table pattern under [services.rtsp]:
[services.rtsp.main_stream]
description = "Main camera stream"
address = "127.0.0.1"
port = 554
[services.rtsp.main_stream.digest_authentication]
username = "admin"
password = "secret"
| Key | Required | Description |
|---|---|---|
description | Yes | Human-readable description of the service |
address | Yes | DNS hostname or IP address of the RTSP service (use 127.0.0.1 when Cambridge runs on the same host) |
port | Yes | RTSP port (typically 554) |
digest_authentication | No | Sub-table with username and password for RTSP digest authentication |
When digest_authentication is configured at the service level, it is used by default for all sessions to that service. Clients can override these credentials per-session using the digestAuthentication parameter in the rtsp.createSession call.
Global Service Settings
The [services] table supports global settings that apply to all services:
[services]
accept_invalid_certs = true # only for testing!
| Key | Default | Description |
|---|---|---|
accept_invalid_certs | false | When true, allows connections to services with self-signed or invalid TLS certificates. Use only for testing. |
Environment Variable Overrides
Any configuration value can be overridden using environment variables. The variable name is formed by:
- Starting with the
CAMBRIDGE__prefix. - Using double underscores (
__) as section separators. - Converting all keys to uppercase.
For example:
| TOML path | Environment variable |
|---|---|
signaling.nabto.product_id | CAMBRIDGE__SIGNALING__NABTO__PRODUCT_ID |
signaling.nabto.device_id | CAMBRIDGE__SIGNALING__NABTO__DEVICE_ID |
signaling.nabto.shared_secret | CAMBRIDGE__SIGNALING__NABTO__SHARED_SECRET |
signaling.nabto.private_key | CAMBRIDGE__SIGNALING__NABTO__PRIVATE_KEY |
Private Key in Environment Variables
When setting the private key via an environment variable, the PEM value must be base64-encoded:
export CAMBRIDGE__SIGNALING__NABTO__PRIVATE_KEY=$(cat private_key.pem | base64 -w 0)
During configuration loading, if the private key value does not start with -----BEGIN, it is automatically decoded from base64 before use.