Skip to content
FluxGate

Architecture

Rust control plane and edge evaluation

FluxGate separates administration from evaluation. The backend persists and streams flag state, while edge nodes handle low-latency decisions near application traffic.

FluxGate evaluation analytics dashboard showing evaluation traffic

Components

What runs where

Four services make up FluxGate. People work in the Admin UI, the backend keeps the truth, and edge servers answer your apps.

FluxGate components and how they connectPeople open the Admin UI, a browser app served by the UI server. It calls the backend over REST and WebSocket straight from the browser. The backend stores data in PostgreSQL and streams the feature set to edge servers over gRPC. Your apps evaluate flags on the edge server over OFREP; the edge sends evaluation events back to the backend in batches. Apps can also post metric events to the backend. CI jobs call the backend with a scoped token. Jira Cloud, an OIDC provider and TypeSafe Jev connect to the backend when you turn them on.YOUR SIDEFLUXGATEOPTIONALAdmin browserpeopleYour appsSDK or HTTPCI jobsscoped tokenAdmin UI:3000Edge server:8081 OFREPin-memory cacheBackend:8080 REST + WebSocket:50051 gRPCPostgreSQLflags, users, analyticsJira Cloudstatus changesOIDC providersingle sign-onTypeSafe JevAI judgmentsopens the appREST + WebSocketOFREPREST + tokengRPC streamevaluationeventsSQL
The Admin UI runs in the browser and calls the backend directly, so the backend address must be reachable from your browser. Your apps evaluate flags only on the edge server. The backend is the source of truth: it stores everything in PostgreSQL and streams the feature set to every edge server over gRPC. Evaluation events flow back to the backend in batches for the dashboards. Apps can also post metric events straight to the backend for experiments. Dashed boxes are optional integrations.

Evaluation flow

How an evaluation flows

From a flag request in your app to a data point on a dashboard, in six steps.

  1. 1App

    Ask for a flag

    Your app sends the flag key and the user’s context to the edge server: over OFREP with its SDK key, or over /evaluate, which answers as the edge’s own client.

  2. 2Edge server

    Check the caller

    On OFREP the edge checks the SDK key. A good key is cached for up to five minutes, so repeat calls skip the backend check.

  3. 3Edge server

    Find the rules

    It reads the flag from its in-memory copy and picks the stage for the client’s environment.

  4. 4Edge server

    Choose a variant

    Criteria run in priority order and the first match wins. A weighted split hashes the flag key with the bucketing key, so a user always lands in the same bucket.

  5. 5App

    Use the answer

    The response carries the value, the variant and the reason. Your code branches on it.

  6. 6Backend

    Record it

    The edge sends evaluation events to the backend in batches, about every 30 seconds by default. The dashboards read them.

Sync

How changes sync to edge servers

Each edge server loads a snapshot when it connects. After that the backend pushes every saved change down a gRPC stream, so a change reaches every edge of the team within moments, without a redeploy.

1 · Connect on start and on every reconnect

  1. Edge server to Backend

    Look up the client’s team

    which team does this client belong to?
  2. Edge server to Backend

    Open the stream

    signs in with the client ID and API key
  3. Backend to Edge server

    Snapshot of every team feature

    one message per feature
  4. Backend to Edge server

    Snapshot complete

    the edge drops features that are gone

2 · Live change every saved change

  1. Admin UI to Backend

    Save a change

    for example criteria, stage, approval, delete
  2. Backend

    Commit to PostgreSQL

    before anything is pushed
  3. Backend to Edge server

    Push the full feature

    to every edge of the team
  4. Edge server

    Update the cache

    replace it, clear cached results
The next evaluation on that edge uses the new rules, and OFREP responses carry a new ETag. The edge sends a heartbeat every 30 seconds and the backend answers it.

If the stream drops

The edge keeps answering from its last copy and stays ready while it holds flags. It reconnects after 1 second, doubling the wait up to 30 seconds, and loads a fresh snapshot. See Edge resilience.

If an edge falls behind

When an edge cannot keep up with the changes, the backend tells it so. The edge keeps its copy, reconnects and loads a full snapshot, which then removes the flags the backend no longer has.

Data flow

A release system in four loops

Each component has a clear job: author, synchronize, evaluate, and observe.

01

Admin control plane

React UI and REST APIs manage features, stages, contexts, teams, approvals, metrics, and settings.

02

Streaming update channel

The Rust backend publishes feature snapshots and incremental updates to connected edge nodes over gRPC.

03

Low-latency edge

Edge nodes evaluate requests from cached rules, deterministic bucketing, ordered criteria, dependencies, and sticky assignments.

04

Telemetry feedback

Evaluation events, assignments, and metrics flush back to the backend for dashboards, experiments, and rollout governance.

Runtime shape

Backend owns truth. Edge owns speed.

Feature updates move from the backend to edge nodes over long-lived gRPC streams. Evaluations use cached rules, criteria priority, deterministic bucketing, dependencies, and sticky assignment metadata.

Read the component guide in the docs
  • PostgreSQL-backed configuration and analytics
  • React UI for operations, approvals, and metrics
  • Edge REST and OFREP endpoints for applications
  • Evaluation events sent back in batches for dashboards

Build with ForgeOps LABS

Need feature flag delivery, platform tooling, or rollout automation?

FluxGate shows the kind of end-to-end software ForgeOps LABS builds: backend, UI, infrastructure, integration, and operational workflows.

hello@forgeopslabs.comForgeOps LABS