Verigram
Verigram
  • Docs
  • Changelog
  • Feature requests
  • Support portal
    • General technical information
    • Server Benchmarks
Docs / On premises

General technical information

General technical information

Server Hardware

  • Operating System: Most modern Linux distributions (e.g., Debian, Ubuntu, CentOS, Red Hat). Windows and macOS are supported via Docker for development purposes only; they are not recommended for production environments.

  • Backend Language: Primarily Python 3.11, with Node.js used for specific services.

  • Minimum CPU: 8-core CPU with support for instruction set extensions for parallel data processing (e.g., Intel AVX-512).

  • Minimum RAM: 10 GB.

  • Minimum Storage: 40 GB.

  • GPU: CUDA-enabled GPUs are supported but optional.

Database and storage requirements

MongoDB

The on-premises version of the application requires a MongoDB database cluster to store data, settings, and business logs.

Minimum Requirements:

  • Version: 4.2 or higher.

  • Storage Engine: WiredTiger.

  • Deployment: Replica set (3 nodes recommended).

  • Refer to the official MongoDB production notes for best practices.

Redis and Redis stack

The application requires a Redis database to serve as a cache for frequently used data and settings.

Redis Cache Requirements:

  • Version: 7.2 or higher.

  • CPU: 1 core.

  • RAM: 2 GB.

  • Disk: 10 GB.

Redis Stack (Vector Search):

Redis Stack provides additional features, such as Vector Search, for storing face embeddings and related metadata.

  • Version: 7.2 or higher.

  • RAM: ~6 GB per 1 million face embeddings.

  • High Availability: 3 nodes with 3 Sentinels recommended.

Note: In production, it is recommended to use separate Redis clusters for caching and vector search.

Persistence Configuration (Sample)

For the vector search cluster, you must implement persistence strategies that satisfy your business continuity needs.

The following configuration uses both RDB and AOF persistence to ensure data safety.

# RDB Snapshots
# Save if at least 1 key changed in 1 hour
# Save if at least 100 keys changed in 5 minutes
# Save if at least 10,000 keys changed in 1 minute
save 3600 1 300 100 60 10000
rdbcompression yes
dbfilename dump.rdb

# AOF Persistence
appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
appendfsync everysec
  • RDB: Provides periodic full snapshots. Data is compressed (rdbcompression yes) to save disk space.

  • AOF: Logs every write command for maximum durability and can be replayed during recovery. The AOF is synchronized every second (appendfsync everysec).

Object Storage

The on-premises version of the application requires S3-compatible object storage (e.g., MinIO). Each liveness session requires approximately 5–7 MB of storage. Please plan your total storage capacity based on the volume of liveness sessions you expect to process.

List of services

  • AppServer (VL2) - the primary service providing an API for resource management and auxiliary eKYC services. It processes all requests from the liveness Web and Mobile SDKs. Code name is VL2

  • Algos - a specialized service responsible for heavy computations and deep learning models; it is utilized directly by the VL2 service for processing.

  • Algos-slim - a specialized service responsible for lightweight computations and small machine learning models; it is utilized directly by the VL2 service for processing.

  • Worker (Webhooks) - a background service that handles outgoing webhooks and other asynchronous tasks to ensure system responsiveness.

  • Console - a web-based dashboard providing a user interface for managing and reporting on liveness and other active sessions.

  • AdminConsole - a dedicated administrative web application for managing tenants within the multi-tenant system.

  • CeleryBeat - a scheduler service that triggers periodic background jobs and scheduled tasks at defined intervals.

Output artifacts

Name

Storage Location

Estimated Size

Description

Face Embedding

Vector Database

~6 KB

Optional. A mathematical representation of the face used for matching.

Liveness Video

Object Storage

Up to 10 MB

Optional. The full video recorded during the session; size depends on quality settings.

Best Frame

Object Storage

~180 KB

The highest-quality individual frame extracted by the algorithm from the session.

Frames Archive

Object Storage

~4 MB

A compressed collection of specific frames selected during the liveness process.

Alternative Video

Object Storage

~100 KB

A lightweight video generated using only the selected sample frames.

PrevBackend API
NextServer Benchmarks
Was this helpful?