Skip to content

IDV Installation

This section describes how to install and deploy the IDV Platform, including its dependencies, internal services, and recommended deployment strategies.

Architecture Overview

IDV is a set of interconnected services that integrate with Regula Document Reader API and Regula Face API. Its modular design allows for flexible deployment — from a single instance setup to distributed high-availability environments.

External Dependencies

Ensure the following third-party components are available before deploying IDV.

Dependency Description Options Requirement
Database Stores primary data for all services. MongoDB 4.4+ / MongoDB Atlas (recommended) Required
Message broker Handles asynchronous communication and background job processing. RabbitMQ / AmazonMQ 3.x+ / Kafka 3.7+ / Redis / Valkey 7.0+ Required
Storage Stores files, images, and processing results. S3 or S3-compatible (MinIO) / Local file system (NFS) Required
Vector database Supports similarity search and vector-based queries (needed for the Profile module). OpenSearch 2.19.0+ / MongoDB Atlas Optional
Document service Provides document data extraction (needed for document processing). Regula DocumentReader 8.1+ Optional
Face service Enables face detection, matching, and liveness checks. Regula FaceAPI 7.1+ Optional
Metrics server Collects metrics (StatsD protocol) for monitoring, observability, alerting. Prometheus / statsd_exporter Optional

Internal IDV Services

Service Description Scaling out Scale metrics Hardware (per instance)
API Main HTTP entry point, proxies requests to other services. Yes idv_api_http_duration, idv_api_http_request_total CPU: 2 vCPU
RAM: 2 GiB
Workflow Executes workflows and coordinates communication between services. Yes Queue size, processing delay CPU: 2 vCPU
RAM: 2 GiB
Scheduler Executes scheduled tasks (data cleanup, workflow reload, periodic jobs). No - CPU: 1 vCPU
RAM: 1 GiB
Audit Logs all significant system events. No - CPU: 1 vCPU
RAM: 1 GiB

Special Requirements

  • The Face Processing Service should run on a GPU for optimal performance.
  • The GPU mode is memory-intensive; it is recommended to prioritize larger GPU memory over raw compute performance.

Recommended setup (observed in production):

  • AWS EC2 with NVIDIA Tesla T4 GPUs
  • 16 GB GPU memory → supports up to 4 parallel workers

Deployment Options

Single instance setup

A minimal setup can run all services on one machine using Docker Compose.

Prerequisites:

  • Valid license file in the same directory as docker-compose.yaml.
  • Prepared IDV config (config-idv.yaml) and Document Reader config (config-reader.yaml).
  • Integration with Face Processing Service and Document Reader with sessionAPI enabled.

Configuration files:

  • config-idv.yaml — shared IDV configuration.
  • config-reader.yaml — Document Reader configuration.
  • docker-compose.yaml — deployment file.

This setup is suitable for development or demo environments.

Distributed environment setup

For production-grade deployments, IDV should be deployed in a distributed environment to ensure high availability, scalability, and fault tolerance.

Key benefits:

  • Fault isolation between services
  • Flexible scaling of heavy-load components
  • Improved performance under high traffic
  • Easier observability and monitoring

Recommended architecture includes:

  • API — entry point for all traffic
  • Face Processing Service — GPU-enabled nodes
  • Document Reader Service — independently scalable
  • Message broker — RabbitMQ, AmazonMQ, or Kafka
  • Databases — MongoDB Atlas + optional Vector Search (OpenSearch)
  • Storage — S3 or NFS
  • Monitoring — Prometheus-compatible metrics

Deployment considerations:

  • Deploy each service in dedicated containers or Kubernetes Pods.
  • Use load balancers for traffic distribution.
  • Use persistent volumes and managed storage (MongoDB Atlas, S3).
  • Configure metrics and alerts per component.

AWS Cloud setup (HA)

For high availability (HA), IDV can be deployed on AWS with managed services:

  • Database: MongoDB Atlas
  • Message broker: AmazonMQ
  • Container orchestration: Amazon EKS (with Karpenter)
  • Storage: S3
  • Vector database: MongoDB Atlas

This setup leverages AWS-managed infrastructure for scalability, resilience, and fault tolerance.