> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.datalab.to/llms.txt
> Use this file to discover all available pages before exploring further.
# Running the Container
> Getting our container up-and-running takes minutes.
Running Datalab's containers requires **a Google Cloud service account key** to pull the container image.
If the terms of your agreement require a license, we'll also provide **a license key.**
# License-enabled containers
Copy your license key, download the service account key, and [run the script in this Github repository to get up-and-running](https://github.com/datalab-to/datalab-on-prem):
```shellscript theme={null}
export DATALAB_LICENSE_KEY=your-license-key
export SERVICE_ACCOUNT_KEY_FILE=path/to/key.json
./run-datalab-inference-container.sh
```
# Kubernetes deployment (Helm)
A Helm chart is available for deploying the container on Kubernetes clusters. Contact [support@datalab.to](mailto:support@datalab.to) to receive the chart and values reference for your deployment.
# Fully-airgapped containers
A license key is not required to run a fully-airgapped container. If the terms of your agreement require a fully-airgapped container, we will provide:
* Access to private registries that contain those images.
* A Google Cloud service account key to pull images.
* Directions for how to run the container.
# [www.datalab.to](http://www.datalab.to) must be reachable
Our on-prem license requires that [https://www.datalab.to](https://www.datalab.to) is reachable in order to:
1. Activate and register your license with our servers.
2. Send usage metrics.
# Usage data sent to Datalab
License activation and usage heartbeats **do not send private data to Datalab.**
Our intent is to ensure compliance with our license and to easily support customers when they run into problems.
The container sends the following to our servers:
1. On container startup we activate your license. In that request, we send information about your hardware and OS available in `/proc` and `/sys` (in the container, not on your host).
2. At regular intervals we send usage heartbeats that contain:
1. The # of successful/failed inference requests completed since the last heartbeat
2. The # of inference requests submitted to the container over a recent time window
# I need a fully-airgapped deployment
We also support fully-airgapped deployments that do not require a license. [Get started by filling out this form.](https://www.datalab.to/contact)
Please reach out to us at [support@datalab.to](mailto:support@datalab.to) if you have questions.
## Hardware Requirements
| Container Type | GPU Required | Minimum VRAM | Recommended Use |
| --------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `marker` | Yes (CUDA) | 24 GB | Standard document conversion with Surya OCR |
| `chandra` | Yes (CUDA) | 80 GB | Full Chandra VLM for highest accuracy |
| `chandra-small` | Yes (CUDA) | 16 GB | Smaller Chandra variants (2B/4B models) |
| `chandra-us` | Yes (CUDA) | 40 GB | Chandra-compatible container using Gemma-4 26B weights — same API as `chandra`, for customers with model-origin or supply-chain requirements |
| `surya-us` | Yes (CUDA) | ≤ 16 GB | Lightweight Chandra-compatible container using the chandra-small-0.6 RL model (\~1.5 B parameters, \~3 GB bf16 weights) — for customers with model-origin requirements and limited GPU VRAM |
## Throughput and Timeout Settings
For Chandra and Chandra-US containers that bundle vLLM, set these environment variables on the container before starting it:
| Variable | Default | Purpose |
| -------------------------------- | ------- | ------------------------------------------------------------------------------------------------- |
| `VLLM_API_SERVER_COUNT` | `1` | Number of vLLM API frontend processes. Increase when frontend image processing limits throughput. |
| `VLLM_STATS_INTERVAL` | `10` | Seconds between throughput log entries; `0` disables them |
| `VLLM_REQUEST_TIMEOUT_SECS` | `120` | Timeout for one page inference attempt, in seconds |
| `VLLM_ERROR_RETRIES` | `3` | Retry budget for inference errors |
| `CHANDRA_REPETITION_MAX_RETRIES` | `3` | Retry budget for repetitive model output |
For `chandra-us`, `GPU_MEMORY_UTILIZATION` overrides the fraction of GPU memory reserved by vLLM. When unset, the GPU startup path chooses `0.8` on cards with up to 32 GB VRAM and `0.9` on larger cards.
Pass variables through your deployment's container environment configuration, then recreate or restart the container. Exporting them in your host shell only works if your launcher forwards them into the container. In Helm deployments with separate model services, configure the inference application and model server independently.
The page attempt budget is `1 + max(VLLM_ERROR_RETRIES, CHANDRA_REPETITION_MAX_RETRIES)`. Setting only `VLLM_ERROR_RETRIES=0` still permits repetition retries. To limit a page to one inference attempt of about 30 seconds, set both retry values to `0` and `VLLM_REQUEST_TIMEOUT_SECS=30`. This is an inference-attempt bound, not an end-to-end request deadline; queueing and document preparation add time.
## Health Check
Verify your container is running:
```bash theme={null}
curl http://localhost:8000/health_check
```
Expected response:
```json theme={null}
{"status": "healthy"}
```
## Next Steps
API reference for the on-prem container image.
Compare open-source and paid on-prem deployment options.
Try the cloud-hosted API for quick evaluation.
Understand HTTP error codes and troubleshooting steps.