Introduction

OpenProcessor is a self-hosted visual AI backend built on NVIDIA Triton Inference Server. One FastAPI service (api, port 4603) puts TensorRT-accelerated detection, face recognition, image/text embeddings, OCR and vector search behind a single REST API. An optional curation subsystem adds an active-learning dataset backend on top of the same models: ingest, clustering, review queues, VLM-assisted labeling, export, training, model comparison and promotion back into Triton.

It is licensed AGPL-3.0-or-later (see Licenses).

Capabilities

Area	Routes	Backed by
Object detection	/detect, /detect/batch	YOLO11 (EfficientNMS end2end engine, GPU NMS) and YOLO26 (NMS-free engine), side by side
Faces	/faces/detect, /faces/recognize, /faces/verify, /faces/search, /faces/identify	SCRFD-10G (boxes + 5-point landmarks) and ArcFace (512-dim)
Embeddings	/embed/image, /embed/text, /embed/batch, /embed/boxes	MobileCLIP2-S2 image and text encoders (512-dim)
Visual search	/search/image, /search/text, /search/face, /search/ocr, /search/object	OpenSearch k-NN
OCR	/ocr/predict, /ocr/batch	PP-OCRv5 detection + recognition, orchestrated by a Triton Python-backend (BLS) model
Combined analysis	/analyze, /analyze/batch	All of the above on one image
Ingest	/ingest, /ingest/batch, /ingest/directory	Indexes global, face, object and OCR documents into OpenSearch
Curation	everything under /curation; data routes under /curation/projects/{project}	PE-Core embeddings, your own detector, an optional VLM, segmenter and trainer

Every core route is also mounted under /v1 (for example /v1/detect). The /curation surface has a single, unversioned prefix. See the API reference.

How the pieces fit

• triton-server serves every model from models/ in explicit model-control mode, so models load, unload and get promoted at runtime.
• api does request validation, preprocessing, orchestration and response shaping, and talks to Triton over one shared gRPC client so concurrent requests reach Triton's dynamic batcher together.
• opensearch stores vectors and metadata for search, and each curation project's image, item, class and config indexes.
• Opt-in compose profiles add the curation workers, a SAM 3 segmenter, an in-compose vLLM VLM, a trainer with MLflow, and a monitoring stack.

Which services each compose profile starts is on Compose profiles; the diagrams of how they fit together are on the Architecture page.

The curation subsystem

The curation subsystem is domain-agnostic: nothing about "what an item or a region of interest is" is hardcoded. It is bring-your-own-model: you supply the item detector, and optionally a VLM, a region detector and training data. It ships opt-in behind the curation compose profile and, like the rest of the API, has no authentication. v0.6.0 keeps no compatibility shims: a renamed environment variable is rejected at startup, not translated.

What a deployment configures, and where:

• Projects are isolated dataset workspaces. Each has its own classes, items, settings, exports and job state, and all curation data routes are under /curation/projects/{project}/. A project can be archived, cloned for its settings, and combined with others. See Projects.
• Per-project configuration is stored with revisions and rollback: prompt packs, region profiles, the active VLM endpoint, keymaps and strategy defaults. See Settings and config store.
• Regions are sub-objects inside an item. An item carries a list of boxes, each with its own state, text and embedding. See Multi-box regions.
• VLM endpoints are registered once per deployment and activated per project, including a local model catalog. See VLM selection.
• Existing data comes in through dataset import (YOLO, COCO, or an OpenProcessor export), and one /reprocess route re-runs stages over it.
• Deployment settings (ports, GPUs, model names, mounts) are environment variables; see Configuration.

The wheel example walks the whole path on public data, and Use your own domain shows what to change for yours. See also Vision and goals and the curation workflow.

Frontends

Every route works from curl, httpx or a client generated from contracts/openapi/curation.json. Cropwright is the optional SvelteKit labeling frontend for the /curation API. It lives in this repository (frontend/), has its own section of these docs, and can be installed or used on its own; some screenshots in these docs were captured from it. It is not required to use OpenProcessor.

Requirements

• An NVIDIA GPU with 8 GB+ VRAM (Ampere or newer), 16 GB RAM, 16 CPU cores at minimum; see GPU sizing.
• Docker with Compose v2 and the NVIDIA Container Toolkit.
• Roughly 30-60 minutes on first start for one-time TensorRT compilation; later starts take seconds.

Next: Choose your path to pick between the inference API and curation, then the Quick start.