System requirements#

This page lists what a server needs to run Reportworq: the operating system and hardware, the browser used for the admin console, and the network and firewall requirements. Reportworq runs on Windows Server and on Linux. Confirm these before you install, since the most common "jobs cannot read or write" and "cannot reach the server" problems trace back to the network and service-account setup rather than the software itself.

To decide which deployment shape fits your environment (Windows, Linux, or a container), see Deployment topology.

Operating system#

Hardware#

Browser window size#

The Reportworq web interface is designed against the size of the browser window, not the size of the monitor. Those are usually different, and the difference is larger than most people expect, so size the window rather than assuming a large monitor is enough.

Minimum 1280x720. Recommended 1920x1080. Below 1280 wide, some screens become cramped and wide tables are harder to read.

Three ordinary things make a browser window smaller than the monitor it is on:

• Display scaling. Windows scaling shrinks the usable area the browser reports. A 1920x1080 monitor at 150% scaling gives the browser 1280 pixels of width; at 125% it gives 1536. Enterprise laptops are frequently scaled by default, so a 1080p screen often behaves like a 1280-wide one.
• Browser toolbars. Tabs, the address bar and the bookmarks bar take roughly 90 to 140 pixels of height. A 1366x768 laptop screen leaves about 630 pixels of usable height.
• Windows that are not maximized. Running Reportworq beside Excel or Teams on a wide monitor halves the width available to it.

Reportworq's own navigation rail takes a further 280 pixels of width, which does not change with the window size. Collapsing the rail with the menu button at the top left returns about 170 pixels, which is worth doing on a narrow window or when working with a wide table such as Run History.

If the window is very small, Reportworq shows a banner telling you so. Widening the window, maximizing it, or collapsing the navigation rail resolves it.

Additional requirements on Linux and in containers#

The Linux tarball and the container image bundle the .NET runtime, so no runtime prerequisite is installed on the host. CPU, RAM, and disk are the same as on Windows. Two host-level items are specific to Linux.

Linux is at feature parity with Windows. There is no capability a customer uses that the Linux build lacks. The only piece not built for Linux is the Windows service host, which is a launcher and is replaced by the systemd unit or the container entry point.

Running version 5 and version 6 on the same server#

Reportworq 5 and Reportworq 6 can run side by side on the same machine. Version 6 installs into its own folder (C:\Program Files\Reportworq 6 by default) and listens on its own default port, so it does not collide with an existing version 5 installation, which keeps its own folder and its own default port.

This is what makes a staged migration practical: you can stand version 6 up next to a running version 5, move content across, and validate before decommissioning anything. When you are ready to bring version 5 content over, use the import path rather than pointing version 6 at a version 5 repository, see First-run setup.

Network and firewall#

Reportworq hosts its web application and job runtime on a single service. Two TCP ports must be open in the firewall on every server that runs Reportworq, including each load-balancer node in a cluster. The port numbers below are the Windows defaults; on Linux and in containers the default web port is 8080 and the Event Hub follows on 8081.

The default web port is 8600 (with the Event Hub on 8601). Earlier releases defaulted to 8300, and Reportworq 6 uses 8600 so it can run alongside an existing Reportworq 5 on the same server without a port conflict. If you are upgrading from v5, are not running v5 and v6 side by side, and your firewall is already open for 8300, you can change the web port back to 8300 in Server configuration; the Event Hub port then follows as 8301.

Warning: opening only the web port is a common mistake. Local access on the server works immediately, but a cluster that opens only the web port will connect while its real-time coordination fails silently. Open both 8600 and 8601 on every server. If you change the web port later in Server configuration, the Event Hub port moves with it (web port plus one).

Local access on the server works as soon as the service is running. Remote access is blocked until you add an inbound-allow firewall rule for the web port. After adding the rule, test remotely with the server's name and port, for example https://<computername>:8600.

The server also needs outbound internet access during installation, configuration, and use, for license activation, updates, hosted AI, and CloudHub. For an air-gapped server, see the offline activation path in Install Reportworq.

HTTPS out of the box#

On a fresh Windows on-premises install, Reportworq turns on HTTPS automatically at first boot. It generates a self-signed certificate, trusts it on the server, and enables SSL before you sign in, so the first browse to the server is https://localhost:8600 and local access on the server works right away because the certificate is already trusted there.

• Remote browsers do not trust a self-signed certificate until you distribute the trusted-root certificate to them.
• For production, replace the self-signed certificate with one from a trusted certificate authority.

For the certificate actions, see Server configuration.

This automatic step is Windows-only and fires only on a genuinely new install. Linux and container hosts do not self-provision a certificate; enable HTTPS there through configuration or a TLS-terminating reverse proxy, see Deployment topology.

HTTPS is required for the Excel add-in and Microsoft 365#

HTTPS is mandatory for the Excel add-in and for every Microsoft 365 feature (Entra sign-in, SharePoint, Microsoft 365 email, and Teams distribution). Over plain HTTP, add-in sign-in and the Graph-based integrations will not work, and they fail quietly rather than reporting an error. Because a fresh Windows install already serves over HTTPS (see above), these features work from the first boot on Windows; on Linux and container hosts, make sure HTTPS is configured before you rely on the add-in or Microsoft 365 features.

Notes and limits#

• The MSI installer and the Windows service are Windows-bound. The Linux tarball and the Docker / Azure App Service container image run the same application with no installer and no Windows service, see Deployment topology.
• The RAM figure is a stated requirement, not enforced by the software at startup. As a rule of thumb, allow about 2 GB per concurrent job on top of the base. The default is 4 concurrent jobs, and the concurrency setting is in Server configuration.
• No graphics requirement. Earlier Reportworq documentation listed DirectX 12. That requirement belonged to the older rendering path and does not apply. Reportworq needs no GPU and no display adapter on any platform. What that row was standing in for is fonts, which are a real requirement, see the Fonts row above.

Going deeper. For multi-node clusters, cloud hosting, and how the two ports apply across a load-balanced set of servers, see Deployment topology. To turn these baseline figures into a server count for a real workload, see Distribute the load.