Skip to main content

Deployment Layouts

The unit of deployment is one Smart Corridor stack: the corridor services (Hub with its adapters, CIGS, CBS, the dashboard, optionally MCT) together with the vendored Face Matcher in the package's face-matcher/ folder, started together by start.sh on one host. Each stack has exactly one Face Matcher; the corridor services talk to it over face-matcher-network through the integration list only. One stack can still serve several physical units (corridor and e-gate lanes), distinguished by unit configuration.

Single stack​

The default layout for one site area: a single host runs the whole stack, cameras stream into its Face Matcher, and consumers connect to its /graphql endpoint on port 8090. This is the layout the First Deployment guide produces, and it carries most deployments — a stack with several cameras covers a multi-lane corridor or a bank of gates.

Multiple stacks with a Face Matcher Leader​

When a deployment outgrows one host — several terminals, distant halls, or independent checkpoints — add more stacks. Each stack keeps its own Face Matcher, and those Face Matcher instances run as Followers of one Leader using Face Matcher's Leader and Follower watchlist synchronization. Watchlists and subjects are managed on the Leader only: enroll a traveller once and every stack matches against the same data, while detection and matching stay local to each stack so a WAN outage never stops a lane. The Leader is a Face Matcher deployment of its own — it can be the Face Matcher of one of the stacks or a dedicated instance — and is configured on the Face Matcher side, not in the corridor files.

                 ┌─────────────────────────────┐
                 │   Face Matcher — Leader     │  ← watchlists & subjects managed here
                 └──────┬───────────────┬──────┘
          (watchlist sync)│             │(watchlist sync)
   ┌──────────────────────┴───┐   ┌─────┴────────────────────┐
   │ Smart Corridor stack A   │   │ Smart Corridor stack B   │
   │  Face Matcher (Follower) │   │  Face Matcher (Follower) │
   │  Hub + CIGS + CBS        │   │  Hub + CIGS + CBS        │
   │  dashboard (+ MCT)       │   │  dashboard (+ MCT)       │
   └──────────────────────────┘   └──────────────────────────┘
        cameras, lanes                 cameras, lanes

See Deployment Topologies and Multi-Server Deployment for the Face Matcher side of this layout.

Separately deployed Face Matcher​

The vendored copy exists so that one package installs everything. Because the corridor depends on Face Matcher only through its published integration list, the stated direction is to let the corridor services join an existing, separately deployed Face Matcher — one that is already operated for other purposes, or shared by several corridor stacks — instead of the vendored copy. Until that is released, plan on one vendored Face Matcher per stack.

Choosing a layout​

Start with a single stack and scale by stack count, not by stretching one stack across locations. Rules of thumb: one stack per site area that must operate autonomously; one Face Matcher Leader per deployment when there is more than one stack; integrations consume each stack's Hub endpoint (events are per stack), while enrollment targets the Leader. Hardware per stack is driven by camera count and processing type — see Hardware Requirements and Scaling.