The two ways to run (CCX vs GPI)

Enforza ships the same firewall engine with two ways to author and ship policy. The choice is your team’s workflow, not a difference in capability or billing — both are equal first-class modes.

Cloud Controller (CCX)

The GUI-driven console, for network-operations teams.

You compose policies in the console — no YAML editing — across the three traffic sections, with drag-to-reorder rules and reusable objects. Publishing runs the policy through a schema gate and (optionally) your bound compliance guardrail packs, then you bind the published version to one or more firewalls. Live logs, fleet view, and log exporters are all driven from the console.

Start here:

• End-to-end workflow — the map.
• Deploy your first firewall — AWS
• Build a simple policy

GitHub Pipeline Integration (GPI)

Policy-as-code / GitOps, for platform-engineering teams.

Your policy is a single YAML file in your GitHub repository. Changes flow through your pipeline — review, checks, merge — and the control plane ships the merged policy to the bound engines. The same compliance guardrails run as a pipeline check. This is the mode for teams that want firewall policy to live in version control alongside the rest of their infrastructure.

Start here:

• Policy guide overview — the YAML model.
• rules (traffic sections) and rule fields.

Same engine, same billing

Both modes drive the same single-pass packet classification and verdict engine, the same three traffic sections, the same first-match evaluation, and the same flat per-firewall licence. A tenant can run both — some firewalls bound to console-authored policy, others to pipeline-authored policy — at the same time.

See how it works for the engine architecture both modes share.