Documentation
On-premises installation
What a dedicated, single-tenant instance needs from your environment and what your administrator manages.
What a dedicated instance is
A dedicated instance is a single-tenant Holistra that runs on servers you control, in your data centre or your own cloud account. It has the same dashboard, agents and API as the cloud service, but serves only your organisation. Scan results, assets, findings and reports are stored on your infrastructure.
It is activated with a licence key that we issue for your instance. Without a valid licence, new scans can't be started; viewing data, agents and remediation keep working.
Installation is done together with our team
Before installation
Server
A single server (physical or virtual) runs the whole platform. Web scanning is the most demanding part, so size for the number of targets you plan to scan at once. As a starting point:
| Minimum | Recommended | |
|---|---|---|
| CPU | 2 cores | 4 or more cores |
| Memory | 4 GB | 8 GB or more |
| Disk | 10 GB free | 20 GB or more, on storage that is backed up |
We confirm the sizing for your environment during scoping.
A hostname and certificate
Choose the hostname users and agents will use, for example holistra.corp.example, and a TLS certificate for it. A certificate from your internal CA or a self-signed one works: agent installers save the server's certificate when they run, so agents keep verifying TLS.
Pick the hostname before rolling out agents
Network access
Inbound to the server
| From | Port | Why |
|---|---|---|
| Users’ browsers | TCP 443 (HTTPS) | The dashboard and API |
| Endpoints with the agent | TCP 443 (HTTPS) | Agent check-ins. Agents only connect outwards; nothing connects to them |
| Optional | TCP 80 | Redirect to HTTPS |
Outbound from the server
| To | Needed for | Required? |
|---|---|---|
| Holistra | Licence validation, and downloading signed threat-intelligence and agent-release updates | Yes |
| Your scan targets | Network, web, host and CIS scans | For scanning |
| Your code repositories and cloud accounts | SCA, SAST and cloud-configuration scans | If you use those scan types |
| OSV (api.osv.dev) or your own mirror | Matching agents’ installed packages against known vulnerabilities | Optional; can be turned off |
| Microsoft Security Update Guide (api.msrc.microsoft.com) | Checking Windows hosts for missing security updates | Optional; can be turned off |
| Your identity provider | Single sign-on and SCIM | If you use SSO |
What leaves your network
- Licence check: your licence key, sent in a request header, on a regular schedule.
- Updates: downloads only. Threat-intelligence feeds and agent releases are signed, and your instance refuses anything that isn't.
- Vulnerability matching (optional): package names, versions and the OS distribution sent to OSV. No hostnames, IP addresses or other data about your organisation.
- Windows update data (optional): public Microsoft documents are downloaded; nothing about your devices is sent.
Scan results, findings, assets, agent reports, users and the audit log stay on your server.
After installation
Your first Administrator signs in, then follows Getting started. On a dedicated instance, your Admins also control updates:
| What | Where | How |
|---|---|---|
| Threat intelligence (CISA KEV and EPSS) | Settings → System | New signed feeds are staged; an Admin reviews and installs them. Older feeds can’t replace a newer one. |
| Agent releases | Settings → Agent updates → Releases | Check now fetches signed releases; an Admin installs one. Agents then update on Update now or by your automatic policy. |
| Agent update policy | Settings → Agent updates | Manual or automatic, maintenance window, canary agents first. |
Jira two-way sync is available on dedicated instances; we set it up with you. Everything else, including agents, SSO and the API, works as described in the rest of this documentation.