Where a host-shaped firewall belongs

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: HeartSuite Firewall fits when the workload can live on the closed HeartSuite image the product ships as, and you want a sealed inbound allowlist for this box. Campus NGFW blades stay the specialist tool.

Where HeartSuite Firewall fits

A single-purpose workload on a closed image

A backup receiver, an internal service, a regulated workload that should run one job: the workload lives on the appliance. You observe what actually arrives, approve the sockets that job needs, and seal.

Root Lock by HeartSuite is already the operating system, so a new binary and a new outbound destination still go through the kernel allowlist.

Virtual appliance on a hypervisor you administer

QCOW2 or OVA on KVM, or the equivalent import on a commercial hypervisor. Console or serial is how you reach the Dashboard. Restrict who can open that console.

The hypervisor is part of the trust boundary. See The virtual appliance residual.

Next to cloud security groups and provider DDoS tools

Security groups and the provider’s volumetric controls stay useful in front of any VM. HeartSuite Firewall is the host allowlist on the image after that outer layer.

Cloud firewall services stay the provider’s policy plane. Booting on AWS, Google Cloud, Azure, DigitalOcean, or Linode leaves that plane in place.

Teams who already review Root Lock queues

If the team already reviews Programs, File Access, and Internet Access, Firewall Rules is the same human act applied to this box’s sockets. That is the intended buyer. FortiManager-class estate management stays with the campus tool.

Where another tool belongs

In front of other machines

v1 has no FORWARD or NAT product surface. Keep the existing edge firewall in front of a backup server, a subnet, or a pair of application hosts, or wait for an edge SKU that changes placement.

Campus, branch, or “NGFW refresh”

App-ID, TLS interception, URL clouds, SD-WAN, SSL-VPN as identity, and a central management platform stay with the specialist tool.

Using this image as a FortiGate or Cisco Secure Firewall replacement is a misfit.

Install-on-my-Ubuntu

HeartSuite Firewall ships only as the closed image, so it does not install onto a server you already run.

Root Lock on a server you already own remains the kernel product. Inbound on that server stays the OS or cloud control you already run, unless you move the workload onto this appliance.

Dedicated hardware

A hardware appliance (TPM / measured boot) is planned. v1 is the virtual image. Until hardware ships, the hypervisor is part of the trust boundary.

Shared-kernel container hosts

This appliance is a closed image with no container engine. Docker, containerd, Kubernetes, CRI-O, and Podman are not a fit on the Root Lock kernel by design: under Lockdown, Root Lock refuses the new mounts a runtime makes, so build and run those images on another host. See Root Lock Deployment Scenarios.

A WAF or API gateway requirement

Payload inspection, bot scores, and schema validation stay with a WAF in front of an allowed HTTPS port.

Alongside Root Lock

On the HeartSuite appliance image the two layers are designed to run together.

Root Lock without this image is still a complete kernel product. HeartSuite Firewall on that server is an optional SKU.

Adding a second packet-filter manager next to HeartSuite Firewall on the appliance opens a hole in the composition.

For residuals inside an approved port, see Protection limits.