Edge Server Settings
The Settings section covers the small set of options that are configured on the device rather than in the cloud — the local admin password, the mTLS material that external systems use to authenticate to the Edge Server, and the LoRaWAN network server and gateway certificates.
Everything else (clients, variables, transforms, virtual variables, triggers, alarms, dashboards) is configured in ControlCom Connect and picked up automatically.
Security — Account
/settings/security/account changes the password of the local admin account that protects the web UI and the public REST API.
Form fields
- Current Password — required.
- New Password — required, minimum 6 characters.
- Confirm New Password — required, must match.
Click Change Password to commit. The change takes effect immediately; existing sessions remain valid until they expire naturally.
This is a local account, distinct from your ControlCom Connect cloud login. Use a strong password — the same Edge Server may be reachable on the LAN by anyone who can reach port 3041 or 3040.
Security — Certificates
/settings/security/certificates lets you download the Edge Server's mTLS certificate bundle as a single cert-bundle.zip. The bundle contains three files:
- rootCA.crt — the trust anchor (Certificate Authority) that signs everything else.
- client.crt — this Edge Server's client certificate, signed by the Root CA.
- client.key — the private key paired with
client.crt. Sensitive.
When to download it
- Configuring an external system (SCADA, custom integration, another Edge Server) to authenticate to the mTLS-protected API on port 3040 or the Sparkplug B broker on port 8883.
- Provisioning a developer workstation that needs to call the secure REST API.
Handling
Treat client.key the same way you would treat any other private key: never check it into source control, never email it, never share it across devices that are supposed to have distinct identities. If a key is compromised, regenerate the bundle by recycling the device (the server automatically regenerates mTLS material at startup whenever the configured SANs change — see the TRUSTED_DOMAINS and TRUSTED_IPS environment variables in Getting Started).
LoRaWAN — Network Server
/settings/lorawan/network-server configures the Edge Server's embedded LoRaWAN Network Server (LNS) and Application Server. Each Edge Server can host its own LNS, accepting traffic from Basic Station gateways via CUPS and LNS WebSocket protocols.
Form fields
| Field | Notes |
|---|---|
| Enabled | Master switch. When off, the LNS does not start and the CUPS / LNS endpoints are inactive. |
| NetID | 6 hexadecimal characters (e.g. 000000 for a private network). Used for OTAA session-key derivation and encoded into every issued DevAddr. |
Click Save to persist or Reset to discard pending changes.
Endpoints panel
Once enabled, the page shows the CUPS URI and LNS URI for every network interface available on the host, with a copy button next to each. Use these when configuring a Basic Station gateway:
- CUPS URI — the gateway's first contact, used to discover the LNS URI and exchange credentials. Example:
https://edge.local:443. - LNS URI — the long-lived WebSocket the gateway uses to send uplinks and receive downlinks. Example:
wss://edge.local:443.
LORAWAN_PUBLIC_HOSTNAME: when the Edge Server runs behind NAT (Docker bridge, Kubernetes ClusterIP, etc.), set the LORAWAN_PUBLIC_HOSTNAME environment variable so CUPS returns a hostname that gateways can actually route to. Also add that hostname to TRUSTED_DOMAINS so the wss handshake succeeds.
LoRaWAN — Gateways
/settings/lorawan/gateways manages the per-gateway mTLS certificates that Basic Station gateways present when they connect to the LNS. Gateways themselves are configured in ControlCom Connect (name, EUI, region); this page is where you mint, rotate, and revoke the certificates that go with them.
Trust Bundle
The Trust Bundle button (top right) downloads the LoRaWAN Root CA certificate. Install this on each gateway as the trust anchor for the LNS — gateways validate the server's TLS certificate against this CA.
Gateways table
| Column | Notes |
|---|---|
| Name | From platform configuration. |
| EUI | Gateway EUI (unique identifier burned into the radio). |
| Region | Regional plan, e.g. US915 with an optional sub-band. |
| Cert | None / Active / Revoked. |
| Issued | Date the current cert was created. |
| Expires | Date the current cert becomes invalid. |
Per-row actions (context-sensitive dropdown)
- Issue certificate — only when no cert exists. Generates a new key + cert and downloads the gateway bundle.
- Download bundle — when a cert exists, re-download the current bundle. (You will need the private key only once at provisioning — store it on the gateway and treat it as sensitive.)
- Rotate certificate — generates a brand-new key + cert, invalidates the previous one, and downloads the new bundle. Use this on a schedule or after a suspected key compromise.
- Revoke — when Active. Marks the cert as revoked; the gateway will fail mTLS on its next connect attempt. Use this when a gateway is decommissioned or has been physically lost.
- Delete cert record — removes the certificate record from the Edge Server. Does not touch the gateway's configuration in the cloud, only the local mTLS state.
Issuing or rotating a certificate writes the new key and cert to a single ZIP download. There is no way to retrieve a private key after the fact. If you lose the bundle, rotate to a new one — there is no recovery path that returns the old key.