Deploy the Edge

In one sentence

Run octet-edge on the Linux hop that terminates the browser connection, give it your credentials, and route the collector's apiUrl to it.

This is step 2 of three. You should already be embedding the collector; next you'll fetch the verdict.

The one rule: terminate the browser connection

Read this first

The edge reads a connection-level network-timing signal that is only meaningful when the edge is the hop where the browser's connection actually terminates. If a separate TLS-terminating CDN or load balancer sits between the browser and the edge, that signal reflects the intermediary, not the browser — and confidence drops.

The integration still works without it (the other signals carry the verdict), but you get the strongest result when the edge is the connection-terminating hop. Because this depends on your specific infrastructure, finalize the exact termination topology with Octet during onboarding — that's expected and normal. The per-server guides below show the trade-offs.

Run it

The edge is a single static Linux binary (get it here). It's configured entirely through environment variables:

PORT=8080 \
OCTET_URL=https://<your-octet-api-url> \
LICENSE=<your-license-key> \
  ./octet-edge-linux-amd64

Variable	Required	Purpose
PORT	–	Port to listen on (default 8080).
OCTET_URL	yes	Octet's API base URL — where the edge forwards. Octet gives you this.
LICENSE	prod	Your license key, presented to Octet as x-octet-license.
OCTET_CA_FILE	planned	Octet's CA certificate — pins and verifies Octet over HTTPS. For the planned mutual TLS; optional and inert until Octet provisions certs.
EDGE_CLIENT_CERT_FILE	planned	Your client certificate for mutual TLS to Octet. Planned hardening — not required yet.
EDGE_CLIENT_KEY_FILE	planned	The matching private key. Planned hardening — not required yet.

The edge forwards to Octet at OCTET_URL (use https://). Mutual TLS is planned hardening and not yet in force: the OCTET_CA_FILE / EDGE_CLIENT_CERT_FILE / EDGE_CLIENT_KEY_FILE variables are optional and inert until Octet provisions certificates — when set, OCTET_CA_FILE pins Octet over HTTPS and adding the client cert + key enables mutual TLS. Full reference: Edge Configuration.

Endpoints it exposes

Method	Path	Purpose
GET	/health	Liveness check — returns { ok: true, ... }.
POST	/v1/signals	The collector posts the signal bundle here; the edge forwards and returns a coarse result.
GET	/v1/ws	The latency channel the collector measures against.

The collector calls these relative to its apiUrl: with apiUrl: 'https://yourapp.com/octet', it posts to /octet/v1/signals and connects the WebSocket at /octet/v1/ws. Your server routes that prefix to the edge — see the per-server guides.

Pick your setup

The connection-level timing signal aside, the wiring is the same everywhere: route the browser's apiUrl traffic (including the WebSocket) to the edge, and pass through the source IP.

• nginx — reverse-proxy a path prefix to the edge.
• Caddy — reverse_proxy with automatic HTTPS.
• Cloud LB / CDN — AWS ALB/NLB, GCP, Cloudflare — and the termination caveat that matters most here.
• Standalone / container — systemd, Docker, or a Kubernetes sidecar; the edge terminates directly.

Where to go next

• Fetch the Verdict. Read the result on your backend.
• Edge Configuration. Every variable and endpoint.