2026.2 OnPremises Load Balance Installation Guide for Windows

In this article, we provide instructions to install qTest components for 2026.2 OnPremises on different Windows server machines with a Load Balancer, then connect it to qTest Manager on another machine. Please read the instructions thoroughly before starting your installations.

About the Command Line Wizard

The qTest 2026.2 Command Line Wizard is a command line interface application that allows you to configure basic settings for qTest applications in your purchase package.

You should understand these Command Line Wizard characteristics before you begin:

• For each step, the installer will prompt you for a specific input value. After you provide a value, the installer will validate the input. If the value is incorrect, or additional permissions are required, an explicit error message displays so it’s easy to know how the input value should be corrected.

  • Default values display in square brackets [ ]. To use the default value, simply hit the Enter key.

  • Input values for yes/no questions, should be 'y', 'yes','n', 'no' (ignore case sensitive.) Any value other than those listed will be treated as a 'no.'

• To terminate the configuration at any time without completing it, press Ctrl+C.

  In the event, you cannot start the Command Line Wizard again after terminating the configuration, backup then remove the qTest.config file. Retry to start the Command Line Wizard again.

Before You Begin

These instructions are specific to deploying qTest applications on a Windows Server 2019/2022 environment. If you are installing qTest applications with load balancing on another Windows version, please consult our customer support.

Read the following:

• Get started with qTest 2026.2 OnPremises

• 2026.2 OnPremises Prerequisite Software for Windows

• Server Sizing Guide

• Select your OnPremises Systems and Deployment Model for Manager 2026.2

TLS Connections

Client connections for qTest and PostgreSQL will be configured to use transport layer security (TLS) by default. However, the option to use non-TLS (HTTP) connections is still available at your own risk. A self-signed certificate is provided for convenience, but Tricentis recommends a CA-signed certificate whenever possible.

Ports

Open the Ports for the prerequisite applications and qTest applications you are installing prior to any self-assisted installation or upgrade. You should only open the HTTPS ports if you plan to serve SSL from the application.

Prerequisite applications

Product	Port	Transport Protocol	Application Protocol	Source	Destination	Configurable
PostgreSQL	5432	TCP	TCP	qTest Manager, Insights, Sessions, Parameters	Database (PostgreSQL) Server	Yes
Elasticsearch	9200 (TCP) 9300 (if using ES Clustering)	TCP	HTTP	qTest Manager	Database (Elasticsearch) Server	Yes
Network File System (NFSV4)	2049	TCP/UDP	TCP/UDP	qTest Manager, Sessions	NFS	No

Native Linux and Windows

Product	HTTPS Port	HTTP Port	Transport Protocol	Application Protocol	Source	Destination	Configurable
Manager/API	443	80	TCP	HTTPS	Web Browser, API	qTest Manager Application Server/API Server	Yes
Sessions	8443	8080	TCP	HTTPS	Web Browser, API	qTest Application Server	Yes
Scenario	6443	6080	TCP	HTTPS	Web Browser, API	qTest Application Server	Yes
Insights	9443	9080	TCP	HTTPS	Web Browser, API	qTest Application Server	Yes
Parameters	5443	5080	TCP	HTTPS	Web Browser, API	qTest Application Server	Yes
Pulse	4443	4080	TCP	HTTPS	Web Browser, API	qTest Application Server	Yes
Launch	3443	3080	TCP	HTTPS	Web Browser, API	qTest Application Server	Yes

Please note that we strongly recommend that you use the HTTPS ports in your setup.

Application Checklist

You will need to gather the following information for each application prior to beginning the installation and configuration.

PostgreSQL 16.x - Must be installed and configured prior to qTest application installation. You must inst

• Hostname/IP

• Port

• Database Superuser - You can use the standard PostgreSQL user. If you require a separate user, it must have equivalent superuser permission. Your PostgreSQL setup must have superuser access, so you can't use managed PostgreSQL services that don't grant native superuser access. Learn more about the limitations of managed cloud PostgreSQL services in our Knowledge Base (opens in a new tab).

• Database Superuser Password

• TLS Certificate - The location of the TLS root certificate is required for installation. Make sure that the permissions and ownership allow the user installing qTest to access the path and certificate files recursively. For more information on PostgreSQL TLS connections, refer to the official documentation found at https://www.postgresql.org/docs/current/ssl-tcp.html.

