---
title: "Infrastructure Requirements"
slug: "infrastructure-requirements"
updated: 2026-08-04T14:09:23Z
published: 2026-08-04T14:09:23Z
canonical: "help.hyperscience.ai/infrastructure-requirements"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.hyperscience.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Infrastructure Requirements

## Specifications

### Internet browsers

The table below lists the supported internet browsers for each version of Hyperscience.

| **Hyperscience version** | **Supported browsers** |
| --- | --- |
| v31 and earlier | Internet Explorer 11 and the latest version of Google Chrome |
| v32-v35 | Internet Explorer 11 and the latest versions of Google Chrome and Microsoft Edge |
| v36 and later | The latest versions of Google Chrome and Microsoft Edge |

For the best possible user experience, we recommend browser dimensions of at least 1280 x 720 pixels.

### Application servers

The requirements in this section apply to the VMs that run the Hyperscience application. For the requirements for Trainer VMs, see [Trainer](/deployment/docs/v43-1-new-infrastructure-requirements#trainer).

#### Operating system

The tables below list the supported operating systems for each version of Hyperscience.

**Ubuntu**

| **Hyperscience version** | **Supported Ubuntu versions** |
| --- | --- |
| v39.2 and earlier | 16.04, 18.04, 20.04, 22.04, and 24.04 |
| v40 | 18.04, 20.04, 22.04, and 24.04 |
| v41 | 20.04, 22.04, and 24.04 |
| v42 and later | 22.04 and 24.04 |

**RHEL**

| **Hyperscience version** | **Supported RHEL versions** |
| --- | --- |
| v28 and earlier | 7, 7.5, 7.7, and 7.8 |
| v30-v32 | 7, 7.5, 7.7, 7.8, and 7.9 |
| v33-v34 | 7, 7.5, 7.7, 7.8, 7.9, 8.4, and 8.5 |
| v35-v39.0.8 | 7, 7.5, 7.7, 7.8, 7.9, 8.4, 8.5, and later 8.x versions |
| v39.0.9-v39.2 | 7, 7.5, 7.7, 7.8, 7.9, 8.4, 8.5, later 8.x versions, and 9.x |
| v40 | 8.4, 8.5, later 8.x versions, and 9.x |
| v41-v42.2 | 8.10 and 9.x |
| v42.3 and later | 8.10, 9.8, 9.10, and 10 |

**Container environments**

The table below lists the supported container environments for each operating system.

| **Operating system** | **Supported container environments** |
| --- | --- |
| RHEL 7.9 and earlier | Hyperscience v37-v39.2 with trainers with GPUs: Docker 19.0.3 and later All other configurations of Hyperscience v37-v39.2: Docker 1.13 and later |
| RHEL 8.4 and later | Podman, as included in the GA (general availability) release of your RHEL version (3.3.1 at minimum) |
| Ubuntu 16.04 (LTS) and later 16.x versions | Hyperscience v37-v39.2 with trainers with GPUs: Docker 19.0.3 and later All other configurations of Hyperscience v37-v39.2: Docker 1.13 and later |
| Ubuntu 18.04 | Hyperscience v37-v40 with trainers with GPUs: Docker 19.0.3 and later All other configurations of Hyperscience v40 or earlier: Docker 1.13 and later |
| Ubuntu 20.04 | Hyperscience v41: Docker 25.0.4 and later |
| Ubuntu 22.04 and 24.04 | Hyperscience v41 and later: Docker 25.0.4 and later |

> [!WARNING]
> Use the version of Podman included in your RHEL release.
> 
> On RHEL, we support only Podman, at the version included in the general availability (GA) release of the RHEL version you are running. If you are running a different version and encounter an issue, we may ask you to return to the version included in your RHEL release before we can investigate.

Note the following:

- The container environment should be installed on all machines.
- The container environment can be called:
  - `docker-latest` or `docker` if you are using Docker.
  - `podman` if you are using Podman.
- The container environment's preferred storage driver is `overlay2`.

We support any Docker distribution that meets the requirements above. Examples include:

- Docker Community Edition (CE):
  - In v30 and later, Hyperscience does not support Docker installed via the Snap application package or via Snap Store. Hyperscience does not impose restrictions on where users run the installation command and unpack the Bundle, while Snap-installed Docker has tighter security permissions and only allows mounting Docker containers if the install path is under `/home`. To learn more about the Snap application package and Snap Store, see Snapcraft's [Install Docker on Ubuntu](https://snapcraft.io/install/docker/ubuntu) and [Snap Store](https://snapcraft.io/store).
  - RHEL 7 — see Red Hat's [Getting Docker in RHEL 7](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_containers/index#getting_docker_in_rhel_7).
  - Ubuntu — see Docker's [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/).
  - Docker CE can be obtained from either OS distribution repository packages or Docker's [download.docker.com](http://download.docker.com) repository.
- Docker Enterprise Edition (EE):
  - Docker EE can be purchased from Docker.

Hyperscience requires Docker Container Runtime, which we refer to as "Docker" on this site. Note that Docker offers other products, such as Docker Desktop and premium support, that are licensed by Docker but are not required for using Hyperscience. For any licensing and support arrangements for Docker, contact Docker's support team.

#### Local storage

Each VM's local storage requirements depend on your version of Hyperscience, as shown in the table below. These requirements are in addition to the space consumed by the OS.

| **Hyperscience version** | **Total local storage** | **Volume for downloading, extracting, and deploying the application (typically the root (** `/` **) volume)** | **Volume Docker or Podman is set up to use for the application image (typically located at** `/var`**)** |
| --- | --- | --- | --- |
| v42 and later | At least 400 GB | At least 300 GB | At least 100 GB |
| v41 | At least 300 GB | At least 200 GB | At least 100 GB |
| v40 and earlier | At least 150 GB | At least 90 GB | At least 60 GB |

Additional space is recommended to accommodate future expansion and operational flexibility.

> [!NOTE]
> To maximize the amount of available space, we recommend keeping no more than two bundles in your local storage.

#### CPU

- Intel x86_64 is a requirement.
- ARM is not supported.

#### VM CPU cores

The system requires a minimum of 8 CPU cores in each VM.

> [!NOTE]
> **Definition of "CPU cores"**
> 
> Note that in this article, we use the term "CPU cores" for:
> 
> - threads on Intel processors with enabled Hyper-Threading, and
> - virtual CPUs (vCPUs) on compute instances in cloud providers (e.g., AWS, GCP).
> 
> For example, a VM using 4 physical cores on an Intel processor with enabled Hyper-Threading would be using 8 logical cores (i.e., 8 threads) and is considered to have 8 cores. An AWS EC2 instance or a GCE instance with 8 vCPUs is considered to have 8 cores.

#### GPU

Application machines with GPUs are supported in deployments of Hyperscience v41 and later. Use of GPUs with v40 or earlier is not supported.

- An application machine with a GPU is required to use ORCA VLMs.
- The use of an application machine with a GPU is supported only for ORCA use cases.

> [!WARNING]
> The following requirements apply only to the application VM that runs ORCA and has a GPU.

| **Use case** | **Hardware requirements** | **Required drivers** |
| --- | --- | --- |
| ORCA VLMs | ≥ 24 GB of VRAM for inference ≥ 16 GB of RAM above the machine minimum ≥ 4 vCPUs ≥ 100 GB of local disk space above the machine minimum [v43.1 and later] ≥ 10 GB of disk space in `/dev/shm` Compute capability ≥ 8.0 (see NVIDIA's [CUDA GPU Compute Capability](https://developer.nvidia.com/cuda-gpus)) | **v41-v43.0** NVIDIA drivers ≥ 525 **v43.1 and later** NVIDIA drivers ≥ 580 |

The table below lists GPUs officially supported by Hyperscience. You may also be able to use other GPUs with comparable specifications. Contact your Hyperscience representative for more information.

| **GPU Type** | **Compute capability** | **GPU Memory** | **Hyperscience versions offering support** | **Notes** |
| --- | --- | --- | --- | --- |
| NVIDIA A100 | 8.0 | 40 GB / 80 GB | v42.0.13+ v42.3.0 and later |  |
| NVIDIA A10 | 8.6 | 24 GB | v42.0.13+ v42.3.0 and later |  |
| NVIDIA L4 | 8.9 | 24 GB | v42.0.13+ v42.3.0 and later | Typically, approximately 40% slower than the A10 |
| NVIDIA L40S | 8.9 | 48 GB | v42.0.13+ v42.3.0 and later |  |
| NVIDIA H100 | 9.0 | 80 GB | v42.0.13+ v42.3.0 and later |  |
| NVIDIA RTX PRO 6000 (Blackwell) | 12.0 | 96 GB | v42.0.15+ v42.3.2 and later |  |

To learn how to set up application machines with GPUs, see our "Enabling Application Machines with GPUs" articles for [Docker](https://help.hyperscience.ai/deployment/docs/enabling-application-machines-with-gpus-in-on-premise-docker-deployments) and [Podman](https://help.hyperscience.ai/deployment/docs/enabling-application-machines-with-gpus-in-on-premise-podman-deployments).

#### RAM

The system requires a minimum of 32 GB per VM.

#### Permissions

The Hyperscience application does not support the use of `fapolicyd` in Podman-based deployments. It does support SELinux, which provides similar security measures.

#### Database

Hyperscience supports the database options described below.

**PostgreSQL**

Hyperscience supports the community and enterprise (EnterpriseDB Postgres) editions of PostgreSQL, as well as Amazon RDS for PostgreSQL and Google Cloud SQL for PostgreSQL.

| **Hyperscience version** | **Supported PostgreSQL versions** |
| --- | --- |
| v28 | 9.5, 10.x, and 12.x |
| v30-v33.1.8 | 10.x and 12.x |
| v33.1.9-v34 | 10.x, 12.x, and 13.x |
| v35-v37 | 10.x, 12.x, 13.x, and 14.x |
| v38-v39.2 | 12.x, 13.x, and 14.x |
| v40 | 13.x and 14.x |
| v41 | 14.x, 15.x, and 16.x |
| v42 and later | 15.x, 16.x, and 17.x |

**Oracle**

Hyperscience supports Oracle and Amazon RDS for Oracle. All supported Oracle versions require DBMS_ALERT privileges.

| **Hyperscience version** | **Supported Oracle versions** |
| --- | --- |
| v28 and earlier | 12 |
| v30-v31 | 12 and 19c |
| v32-v33 | 12.2 and 19c |
| v34-v41 | 19c |
| v42 and later | 19c, 23ai, and 23c |

**Microsoft SQL Server (MSSQL)**

Hyperscience supports MSSQL and Amazon RDS for SQL Server. Service Broker must be enabled.

| **Hyperscience version** | **Supported MSSQL versions** |
| --- | --- |
| v30.0.5 and earlier | 2016 and 2017 |
| v30.0.6-v40 | 2016, 2017, and 2019 |
| v41 and later | 2017, 2019, and 2022 |

**Azure SQL Managed Instance**

Azure SQL Managed Instance is supported in Hyperscience v28 and later.

> [!NOTE]
> **Hyperscience does not support Azure SQL Database.**
> 
> Because Azure SQL Database does not support Service Broker, Hyperscience does not support Azure SQL Database.

> [!NOTE]
> PostgreSQL and MSSQL are the recommended database options. While we do support the use of Oracle, it is the least used option, and we may remove support for it in the future if usage decreases.

**Privileges required**

User DDL privileges are required for table and index creation and modification. Keeping these DDL privileges is required even after installing the Hyperscience application.

**HA/DR**

Architectures for the database are subject to our customers' policies and are managed by them; our application supports connecting to a single database host at a time.

> [!NOTE]
> Migrating existing data between different database types is not supported.

#### File storage

**Supported options**

- AWS S3 bucket
- Azure Blob Storage
- Google Cloud Storage
- A networked file store (like NFS or CIFS)

**HA/DR**

Architectures for the file store are subject to our customers' policies and are managed by them.

#### Load balancer

To achieve HA/DR goals for the application, we encourage customers to deploy the application on multiple VMs and to use a load balancer for web requests. To learn more about using a load balancer to distribute web requests, see [Load Balancer](https://help.hyperscience.ai/deployment/docs/load-balancer).

> [!NOTE]
> If you are configuring a load balancer, note that the application uses the `HTTP_HOST` from the request to generate some of its links.

**Load balancer health check URLs**

Hyperscience offers a Health Check Status API endpoint, which is designed to help you monitor the health of your system's components. If any component tested by the Health Check Status API is in an error state, the endpoint will return an error code. If you enter the Health Check Status endpoint as your load balancer's health check URL, an issue in one server will cause all servers to return an error code to the load balancer. This response will prevent traffic from being routed to your entire system, even if healthy servers are available. For this reason, **we do not recommend using this endpoint as your load balancer's test of overall system health**.

For more information on the Health Check Status endpoint, see our [API documentation](https://docs.hyperscience.ai/#health-check-status).

### Trainer

The *Hyperscience Trainer* runs separately from the main application and communicates with the main application via the API. The trainer supports select long-running tasks and very large file downloads and uploads that might otherwise negatively impact document processing time.

To learn more, see [Trainer Installation](https://help.hyperscience.ai/deployment/docs/trainer-installation-production).

#### Operating system and container environment

Trainer VMs run on the same infrastructure as application servers. The operating system and container environment requirements described in [Operating system](/deployment/docs/infrastructure-requirements#operating-system1) also apply to trainer VMs.

#### Storage

Trainer VMs have the same local storage requirements as application servers. For details, see the [Local Storage](/deployment/docs/infrastructure-requirements#local-storage1) section of this article.

Use **local storage** with the trainer. Do not use shared storage, especially if you have multiple trainers of the same version. Using shared storage may cause data to be overwritten and training jobs to fail.

#### Database

The trainer uses its own local PostgreSQL database, which comes pre-packaged with the Hyperscience bundle. You do not need to provision an external database for trainer VMs — the requirements described in [Database](/deployment/docs/infrastructure-requirements#database2) apply to application servers only.

#### VM CPU cores

We require 16 CPU cores in a trainer VM if you are processing Semi-structured documents. If you have only 8 CPU cores, you can expect 60-70% longer training times and an increased risk of out-of-memory errors during training, particularly on datasets with longer, denser documents.

#### RAM

The trainer needs 4 GB of RAM for each CPU core in a trainer VM. This will need to scale up proportionally when increasing Trainer CPU cores at a rate of 4GB of RAM for each additional CPU Core. Therefore, if you have a 16-core CPU, as described in [VM CPU cores](/deployment/docs/v43-1-new-infrastructure-requirements#vm-cpu-cores1), you can expect maximum performance with 64 GB of RAM.

> [!NOTE]
> In v42.3 and later, a minimum total of 64 GB of RAM is required.

#### GPU

Trainers with GPUs are supported in Docker, Podman, and Kubernetes deployments of Hyperscience v41 and later. Use of GPUs with v40 or earlier is not supported.

- A trainer with a GPU is required to train Long-form Extraction models.
- While GPUs are not required to train Field Identification or Table Identification models, you can use a trainer with a GPU to train these models.
- The training of other types of models with a GPU is not supported. However, you can train them with a CPU on a trainer machine that has both a GPU and a CPU.

Trainer GPU requirements depend on the types of models you want to use with the GPU.

| **Models being trained** | **Hardware requirements** | **Required drivers** |
| --- | --- | --- |
| Long-form Extraction (GPU required) or Field Identification (can use GPU or CPU) | **NVIDIA GPU** We used the NVIDIA Tesla T4 for our benchmarking. Other NVIDIA GPUs may perform slightly better or worse, depending on cores, RAM, and other factors. For more information on the T4's specifications, see TechPowerUp's [NVIDIA Tesla T4](https://www.techpowerup.com/gpu-specs/tesla-t4.c3316). To learn more about other NVIDIA GPUs, see TechPowerUp's [GPU Specs Database](https://www.techpowerup.com/gpu-specs/?mfgr=NVIDIA&sort=name). We've completed benchmark tests for **AWS's *g4dn.4xlarge* machine**, and we recommend that machine or one of comparable size. For more details on this machine, see AWS's [Amazon EC2 G4 Instances](https://aws.amazon.com/ec2/instance-types/g4/). | **v41.0.10 and later v41 versions** NVIDIA drivers ≥ 550.54.15 **v41.0.9 and earlier** NVIDIA drivers ≥ 550.30.02 |
| Table Identification (can use GPU or CPU) | **NVIDIA GPU** We used the NVIDIA Tesla T4 for our benchmarking. Other NVIDIA GPUs may perform slightly better or worse, depending on cores, RAM, and other factors. For more information on the T4's specifications, see TechPowerUp's [NVIDIA Tesla T4](https://www.techpowerup.com/gpu-specs/tesla-t4.c3316). To learn more about other NVIDIA GPUs, see TechPowerUp's [GPU Specs Database](https://www.techpowerup.com/gpu-specs/?mfgr=NVIDIA&sort=name). We recommend **AWS's *g5dn.4xlarge* machine** or one of comparable size. More information about this machine can be found in AWS's [Amazon EC2 G5 Instances](https://aws.amazon.com/ec2/instance-types/g5/). | **v41.0.10 and later** NVIDIA drivers ≥ 550.54.15 **v41.0.9 and earlier** NVIDIA drivers ≥ 550.30.02 |

To learn how to set up trainers with GPUs, see our "Enabling Trainers with GPUs" articles for [Docker](https://help.hyperscience.ai/deployment/docs/enabling-trainers-with-gpus-in-on-premise-docker-deployments) and [Podman](https://help.hyperscience.ai/deployment/docs/enabling-trainers-with-gpus-in-on-premise-podman-deployments).

## Sizing the system

Exact capacity planning requires details of anticipated document flow (see below) and is usually discussed with our Deployments team.

### Server capacity

The exact number of VMs required depends on the following factors:

- Peak hourly throughput
- Number of fields per page to be collected
- The split of Structured (forms) versus Semi-structured (invoices, checks, paystubs, bills, etc.) documents

Our system scales horizontally — doubling the number of machines doubles the processing capabilities. Additionally, Hyperscience is able to leverage a larger number of cores. The system will perform twice as fast on a 16-core 64 GB RAM machine as it will on an 8-core 32 GB RAM machine.

> [!NOTE]
> **Requirements for RAM and VM CPU cores**
> 
> To ensure optimal performance, the system requires a 1:4 ratio of the number of cores in a VM's CPU and the number of gigabytes of RAM in that VM. For example, if a VM has a 16-core CPU, that VM should have 64 GB of RAM.

Note that burstable-performance machines are not supported. Such machines are:

- AWS: T-series. To learn more, see Amazon's [Burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html).
- Azure: B-series. To learn more, see Microsoft's [B-series burstable virtual machine sizes](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes-b-series-burstable).
- Google Cloud: shared core. To learn more, see Google's [General-purpose machine family](https://cloud.google.com/compute/docs/general-purpose-machines).

The Hyperscience application is designed to consume 100% of its CPUs' resources. The nature of burstable-performance machines does not allow them to constantly utilize 100% of the CPUs' resources, which results in system slowness.

Directionally, a single 8-core 32 GB RAM machine will process approximately 15,000 Structured pages, with 20 fields per page, in 12 hours. Similarly, a single 8-core 32 GB machine will process approximately 7,000 Semi-structured pages, with 20 fields per page, in 12 hours. Large production set-ups might have 4-8 machines, across two data centers for high availability.

The following table gives an example of the recommended number of machines based on a few different peak hourly volumes and ratios of Structured versus Semi-structured documents. The table assumes an 8-core 32 GB RAM machine and approximately 20 extracted fields per page.

| **Document mix** | **1000 pages (peak hourly)** | **2000 pages (peak hourly)** | **4000 pages (peak hourly)** |
| --- | --- | --- | --- |
| **100% Structured** | 1 VM + 1 (trainer) | 2 VMs + 1 (trainer) | 3 VMs + 1 (trainer) |
| **50% Structured** **50% Semi-structured** | 2 VMs + 1 (trainer) | 3 VMs + 1 (trainer) | 5 VMs + 1 (trainer) |
| **100% Semi-structured** | 2 VMs + 1 (trainer) | 4 VMs + 1 (trainer) | 7 VMs + 1 (trainer) |

### Trainer capacity

The trainer uses the directory referenced by the `HS_PATH` environment variable for storage. Ensure that the directory is located on a partition with at least **100 GB of storage**.

If you plan on enabling Trainer Resiliency, which creates checkpoints for Training Data and Model training, you will need to ensure that there is **an additional 6 GB of storage** available. To learn more about this feature, see [Trainer Resiliency](https://help.hyperscience.ai/deployment/docs/trainer-resiliency).

### Database capacity

The size of the database store depends on:

- Daily volume of pages
- Number of fields per page to be collected
- Retention period before record deletion
  - The retention period is configurable by the user. Anywhere between 3 days and 60 days is common.

A typical set-up (15,000 TIFF files per day, deleted after 30 days) requires 30 GB of database storage. As storage is inexpensive, teams usually provision this with a buffer (100-200 GB).

### File storage capacity

The size of the file store depends on:

- Daily volume of pages
- Mix of file sizes and formats
- Retention period before record deletion

Directionally, a setup of 15,000 TIFF files per day, deleted after 30 days, requires approximately 1 TB of file storage.

A separate machine dedicated to handling resource-heavy tasks like training Identification models. It operates independently and connects to the main application through the API.

A packaged file that contains everything needed to install or upgrade the Hyperscience platform. It includes the application and all required tools, helping to streamline setup and upgrade processes.

The input used to teach machine learning models how to process documents accurately. Its structure depends on the model type:

- For **Classification models**, training data consists of uploaded document pages grouped by layout.
- For **Identification models**, training data includes manually annotated fields and tables to train the model to extract specific data points.

A construct in our system that performs specific tasks, like classifying documents, identifying fields, or extracting text. The model improves over time as it learns from more examples. Learn more in [Models](https://help.hyperscience.ai/latest/docs/models).