Deployment models
HEAT Capture is built for a workstation on an isolated on-premises network or a controlled LAN, not for exposure on a general-purpose network or the internet. This shapes both where you put it and how you connect anything else to it.
HEAT Capture’s embedded web server is not a security perimeter. It binds to every network interface by default, most of its endpoints perform no authentication, and the endpoints that do check only whether an operator is signed in on that workstation, not who is calling. The network boundary around the workstation is the actual security boundary. See HEAT Capture’s ICD for the exact interface-by-interface breakdown.
The default shape: one workstation
The common case is a single Windows workstation that runs both HEAT Capture and every capture module the exercise needs, sitting next to the simulator or hardware each module reads from. Data never leaves that workstation except to your HEAT platform instance, over whatever link you have configured for that (see Configure HEAT Capture).
Nothing on that workstation needs to be reachable from outside it. Bind HEAT Capture’s own
interface to localhost unless something genuinely needs remote access - see
Configure HEAT Capture for the WebSettings:Host setting that
controls this.
When a capture plugin is involved
A capture plugin runs inside a simulator host - MACE, Unreal Engine or VBS4 - rather than inside HEAT Capture. That simulator is sometimes the same workstation as HEAT Capture, and sometimes a separate machine on the same network (a dedicated simulation host, for instance). Either way, the plugin reaches HEAT Capture over the network: session control over HTTP and frame publishing over WebSocket, both documented per-plugin in each plugin’s own Interface Control Document.
This is the one case where HEAT Capture’s own interface genuinely needs to be reachable from another machine, so it is also the one case where the network boundary matters most: restrict that reachability to the LAN segment the simulator host is actually on, with a host firewall allowlist rather than leaving the interface open to whatever else shares the network. See Configure HEAT Capture for binding to a specific address and enabling HTTPS.
Where the HEAT platform fits
HEAT Capture is a client of your HEAT platform instance: it authenticates, opens a session, and delivers captured data to it. The platform side of that relationship - identity, session storage, processing and analytics - is a separate product and out of scope for this documentation set; see What HEAT Capture is for the boundary. Whether your platform instance is itself on-premises or reachable over a controlled link is a decision made independently of everything on this page: HEAT Capture only needs outbound reachability to it, never the reverse.
What this means in practice
- Treat every HEAT Capture workstation as untrusted-by-default to anything else on the network: nothing should be able to reach its embedded interface except what genuinely needs to.
- A capture module never needs network exposure of HEAT Capture’s own interface - it runs in-process. Only a capture plugin does.
- Plan firewall rules and network segments around this before an exercise, not during one; the installer creates none for you - see Install HEAT Capture.