Elasticsearch 7.17.x - Must be installed prior to qTest application installation

• Hostname/IP

• Port

• TLS Certificate - The location of the TLS root certificate is required for installation. Make sure that the permissions and ownership allow the user installing qTest to access the path and certificate files recursively. For more information on Elasticsearch TLS connections, refer to the official documentation found at https://www.elastic.co/guide/en/elasticsearch/reference/7.x/ssl-tls.html.

TLS Configuration

• qTest and PostgreSQL

  • Cipher suite - the list of cipher suites the program uses in the ssl_ciphers.config file.

    • The server uses a default set of cipher suites in the ssl_ciphers.config file, but you can edit the configuration file to provide your own. The configuration file contains cipher format examples and details on how to provide your own ciphers.

  • Certificate Authority (CA) Signed Certificate –Will be inserted into the qTest Java Keystore. Use PKCS #8 format. May be signed by an internal CA. Must have a fully qualified domain name and resolvable DNS alias, with valid creation and expiration dates. Use the absolute path to certificate location on the server. The user executing the qtestctl installation must also have read permission for this file and path recursively.

  • Private Key - Use the absolute path to certificate location on the server. The user executing the qtestctl installation should also have read permission for this file and path recursively. If a passphrase is used for the private key, make sure to have it available.

This information is only needed if you will be deploying with an SSL secured connection:

qTest Applications

• Certificate File (.crt) - absolute path to the certificate file on this server.

  • Location should not be inside the directory tree of the qTest application (i.e. /qtestctl). The user executing the qtestctl installation must also have read permission for this file and path recursively.

• Private Key (.key) - absolute path to the private key file on this server.

  • Location should not be inside the directory tree of the qTest application (i.e. /qtestctl). The user executing the qtestctl installation must also have read permission for this file and path recursively.

• Private Key passphrase

qTest Applications

• Manager

  • Port to be used for communications (HTTP or HTTPS)

  • Local Disk directory for attachment storage – Location should not be inside the directory tree of the qTest application (i.e. /qtestctl). The user executing the qtestctl installation should also have read permission for this file and path recursively.

    - OR -

    Amazon (AWS) S3 for attachment storage - Requires bucket name, access key, region, and secret key. For a procedure on setting up AWS S3 for attachment storage, refer to Create an AWS S3 Bucket for qTest Attachment Storage.

  • Directory to logging storage - Location should not be inside the directory tree of the qTest application (i.e. /qtestctl). The user executing the qtestctl installation should also have read permission for this file and path recursively.

  • Fully Qualified Domain Name, Hostname, or IP Address to construct the application URL – This must be resolvable outside of the server.

  • Secret key – You can generate the first key from the installation wizard. After you generate a secret key, make sure you save and use the same key for all of your qTest applications, on all instances.

  • Integration secret key – You can generate the first key from the installation wizard when you install qtestctl. After you generate a secret key, make sure you save this key in a safe place. You must use the same key for all nodes that run Manager or Launch during installation and upgrades.

• Sessions

  • Port to be used for communications (HTTP or HTTPS)

  • Storage type and location for resource files

    • Disk storage – Local disk, NFS, or NAS

    • Amazon S3 – Requires Bucket Name, Access Key, and Secret Key

  • Enhanced CSRF Security (Optional)

    • Resolvable URL and Port for qTest Manager

    • Resolvable URL and Port for qTest Sessions

    • Resolvable URL/Domain for external defect tracker (e.g. – JIRA)

  • Secret key – You can generate the first key from the installation wizard. After you generate a secret key, make sure you save and use the same key for all of your qTest applications, on all instances.

• Insights

  • Port to be used for communications (HTTP or HTTPS)

  • Directory for custom report and dashboard files - Location may be inside the directory tree of the qTest application (i.e. /qtestctl). The user executing the qtestctl installation should also have read permission for this file and path recursively

  • Enhanced CSRF Security (Optional) –

    This may affect Insights performance and features such as (Embedded Reports/Dashboard, Shareable Dashboard, and Rapid Dashboard)

    • Resolvable URL and Port for qTest Manager

    • Resolvable URL and Port for qTest Sessions

• Parameters

  • Port to be used for communications (HTTPS)

  • Secret key – You can generate the first key from the installation wizard. After you generate a secret key, make sure you save and use the same key for all of your qTest applications, on all instances.

