Skip to main content
Version: v2

Helm deployment

The Helm chart deploys the single-image container (API, worker, and models) on Kubernetes.

Prerequisites​

  • kubectl configured for your cluster
  • helm installed

For detailed setup instructions, see the environment setup guide in the doc-ver-ops repository.

You also need a license key and application ID from developer.microblink.com.

Installation​

Add the Microblink Helm repository:

helm repo add microblink https://helm.microblink.com/charts
helm repo update

Install the chart with a values file:

helm install my-release -f values.yaml microblink/doc-ver

Configuration​

License​

The chart expects a Kubernetes secret named license-key containing:

  • LICENSE_KEY
  • LICENSE_APPLICATION_ID

To create the secret manually:

kubectl create secret generic license-key \
  --from-literal=LICENSE_KEY=<your_license_key> \
  --from-literal=LICENSE_APPLICATION_ID=<your_application_id>

Alternatively, set auth.license.createSecret: true and provide the values directly in your values file.

Key values​

  • docVer.replicaCount: number of pod replicas (default: 1)
  • docVer.resources.limits.cpu: CPU limit per pod (default: 4)
  • docVer.resources.limits.memory: memory limit per pod (default: 8Gi)
  • docVer.resources.requests.cpu: CPU request per pod (default: 2)
  • docVer.resources.requests.memory: memory request per pod (default: 4Gi)
  • docVer.env.WORKER_COUNT: worker processes per container (default: 2)
  • docVer.env.API_TIMEOUT_SECONDS: request timeout in seconds (default: 30)
  • docVer.image.tag: container image tag (defaults to the current release version)
  • docVer.ingress.enabled: expose the service via ingress (default: false)
  • docVer.logFiles.enabled: write logs to /var/log in addition to stdout/stderr (default: false)

The full values reference is in the chart README.

Additional environment variables​

Inject extra environment variables via docVer.extraEnv:

docVer:
  extraEnv:
    - name: DocVerV2InflightLimit
      value: "4"
    - name: DocVerV2QueueLimit
      value: "0"

Logging​

Logs go to stdout/stderr by default, captured and rotated by the kubelet.

File logging can be enabled with docVer.logFiles.enabled: true. Log files live on an emptyDir volume; set docVer.volumes.varLog.sizeLimit to prevent node disk pressure from causing pod evictions. Prefer stdout/stderr with centralized log collection.

Throughput and scaling​

A single pod handles roughly 0.8 requests per second and around 70,000 requests per day. On average, a single verification takes 2–3 seconds.

Scale horizontally—avoid increasing WORKER_COUNT without also increasing resource limits.

Flat replicas​

Run a fixed number of replicas (typically a few to 10) for redundancy and handling peak loads. This is sufficient for most production workloads.

CPU-based HPA​

Configure HPA at 50–60% CPU utilization. Processing is CPU-heavy, so CPU-based autoscaling works well for variable loads.

Queue-based scaling with KEDA​

For large or highly spiky loads, place a queue (RabbitMQ, PubSub, etc.) in front and use KEDA with queue-depth metrics. This is the most efficient strategy for handling extreme spikes without over-provisioning.

Migrating from the multi-component chart​

  1. Uninstall the old release (API, Runner, and Model proxy charts separately)
  2. Create the new license-key secret with both LICENSE_KEY and LICENSE_APPLICATION_ID
  3. Update your values file to the new docVer structure
  4. Deploy the new chart and verify readiness at /health/ready
Last updated on