--- title: "Hyperscience Virtual Machine Prerequisites" slug: "hyperscience-virtual-machine-prerequisites" updated: 2026-08-04T14:16:54Z published: 2026-08-04T14:16:54Z canonical: "help.hyperscience.ai/hyperscience-virtual-machine-prerequisites" --- > ## 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. # Hyperscience Virtual Machine Prerequisites ## Introduction ### Purpose This article outlines the prerequisites necessary to setup the virtual machines (VMs) on which you will install the Hyperscience Application and Trainer. It is oriented toward the System Administrators who will perform this task. After you complete these steps, you can provision the VMs by following steps given in the [Technical Installation / Upgrade Instructions](/deployment/docs/technical-installation-upgrade-instructions). ### Scope This article is valid for both the Hyperscience Application and Trainer, whether you are installing them for the first time or are adding more machines to an existing cluster. In the most common use case, the following items need to be provisioned and considered as part of the setup for both the application and the trainer VMs: - Disabling swap - Containers - Folders - Opening ports ### Before you begin… Prior to preparing the VMs, make sure you review our [Infrastructure Overview](/deployment/docs/infrastructure-overview) and [Infrastructure Requirements](/deployment/docs/infrastructure-requirements). Take special note of the [Server](https://help.hyperscience.com/deployment/docs/infrastructure-requirements#servers) section, which gives more information about what is supported and required. If you are planning on installing Hyperscience on multiple VMs, make sure you have the same setup on all of them. Also, make sure you are either a root user or that you have elevated root-level permissions (i.e., you can execute `sudo` commands) on the machines that will be running Hyperscience. ## Prerequisites ### Disable swap space Hyperscience is built with resilience in mind, meaning that it can restore itself to a functioning state when the OOM (out-of-memory) killer kicks in and reclaims memory. When swap is enabled, the system uses it once no free memory remains. Processing times slow down substantially, and it becomes difficult to identify what is causing the slowdown. For this reason, you must disable swap on all VMs running the application and the trainer. You can follow the steps below, but also consult your host OS documentation for the precise steps for turning swap off. To disable swap until the next system reboot, run: ```bash sudo swapoff --all ``` To disable swap permanently, take the following steps: 1. Comment out any swap entries in `/etc/fstab`: ```bash sudo sed -e '/swap/ s/^#*/#/' -i /etc/fstab ``` 2. Find the swap target and mask it: ```bash sudo systemctl list-unit-files   #locate the swap target sudo systemctl mask swap.target ``` You should see output similar to the following: ```bash Created symlink /etc/systemd/system/swap.target → /dev/null. ``` 3. Confirm that the target is masked: ```bash sudo systemctl status swap.target # ● swap.target #      Loaded: masked (Reason: Unit swap.target is masked.) #      Active: active since Tue 2025-05-13 11:02:07 UTC; 2 weeks 2 days ago ``` > [!WARNING] > **The installation script checks whether swap is enabled** > > If swap is still enabled when you run the `run.sh` script, the script stops and returns an error. For more information, see [Technical Installation / Upgrade Instructions](/deployment/docs/technical-installation-upgrade-instructions). ### Containers - Docker/Podman Depending on the OS of the VM, you need to install either Docker or Podman on each of the machines running Hyperscience. Refer to the official installation documentation for your operating system: - RHEL 7 — 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) - RHEL 7 is not supported for v40 and later. - RHEL 8 — [Configuring Podman in RHEL 8](https://help.hyperscience.com/deployment/docs/configuring-podman-in-rhel-8) - Ubuntu — Docker’s [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/) > [!WARNING] > ***fapolicyd* not supported with Podman** > > The application does not support the use of `fapolicyd` in Podman-based deployments. It does support SELinux, which provides similar security measures. ### Folders #### Installation folder You will need to set up a folder on the VMs where the Hyperscience installation bundle will be downloaded and unpacked. We will refer to this folder as the “Hyperscience installation folder.” Our recommendation is to create it inside `/opt/hs`, but you may choose to set it up elsewhere. To create the folder, run the following command in the shell: ```bash mkdir /opt/hs ``` #### Data folder ​​In addition to the installation folder, you need to create a directory where the application will store additional files. We recommend creating `/mnt/hs` and using it as the directory for these files: ```bash mkdir /mnt/hs ``` Depending on where you set your data folder, this location corresponds to the `HS_PATH` environment variable. If you set it according to the recommendation above, record this value to add to the “.env” file when installing the product: ```bash HS_PATH=/mnt/hs/ ``` > [!NOTE] > If `HS_PATH` is not set explicitly, Hyperscience will use the default value of `/mnt/hs/`. #### File storage **Application VM** If you have chosen to use [Network-attached File Storage](/deployment/docs/network-attached-storage-or-local-storage) for your file store (see [Hyperscience Infrastructure Prerequisites](https://help.hyperscience.com/deployment/docs/hyperscience-infrastructure-prerequisites#file-store)), you need to create this directory by running the following commands: ```bash # considering HS_PATH=/mnt/hs mkdir -p /mnt/hs/media chown 1000:1000 /mnt/hs/media ``` Then, you need to mount that file storage under the `$HS_PATH/media` location on all application VMs. If you are using RHEL with SELinux, check to make sure you gave the mounted directory the necessary permissions, as explained in [Network-attached File Storage](/deployment/docs/network-attached-storage-or-local-storage). If you have chosen to use any of the other three storage options ([S3 Cloud Storage](/deployment/docs/s3-cloud-storage), [Azure Blob Storage](/deployment/docs/azure-blob-storage), [Google Cloud Storage](/deployment/docs/google-cloud-storage)), no additional mounting is required. **Trainer VM** > [!NOTE] > **The trainer uses only local folders for file storage** > > Unlike the application file storage, the trainer must use a local directory called `trainer_media` under `HS_PATH` for its file store. Even when using multiple trainers connected to the same environment, each trainer has its own local file storage. To create the local directory, run the following commands: ```bash mkdir -p /mnt/hs/trainer_media chown 1000:1000 /mnt/hs/trainer_media ``` ### Opening ports The application’s web user interface will be exposed on port 80 (or port 443 if you are using SSL/TLS), so the respective port must be open in any firewall that may be enabled. If you need to check settings and open port 80, run: **Ubuntu** ```bash sudo ufw status   #show the status of the firewall - enabled or disabled sudo ufw app list #lists the configured, or opened ports by name sudo ufw allow 80 #enables open service on port 80 sudo ufw reload   #reloads configuration after changing rules ``` **RHEL** ```bash sudo firewall-cmd --list-all  #show currently applied rules sudo firewall-cmd --zone=public --add-port=80/tcp --permanent  #adds exception to allow port 80 to accept traffic sudo firewall-cmd --reload ``` If you are using SSL/TLS, replace `80` with `443` in the above commands. From outside the server, you must be able to receive HTTP replies from our software at `<external hostname or IP>:80` or `<external hostname or IP>:443`.