• Launch

  • Port to be used for communications (HTTPS)

  • Fully Qualified Domain Name, Hostname, or IP Address to construct the application URL – This must be resolvable outside of the server

  • Integration secret key – You can generate the first key from the installation wizard when you install qtestctl. After you generate a secret key, make sure you save this key in a safe place. You must use the same key for all nodes that run Manager or Launch during installation and upgrades.

• Pulse

  • Port to be used for communications (HTTP or HTTPS)

  • Fully Qualified Domain Name, Hostname, or IP Address to construct the application URL – This must be resolvable outside of the server

  • Directory to logging storage - Location should not be inside the directory tree of the qTest application (i.e. /qtestctl). The user executing the qtestctl installation should also have read permission for this file and path recursively

  • Resolvable URL and Port for qTest Manager

  • Choose which version of the Pulse Executor to install

• Scenario

  • Port to be used for communications (HTTP or HTTPS)

  • Fully Qualified Domain Name, Hostname, or IP Address to construct the application URL – This must be resolvable outside of the server

  • Secret key – You can generate the first key from the installation wizard. After you generate a secret key, make sure you save and use the same key for all of your qTest applications, on all instances.

Install qTest Applications with a Load Balancing Model

Refer to the Server Sizing Guide to view different deployment model samples.

To use this sample load-balancing model, you'll need to install and configure multiple qTest applications using the same qTest Application Installation Package. For example, you'll have qTest Manager and Sessions application nodes on at least two separate servers, and you'll also install any satellite applications on a third server.

The sample below uses 7 servers:

• 1 load balancing server for Manager

• 2 qTest Manager + Sessions servers

• 1 qTest Satellite Application Server

• 1 qTest Manager API server

• 1 database server

• 1 shared storage server

• Server 1:  This is the server that load balances the two qTest Manager and qTest Sessions servers. We'll install and use NGINX on this server for that purpose.

• Server 2:  This is one of two qTest Manager Application servers.

  • qTest Manager application node: An instance of qTest Manager deployed in a Windows server

  • qTest Sessions application node: An instance of qTest Sessions deployed in a Windows server

  • NFS Client: Accesses the shared storage on the NFS Server

• Server 3: This is one of two qTest Manager Application servers.

  • qTest Manager application node: An instance of qTest Manager deployed in a Windows server

  • qTest Sessions application node: An instance of qTest Sessions deployed in a Windows server

  • NFS Client: Used to access the shared storage on the NFS Server

• Server 4: This is the satellite application server, which contains all applicable qTest satellite applications.

  • qTest Insights application node:  An instance of qTest Insights deployed in a Windows server

  • qTest Parameters application node:  An instance of qTest Parameters deployed in a Windows server

  • qTest Launch application node An instance of qTest Launch deployed in a Windows server

  • qTest Pulse application node:  An instance of qTest Pulse deployed in a Windows server. Make sure you know which version of the Pulse Executor you want to install.

  • qTest Scenario application node:  An instance of qTest Scenario deployed in a Windowsserver

• Server 5: This is used to handle API traffic.

  • An instance of qTest Manager deployed in a Windows server

• Server 6: This is the server that contains prerequisite applications, including PostgreSQL, Elasticsearch and the Shared Network Drive.

  • PostgreSQL: A database engine used to manage qTest Manager, Sessions, Parameters, Insights, and Launch. All application nodes must use the same PostgreSQL database.

  • Elasticsearch: A database engine used for enhanced search capabilities

  • Shared Server: A server that hosts shared components that are required to run qTest Manager and Sessions. It should be accessible from all application nodes to store attachments and search index. 

• Server 7 (Optional): This is the server that contains your shared storage. Depending on your setup preferences, you can install shared storage with other prerequisite applications on Server 6.

  • NFS Server (Network File Systems): Used to share directories and files with others over a network. We'll use NFS to manage and share files created by qTest Manager and Sessions applications deployed on the two qTest Manager and qTest Sessions servers.

  You will need to configure the application nodes with your load balancer. You can use any load balancing tools or services which are being used in your organization. Our sample uses HAProxy. Your team members will access qTest Manager via the URL in the application nodes as configured in the load balancer.

Setup Shared Network Drive and Install NFS Server

You will need to create a directory under a shared network drive which is accessible from all application nodes. Refer to Set up a shared directory using NFS (Windows) for instructions on setting up your shared network drive using NFS.

Install an Application Node

