I have built WAF and edge products for companies for a long time. Signatures, policy engines, the control plane that sits in front of someone else’s proxy. Some of that work shipped. Some of it sat in a slide deck and died there.

I had a real vision for this space and I wanted to share it. Not as a talk. As something you can run.

coreX is that vision on a stack people already trust — HAProxy, Coraza, Varnish — with extra magic on top, and a few hidden gems I would not leave on a whiteboard again. It is also the box I needed in my own rack when Nginx Proxy Manager stopped being enough, and when NGINX itself had already shown its ceiling at work.

The stack was never the problem

HAProxy already load-balances like it means it. Coraza already speaks OWASP CRS. Varnish already caches. Operators trust that stack because it has been in production for years, not because a vendor renamed it.

What was missing was the layer you live in: a control plane that treats that stack as first-class, not a generated config you are scared to touch. Snapshots. Diffs. Exceptions that do not punch a hole in the WAF. Fingerprints and risk scores you can write policy against. Logs in the same place you change the rule. An MCP gateway so an agent can see the edge without owning it.

That is the extra magic. I did not replace the trusted data plane. I put a real brain and a real UI on it.

NGINX had a ceiling. We hit it.

On more than one team I was on, the data plane was NGINX because that is what everyone knew. It is a fine web server. It is a strained application delivery controller.

We kept paying for the same limitations:

Config that does not reload the way operators need it to when the file gets large and the number of backends is not a demo
Lua and third-party modules doing jobs HAProxy already treats as first-class — stick-tables, ACLs, SPOE, proper L7 routing
WAF bolted on, not designed in. ModSecurity in-process, or a sidecar, or “we will do it at the CDN”
Observability that is access logs and a prayer, not a control plane you can ask a question
A generation culture: render a giant nginx.conf, hope the test is good, reload, find out in production

Those were not theoretical. Development teams I was on struggled with them. I struggled with them. You can paper over a lot of it with discipline and a custom generator. You cannot paper over the fact that you picked a web server and asked it to be an edge platform.

That is why the trusted stack under coreX is HAProxy and Coraza, not another NGINX wrapper with a nicer theme.

The interesting problems after that were never “add another managed rule.” They were the unglamorous ones:

A real GUI over a serious data plane, not a thin wrapper around nginx.conf
Rules you can snapshot, diff, and roll back
Exceptions that do not turn the WAF into an allow-all
Logs that land in the same place you write policy
A way for an operator to change the edge without SSH and a prayer

That is not a feature list that survives a quarterly roadmap meeting. It does not demo as well as a new dashboard skin. It also happens to be the difference between a proxy you babysit and a platform you trust.

I wanted that work in the open. Not as a memoir. As software.

Then the homelab outgrew NPM

At home I was on Nginx Proxy Manager. It is a good tool. It got SSL, proxy hosts, and a usable UI into a lot of racks, including mine.

I outgrew it.

Once you care about WAF rules, request fingerprints, rate limits that are not an afterthought, cache policy, TLS baselines, and more than a handful of backends, NPM is the wrong shape. You end up with a friendly UI for the easy 20% and raw config, sidecars, and hope for the rest — the same NGINX ceiling I had already hit with development teams at work, just in a smaller rack.

I did not want another panel that hides NGINX. I wanted one control plane over a data plane that can actually do the job.

The homelab is a terrible product manager and an honest one. If you will not run it on your own traffic, do not ship it.

The vision they did not want to fund

I am not going to name employers. The pattern is familiar if you have worked inside edge or security product orgs:

The platform that operators live in every day loses to the platform that sells or plaform owners who have no vision. Fine-grained rule workflow loses to a checkbox that says WAF is “on.” Self-hosted control — your metal, your logs, your fail-closed behavior — loses to the cloud SKU.

I did not think those calls were always evil. I thought they left a hole, and I had a clear picture of how to fill it. People who run their own edge still need the same quality of control plane the big vendors keep behind the commercial product. The open stack already does the hard parts. What was missing was the piece you sit in front of all day without feeling like you are editing a generated config by hand — and the judgment about which 10% of “nice to have” actually changes how you operate.

That vision is what I wanted to share. coreX is the share.

Hidden gems

A lot of the product is the obvious stuff: listeners, backends, WAF, TLS, cache. The things I would miss if they disappeared are quieter:

Request fingerprints that go past User-Agent, JA4, and QUIC — the shape of how the client actually builds the HTTP request
Risk scores the rule language can act on, not a number in a dashboard
WAF exceptions you can preview against live logs before they land
Rule version snapshots so a bad publish is a restore, not an incident
Page Protect — CSP builder, script inventory, hash-based supply-chain change detection, and a policy recommender from a real baseline window. Page Shield energy, on your proxy
Trust Beacons — the Page Protect beacon proves a client actually received your HTML (cxid in Server-Timing), then ip.beacon_trusted is a field you can write security rules against. Bots that never rendered the page do not get that bit
API Armor — GraphQL depth and complexity, OpenAPI/JSON schema validation, JWT and API-key checks, and behavioral profiles per endpoint that the same rule language can see
An MCP gateway with teams, DLP, and guardrails, plus a coreX MCP server that exposes the control plane as tools — read for context, write for the people who own the stack
Terraform over the same objects you click in the GUI

Those are the pieces that used to die in internal specs. They are in the product because I got tired of explaining why they matter.

What coreX is, in that light

coreX Platform is extra magic on a trusted stack: a control plane, data plane, and web GUI for the edge I actually wanted to operate. Listeners and backends, WAF, security rules, cache, TLS, observability — and an agent path that is not unbound.

It is not a Cloudflare clone. It is not NPM with extra buttons. It is the vision I could not get funded, running on the homelab that outgrew the last panel, with the hidden gems left in instead of cut for the demo.

If you have hit the same wall — at work, or on a box in the closet — the quick start is the shortest path to kicking the tires. Click around the unglamorous screens. That is where the product actually is.