Docs / dflux EdgeGuard
ContactGet started

Architecture

dflux EdgeGuard terminates two protocol planes — SBI HTTP/2 and Diameter over TCP/SCTP — and feeds every request through a single shared filter chain before routing it to a producer. The chain swaps atomically on hot reload, so policy stays consistent across both planes.

The picture

Two listeners, one pipeline

Inbound traffic arrives on one of two listeners and is wrapped into a protocol-neutral request value before the filter chain runs. The same chain runs for both planes, so a deny decision in the policy filter blocks SBI and Diameter the same way. The chain is a fixed-order slice: authentication (only when oauth2_required is set), policy (always), one rate-limit filter per rate_limits[] entry, request-phase transformation (when rules exist), then the application-server filter when configured. Signature verification, when enabled, is appended last.

The chain order is fixed; there is no per-filter priority knob outside the chain — rules inside a filter have their own ordering (see Policy engine and Transformation engine).

Response stage

After the producer answers, the proxy runs a protocol-specific response stage before the answer goes back to the consumer:

  • SBI: a small response chain applies header stripping (e.g. Server banners), topology hiding (rewrite producer host references), and response-phase transformations.
  • Diameter: a single response filter applies response-phase transformations to the answer AVPs.

Configuration and hot reload

Policy rules, rate-limit rules, transformation rules, routing rules, producer configs, and NRF profiles all live in the control-plane store — the persistence layer. The EdgeControl gRPC admin surface mutates the store; the data path reads it.

A background worker in the proxy polls the store (default every 5 s) for changes. When something changes, the proxy rebuilds the request and response filter chains and swaps them in atomically. This is the hot-reload guarantee: configuration changes take effect with no restart, no request-path lock, and no dropped connections, and both the SBI proxy and the Diameter relay pick up the same chains — so policy stays consistent across protocols.

Storage

The proxy keeps a single control-plane store holding rules, transformation rules, routing rules, producer configs, and NRF profiles. It runs on SQLite (default) or PostgreSQL. Decisions are not written to a database; they are emitted as structured JSON logs you can ship to a log pipeline or SIEM (see Setting up observability). For production storage, see Using PostgreSQL.

Process layout

The proxy runs as a single binary. Inside that binary:

  • One SBI HTTP/2 listener (with h2c fallback).
  • One Diameter relay (TCP or SCTP) — optional, enabled in config.
  • One EdgeControl gRPC admin listener when admin.grpc_listen is set (commonly 127.0.0.1:9091, matching the d3x-edgectl -addr default). Empty leaves the admin surface down.
  • One background worker that polls the control-plane store.
  • Prometheus metrics at /metrics on the SBI listener, and also on the dedicated observability listener when observability.metrics_listen is set (required for Diameter-only scrapes). The admin gRPC port does not serve /metrics.

There is no external broker and no separate sidecar. d3x-edgectl talks to the daemon over gRPC (EdgeControl on admin.grpc_listen) — you can run it from the same host or anywhere with network reach to the admin port.

Where to go next