Installing an application node follows the same instructions as installing a qTest application on a single server. Refer to Download and Start the Installation Package for instructions on installing a single node. You can add as many nodes as you need.

Additional Configuration for Sessions Node in a Load Balanced Environment

If you meet ALL of the following conditions, please read Additional Sessions 2026.2 Load Balance Configuration Windows/Linux before restarting your server for an additional configuration step on your Sessions application node:

• Load balancing qTest Sessions 2026.2

• Using F5 Load Balancer

• Using Internet Explorer to access qTest Sessions

Restart Server

You will need to restart the server for the changes to take effect, then move on to installing the next qTest application.

Repeat Application Installations

You will need to repeat the steps in Download and Start the Installation Package and Install qTest Applications as a Windows Service for each server that contains one or more applications. (You can add as many application nodes as you need for your team size. In this example, we have 2 Manager and 2 Sessions application nodes.)

(Manager and Sessions Only) Server Requirements

Before you download the application installation package you will need to Install NFS Client for Windows on your Manager and Sessions servers. Use the NFS client to mount the shared folder, which you have set up in a Shared Server, to a local drive. The local drive will be used to configure qTest Manager and Sessions when you install it.

In our sample deployment model above, the application installation steps would need to be completed eight times: once for each application node:

• Server 2: qTest Manager application node, qTest Sessions application node and NFS Client.

• Server 3: qTest Manager application node, qTest Sessions application node and NFS Client. 

Setup qTest Manager Load Balancer

Now, it's time to load balance. You will need one server to install load balancing software.

• Server 1: qTest Manager Load Balancer

You will need to use any proxy tools (such as HAProxy, NGINX) which are available in your organization to configure the Load Balancer.

In our example, we will install and configure NGINX on a Windows server whose public IP address is 54.92.55.101.

Download NGINX

1. Access the Windows server where you will install NGINX.

2. Download NGINX 1.13.0 here.

3. Extract the downloaded NGINX package to C:\NGINX-1.13.0

Configure NGINX

1. Open the NGINX configuration file at C:\NGINX-1.13.0\conf\NGINX.conf

2. Edit the file as seen below (notice the highlighted configuration in bold).

#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/NGINX.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
upstream application_servers {
server IP address and port of server 2;
server IP address and port of server 3;
}
server {
listen 80;
server_name localhost;

#charset koi8-r;
#access_log logs/host.access.log main;


location / {
proxy_pass http://application_servers;
proxy_redirect http://$http_host $scheme://$http_host;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
}
}

Configure the Proxy Tool to Start at Windows Start Up

Our instructions below use NGINX as the sample proxy tool.

Create a batch file that will start NGINX when it is executed by following the steps below:

1. Navigate to the folder C:\NGINX-1.13.0\.

2. Create a file named startup.bat.

3. Enter the following information in the file start NGINX.exe.

4. Save and close the file.

5. Open Task Scheduler and select Create Basic Task in the Actions panel on the right.

   

6. On the Create Basic Task screen, enter Start NGINX in the Name field. Then select Next.

   

7. On the Task Trigger screen, select the When the computer starts option button. Then select Next.

   

8. On the Action screen, select the Start a program option button. Then select Next.

   

9. On the Start a Program screen, enter the following. Then select Next.

   • Program/script: C:\NGINX-1.13.0\startup.bat

   • Start in (optional): C:\NGINX-1.13.0

     

10. On the Summary screen, click Finish.

    

11. You will be taken back to the Task Scheduler screen.

12. Select the Task Scheduler Library item in the left panel. In the middle panel, locate the task you just created with the name "Start NGINX". Right click the item, and then select Properties from the right-click menu.

    

13. On the Properties window, select Change User or Group.

    

14. On the Select User or Group window:

    • Enter System in the Enter the object name to select field.

    • Select Check Names.

    • Select OK.

      

15. You will get back to the Properties window.

16. Check the Run with highest privileges check box. Then click OK.

    

17. You have finished setting up the load balancer with NGINX and configured it to load balance the two qTest Sessions instances.

Configure qTest Manager to Connect to qTest Applications

Follow the Configure qTest Applications guide to connect qTest Manager with the other qTest applications you installed. Load Balancing instructions are supplied for the applicable applications.

After setting up the Load Balancer, your users will access qTest Manager and Sessions using the URL configured in the Load Balancer. You should also verify that the applications can be accessed and working properly before performing the next and final step.