> For the complete documentation index, see [llms.txt](https://doc.faceplugin.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.faceplugin.com/integration/deploy-and-host/architecture.md).

# Architecture

Faceplugin server architecture. Prefer Recognition + Liveness combined packages for eKYC, HTTP vs sdk.py, and what you store in your own systems.

Faceplugin ships product SDKs you combine in **your** mobile app or backend.

Faceplugin does **not** ship one all-in-one identity-verification app.

## Recommended: combined Recognition + Liveness

For production eKYC, prefer **combined** packages instead of running recognition and liveness as two separate Face (or Document) services:

| Need                                 | Prefer                                                                                                                                             | Avoid (unless you must split)                                                   |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| Face match + face PAD                | [Face Recognition + Liveness](/products/face-recognition-sdk/recognition-and-liveness.md) on **8083** (`faceplugin/face-recognition-liveness-sdk`) | Face Recognition **8083** + Face Liveness **8084** as two containers            |
| Document OCR + document authenticity | [Document Reader](/products/id-document-recognition-sdk/recognition-and-liveness.md) on **8082** with a Liveness-capable license                   | Document Reader **8082** + Document Liveness **8086** when you already need OCR |

Use standalone [Face Liveness](/products/face-recognition-sdk/liveness-detection-sdk.md) (**8084**) or [ID Document Liveness](/products/id-document-recognition-sdk/id-document-liveness-sdk.md) (**8086**) only when you want **anti-spoofing without** matching or OCR.

## Typical eKYC flow

**eKYC** means electronic know-your-customer / digital identity onboarding.

```mermaid
flowchart LR
  ID[ID capture] --> OCR[OCR and MRZ]
  OCR --> DocAuth[Document authenticity]
  DocAuth --> Selfie[Selfie]
  Selfie --> FaceCombined[Face match + liveness]
```

| Step                                           | Recommended product                                                                                                     |
| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Read the ID + check it is real                 | [ID Document Recognition + Liveness](/products/id-document-recognition-sdk/recognition-and-liveness.md) (port **8082**) |
| Check the selfie is live and match to ID photo | [Face Recognition + Liveness](/products/face-recognition-sdk/recognition-and-liveness.md) (port **8083**)               |

You own the final pass / fail decision. The SDKs return scores and fields. They do not decide your business outcome.

## Recommended topology

Run **one process or container per product**. For face and documents, that product should usually be the **combined** package.

```mermaid
flowchart TB
  subgraph customers [Your systems]
    MobileApp[Mobile or web app]
    Backend[Your backend]
  end
  subgraph faceplugin [Faceplugin on your infra]
    Doc8082[Document Reader :8082]
    Face8083[Face Recognition + Liveness :8083]
  end
  MobileApp --> Doc8082
  MobileApp --> Face8083
  Backend --> Doc8082
  Backend --> Face8083
```

Optional authenticity-only Document Liveness (**8086**) or Face Liveness (**8084**) only if you intentionally split services.

## One runtime per server

Each product is its **own** process or container. Each has its own `lib/cpu/` (or Hub image that already includes the runtime).

You do **not** install Document and Face into one App tree. To use both, run **two servers** (for example Document on **8082** and Face Recognition + Liveness on **8083**) and call both from your backend.

```
document-reader/          face-recognition-liveness/
  lib/cpu/   ← Document     lib/cpu/   ← Face only
  app.py                    app.py
```

{% hint style="danger" %}
Do **not** dump a second product’s Google Drive folder into another product’s `lib/cpu/`. OpenCV, OpenSSL, and ONNX builds differ; files overwrite each other and the process can crash or return wrong scores. Keep one Drive runtime per App / container.
{% endhint %}

The Face **Recognition + Liveness** package is already one product (one Drive / one image) with recognition and face PAD together. That is not the same as merging Document + Face into one folder.

## Who owns what

| You own                              | Faceplugin SDK owns                                |
| ------------------------------------ | -------------------------------------------------- |
| Template / person gallery database   | Face detect, quality, template extract, 1:1 match  |
| Document JSON storage and PII policy | OCR, MRZ, barcode, document authenticity scores    |
| Orchestration and business decisions | Face liveness / PAD score                          |
| TLS, reverse proxy, network access   | Engine processing inside your process or container |
| License request and key storage      | Offline activate after you install the key         |

A **template** is a face feature vector. Store it in **your** database. The server Face Recognition API has **no** `POST /api/identify` gallery.

## Two ways to integrate on a server

### Option A — HTTP sidecar

Run `app.py` or the Docker image. Call it from any language.

```
Your backend  →  HTTP API  →  sdk.py  →  lib/cpu
```

Use this when several services need the engine, or when your backend is not Python.

### Option B — In-process Python

Import `sdk.py` on the **same** host as `lib/cpu/` (or inside the container).

```
Your Python process  →  sdk.py  →  lib/cpu
```

Use this when you want fewer network hops and you already run Python next to the runtime.

**Gradio** (`demo` / `demo.py`) is a local UI for testing. Do not ship it in production. See [Production deployment](/integration/deploy-and-host/production-deployment.md).

## Mobile multi-SDK note

On mobile, keep each product’s AAR or frameworks separate. Request one license **per** application id **per** product. Call one engine at a time.

Face Liveness has no public Flutter or React Native SDK. Prefer Face Recognition + Liveness mobile apps (Identify includes 2D liveness), and/or a native Face Liveness module when you need PAD without matching.

### Related documentation

* [Hosting requirements](/integration/deploy-and-host/hosting-requirements.md) · [Production deployment](/integration/deploy-and-host/production-deployment.md) · [HTTP API](/integration/http-api.md) · [Choose a product](/getting-started/choose-a-product.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://doc.faceplugin.com/integration/deploy-and-host/architecture.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.