End-to-end workflow
Whichever way you run Enforza, the journey is the same shape:
Launch a firewall → bind a policy → point traffic at it.
The single place the two run modes diverge is how you author and push policy - and that is your team’s workflow choice, not a difference in capability, enforcement, or billing.
Up and filtering in three steps
Section titled “Up and filtering in three steps”1. Launch
Section titled “1. Launch”Spin up a Linux VM - one, or several across Availability Zones for redundancy, and sized for your traffic - and enrol it. You have a few ways to launch; pick whatever fits your tooling. The outcome is identical: the firewall enrols over a single secure outbound connection and shows Online in your console within seconds.
-
Manual / quick start - run the install one-liner on any supported Linux VM. You don’t craft this command - either portal (Cloud Controller or GitHub Pipeline Integration) generates it for you with the right key baked in; you copy and run it:
Terminal window curl -fsSL https://dl.neon.efz.io/install.sh \| sudo bash -s -- --regkey=YOUR-KEY-HEREThe deployment key can be per-device (single-use - binds one firewall) or a fleet key (reusable across many VMs and your automation).
-
Infrastructure as code (Terraform / native cloud automation) - provision the VM, its routing, and packet-forwarding settings with Terraform or your cloud’s native automation (CloudFormation, ARM / Bicep, Deployment Manager, and the like). Reference landing-zone templates cover the common shapes - single VM, multi-AZ failover, centralised egress. The VM boots and self-enrols with the deployment key you pass in.
-
AWS Marketplace (1-click AMI) - subscribe, launch via the bundled CloudFormation, and the firewall self-registers via its EC2 instance identity. No deployment key to manage; you simply claim it in the console by account + instance id.
Run more than one VM when your redundancy and availability requirements call for it - the launch step is the same for each.
2. Bind a policy
Section titled “2. Bind a policy”Attach a policy to the firewall. A policy is a policy - the same packet-engine, the same enforcement, whichever mode authored it.
3. Point traffic at it
Section titled “3. Point traffic at it”Make one route change so traffic flows through the firewall. Because the last step is just a route change, rollback is instant - point the route back and you are where you started.
The only difference: how you author and push policy
Section titled “The only difference: how you author and push policy”Everything above is identical across both modes. The one divergence is where your policy lives and how a change ships:
| Cloud Controller (CCX) | GitHub Pipeline Integration (GPI) | |
|---|---|---|
| Author | Visual editor in the console | A YAML file in your GitHub repository |
| Review / gate | Publish runs schema + compliance guardrails | Pull request: review, checks, merge |
| Ship | Push to one or many firewalls from the console | Merge triggers the pipeline; the platform ships to the bound firewalls |
| Best for | Network-operations teams | Platform-engineering teams |
Both run the same compliance guardrails, ship to the same packet-engine, and enforce identically. Choose the workflow your team already lives in.
- CCX path: Deploy your first firewall → Build a policy → Bind it → Watch live logs.
- GPI path: Policy guide overview → rules → object groups.
Not sure which mode? See the two ways to run.