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 basic VM, on any cloud.
Choose the one your team already works in.
GitOps or console — same firewall NVA underneath.
Two equal workflows over one firewall, billed the same. 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.
- 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. No repository required.
- GUI-driven policy and fleet management
- Push to many firewalls at once
- Multi-firewall live log streaming
GitOps is available today as a workflow.
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
- 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
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, so the device manages up, never in. Nothing inbound to find, harden or put behind a VPN.
- 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.