How Enforza works — two ways to run it, one firewall.
The same firewall NVA runs underneath either workflow. Author policy as code through a GitHub pipeline, or drive the Cloud Controller console by hand — then deploy in minutes on a VM you already operate, on any cloud. Pick the workflow your team already lives in.
GitOps or console — same firewall NVA underneath.
Two equal workflows, one firewall, equal billing. There is no second-class mode — the same NVA enforces the policy either way. Choose the one your team already works in.
GitHub Pipeline Integration
Author firewall policy as YAML in your repository and treat it like any other change — branches, pull-request reviews, full history, push to deploy. Compliance runs in the pipeline, so non-compliant rules are caught on the pull request, before they ever reach a firewall.
- Policy-as-code in your own repo
- Reviewed and merged like any change
- Advise-or-enforce compliance on every push
Cloud Controller console
A single console for the whole fleet — author policy and push it to many firewalls at once, then watch live logs stream from multiple firewalls in real time, with the same advise-or-enforce guardrails. No repository required.
- GUI-driven policy and fleet management
- Push to many firewalls at once
- Multi-firewall live log streaming
Same firewall NVA underneath, billed the same way. GitOps is available today as a workflow.
Minutes to deploy, on any cloud.
One install command, a self-registering instance, and a route. The firewall is enforcing egress, ingress and east-west traffic in minutes — on a VM you already run.
-
Install on a Linux VM
Run a single install command on a vanilla Linux VM in your own cloud network — AWS, Azure, Google Cloud or on-prem. The installer detects the distro, brings up the firewall instance and needs no runtime dependencies beyond standard Linux network primitives.
-
It registers and pulls policy
The NVA registers itself with the Enforza cloud over an outbound connection and pulls its bound policy — authored in your GitHub pipeline or the Cloud Controller console. No inbound setup, no bastion, no manual key exchange.
-
Route traffic through it
Point a route at the firewall and it is enforcing in minutes, not days. The same instance governs egress to the internet, ingress into your network, and east-west VPC-to-VPC traffic between your own networks.
Install on the VM, bind a policy, route traffic through it — egress, ingress and east-west.
The single-pass packet classification and verdict engine, built for the cloud.
Each flow is classified once — in microseconds, not milliseconds — then every following packet is enforced in-kernel at line rate. A purpose-built cloud NVA, engineered for the cloud rather than an on-prem box bolted onto it.
- ~49.5 µs
p99 first-packet classification (measured, c6i.xlarge — CPU 99% idle)
- 98.5 %
of packets decided in-kernel at line rate — only the first hits userspace
- 0
dropped packets across the throughput run — queue depth peaked at zero
Each flow is classified once and the verdict is reached in microseconds; 98.5% of packets then decide in-kernel at line rate, with zero drops. Measured on standard VM sizes (t3.micro / c6i.xlarge) — conservative floors, not ceilings.
No exposed management plane. The firewall manages up, never in.
Self-managed firewalls — open-source boxes and self-hosted NGFW VMs alike — usually need a reachable management interface to administer, often exposed to the internet or bolted behind a VPN. That is attack surface on the security device itself.
Outbound-only control plane
The Enforza firewall instance talks outbound-only to the Enforza cloud. There is no inbound management port and no admin UI to expose — nothing to find on the security device, nothing to harden, nothing to put behind a VPN. The instance manages up, never in.
- No inbound management port on the firewall
- No admin UI to expose or stand a VPN in front of
- Smaller attack surface on the security device itself
Built to keep running.
A firewall is only as good as its uptime. Enforza self-upgrades with rollback, runs the same way on any cloud, and fails closed.
-
Self-upgrade with rollback
Trigger an upgrade from the console; the instance swaps its binary atomically and reports success — or rolls back to the previous version automatically if the new one does not come up clean.
-
Runs on any cloud
One static Linux binary on a single VM. AWS, Azure, Google Cloud or on-prem — the same firewall instance, the same workflow, wherever you run it.
-
Fail-closed by default
If the engine process stops, new connections are dropped rather than passing through unfiltered. An encrypted local policy cache keeps a known-good ruleset enforcing through a control-plane outage.
Common questions
What are the two ways to run Enforza?
Two equal workflows over the same firewall NVA. GitHub Pipeline Integration is policy-as-code: you author firewall policy as YAML in your repository, review and merge it like any other change, and push to deploy — branches, reviews and full history. The Cloud Controller console is GUI-driven: author policy and manage the whole fleet by hand. Same firewall instance underneath, same billing — the choice is your team's workflow, not a feature tier.
Do I need GitHub to use Enforza?
No. GitHub Pipeline Integration is one workflow for teams that prefer policy-as-code and GitOps, but it is optional. The Cloud Controller console manages policy and the fleet entirely through the GUI, with no repository involved. You can run either workflow — the same firewall NVA enforces the policy in both cases.
Where does Enforza run?
As a single lightweight Linux VM in your own cloud network — AWS, Azure, Google Cloud or on-prem. The firewall instance lives inside your network; you route the traffic you want inspected through it. Log export streams to your own SIEM and never passes through Enforza's cloud.
How fast is it to deploy?
Minutes. Run a single install command on a Linux VM, let it register with the Enforza cloud and pull its policy, then point a route at it. It is enforcing egress, ingress and east-west traffic in minutes, not days.
Does Enforza expose a management port on the firewall?
No. The firewall instance has no inbound management port and no admin UI to expose. Its control plane is outbound-only to the Enforza cloud — the instance manages up, never in. There is no reachable management interface on the security device to find, harden or put behind a VPN.
Does Enforza work across multiple clouds?
Yes. The same firewall instance runs on any cloud or on-prem, and you manage every instance from one console — push policy to many at once and stream live logs from multiple firewalls in real time. One workflow across the whole multi-cloud fleet.
Deploy your way, in minutes.
GitOps or console, the same firewall NVA on any cloud — outbound-only, fail-closed, self-upgrading. Start free, no card.