---
Source: https://docs.microblink.com/on-prem/quick-start
Title: Quick start
Description: Quick start guide to deploying BlinkID Verify on your own infrastructure
---

# Quick start

The on-prem API runs as a single container image that bundles the API, the processing workers, and the machine learning models.
You can deploy it in your own cloud, or on your own hardware, using any OCI-compliant container runtime.

## Prerequisites

### License

You need a license key and an application ID.
Contact [sales](mailto:sales@microblink.com) to get a license.

### Only x86-64 ISA

The on-prem API does not support ARM processors, only x86-64 (AMD64) processors.

### Resources

Per container:

- Minimum: 2 CPU cores, 4 GB of memory
- Recommended: 4 CPU cores, 8 GB of memory

### Docker

This article uses Docker for image and container management, but you can use any other OCI-compliant tool.

Minimum Docker version: >= 20.10.5.

## Get the image

```bash
docker pull us-docker.pkg.dev/document-verification-public/on-prem/core:4000.0.0
```

## Run the container

```bash
docker run -p 8080:8080  \
  -e LICENSE_KEY={your_license_key} \
  -e LICENSE_APPLICATION_ID={your_application_id} \
  us-docker.pkg.dev/document-verification-public/on-prem/core:4000.0.0
```

## Make a request

You can now make your first request:

<ApiSample
  method="POST"
  url="http://localhost:8080/api/v3/verify"
  formData={[
    { name: "imageFirstSide", fileName: "front_id.jpg" },
    { name: "imageSecondSide", fileName: "back_id.png" },
  ]}
/>

{/* TODO 3: needs its own configuration page as the config surface is different for SH */}

See how to [configure](/verify/configuration) your requests, and learn how to [interpret the response](/verify/response).

## Going to production

The single `docker run` above is enough to get started.
For production, use the reference [Docker Compose](./docker-compose.md) or [Kubernetes](./kubernetes.md) deployment and:

- Set a memory limit.
  Overload protection is a percentage of the cgroup memory limit, and it's disabled when there is no limit, so the container can't reject requests before it runs out of memory.
- Run the container under a restart policy.
  It runs the API, the workers, and the model server as separate processes, and nothing restarts inside the container: if any of them exits, the whole container exits and needs to be brought back as one unit.
- Route traffic only after `/health/ready` succeeds.
- Add replicas when representative load testing shows that one container doesn't provide enough capacity.

See [Environment variables](./environment-variables.md) for the settings that control capacity, memory limits, and shutdown.


Last updated on Sep 11, 2026