Skip to content
Back to insights

How We Built Flarehawk

The story of Flarehawk's launch. Its capabilities are now part of the Vigilbase Platform, the cybersecurity operating system.
|7 min
How We Built Flarehawk

Today we launched Flarehawk on Product Hunt, and it feels like the right moment to share the story behind it. What we saw, what we built, and why.

The problem we couldn't ignore

At Vigilbase, we've spent years managing security for businesses across EMEA. We work closely with Cloudflare. We deploy enterprise security stacks. We help companies configure WAFs, set up Zero Trust, lock down access policies.

And over and over again, we saw the same thing happen.

A company would invest serious money in security tooling. The configuration would be solid. The products would be best-in-class. And then nobody would watch them. Alerts would pile up in dashboards nobody opened. Logs would flow into storage nobody queried. Configuration changes would slip through without review. And when something eventually went wrong, whether a breach, a near-miss, or a compliance finding, the first question was always the same: how did we miss that?

The answer was almost never that the tools failed. The tools were working fine. The problem was that nobody had the time, the team, or the context to make sense of what the tools were telling them.

That's the gap we built Flarehawk to close.

What we set out to build

We didn't want to build another dashboard. The world has plenty of dashboards. We didn't want to build another SIEM that takes six months to deploy and generates more noise than signal. And we didn't want to build something that only works if you already have a 20-person SOC to operate it.

We wanted to build the thing we wished existed for our own customers. Something that connects in minutes, understands the environment it's watching, investigates threats on its own, and tells you exactly what to do in plain language. Three principles guided everything:

No false complexity. If a security tool requires a dedicated team just to operate it, it has failed at its job. Flarehawk should work for a VP of Engineering who owns security as part of a broader role, not just for seasoned SOC analysts.

Context over volume. Most security tools are very good at telling you something happened. Very few tell you why it matters in your specific environment. A login from an unusual location might be a threat for one company and completely normal for another. Without context, every alert looks the same.

Actionable by default. Every finding Flarehawk surfaces comes with an explanation of what happened, why it matters, and a one-click remediation when possible. Not "investigate further." Not "see related events." An actual answer.

Building the Flarehawk Fabric

The hardest technical challenge wasn't detection. Detection, in isolation, is a well-understood problem. The hard part was context. And building context at scale, across diverse customer environments, each generating millions of events per day, required serious infrastructure.

That's what led us to build the Flarehawk Fabric.

The ingestion layer

Flarehawk ingests data from Cloudflare environments in real time. We're talking about HTTP events, WAF triggers, and soon Zero Trust access logs, DNS queries, Gateway activity, and configuration changes. For a single mid-market customer, that can mean hundreds of thousands of events per hour. Across our customer base, we're processing millions of rows per second.

To handle that throughput, we run a distributed ingestion pipeline on Kubernetes clusters that auto-scale based on event volume. Each customer's data stream is isolated at the ingestion layer, tagged, and routed through a series of enrichment stages before it hits the analysis pipeline. The system is designed to never drop events, even during traffic spikes or attack surges when log volume can increase by orders of magnitude in minutes.

The analysis pipeline

Once events are ingested, they flow into a multi-stage analysis pipeline. The first stage handles normalization and enrichment, correlating raw events with threat intelligence feeds, geolocation data, and historical context for that specific tenant. The second stage is where the Fabric model runs.

The Fabric is a per-tenant machine learning engine that builds a behavioral model unique to each customer. It learns traffic patterns, user behaviors, configuration norms, and access rhythms specific to that environment. Over time, it constructs a dynamic baseline of what "normal" looks like for each customer individually.

No two Fabric models are the same, because no two businesses are.

When something deviates from that baseline, whether a WAF rule change that doesn't match historical patterns, an access attempt from an unusual context, or a traffic spike with an anomalous signature, the Fabric doesn't just flag it. It initiates an automated investigation. It correlates the anomaly across multiple data sources, evaluates severity against the customer's own baseline rather than generic thresholds, and produces a finding with a clear, human-readable explanation and a recommended action.

We spent months refining this. Running it against real customer environments in private beta. Tuning the models. Reducing false positives. Making sure that when Flarehawk tells you something matters, it actually matters.

Long-term storage on ClickHouse Cloud

Every event that flows through the pipeline is also written to long-term storage on ClickHouse Cloud. We chose ClickHouse because the query performance at the scale we operate at is unmatched for analytical workloads. When a customer needs to search across billions of historical events for an incident investigation or compliance audit, the response needs to come back in seconds, not minutes.

ClickHouse Cloud gives us the columnar storage and compression we need to retain up to five years of log data per customer without the storage costs becoming prohibitive. It also lets us expose a fully queryable interface where customers can run ad-hoc queries, build custom reports, and export data in the formats their auditors and regulators expect.

The decision to build retention directly into the product rather than treat it as an add-on was deliberate. In our experience managing security for enterprise clients, the moment you most need your logs is almost never the moment something happens. It's weeks or months later, when an auditor asks for evidence, an incident report requires a timeline, or a compliance framework demands proof. Most teams either don't retain logs long enough or store them in formats that are painful to query. We wanted to eliminate that problem entirely.

Private beta to open beta

We ran Flarehawk in private beta with a select group of customers. The feedback shaped every part of the product, from how findings are presented, to how remediation works, to what the onboarding experience looks like.

The early results validated our thesis. Customers told us Flarehawk surfaced real threats in the first week that had gone completely unnoticed. Misconfigured rules running for weeks without anyone catching them. Unusual access patterns that didn't trigger generic thresholds but stood out against the customer's own behavioral baseline built by the Fabric.

That gave us the confidence to open it up.

Why Product Hunt, why today

We chose to launch on Product Hunt because Flarehawk was built for a specific kind of team. Lean engineering organizations that care deeply about security but don't have the headcount to run a full security operation. Product Hunt is where those teams discover tools that solve real problems without adding complexity.

If that sounds like your team, we'd love your support. Upvote Flarehawk on Product Hunt and let us know what you think. It makes a real difference for a small team shipping something we believe in.

What's next

Today's launch is just the beginning. We have more announcements coming in the days ahead, including new capabilities, new integrations, and more ways to make Flarehawk the security team your infrastructure deserves.

If you're ready to see what's happening inside your environment, get started today at Vigilbase.

And if you want to follow the journey, connect with us on LinkedIn or reach out directly. We're building this in the open now, and we want to hear from you.

Flarehawk is built by Vigilbase, a managed security services provider specializing in Cloudflare solutions across EMEA and the US market.

Tags

Flarehawk
Ilyas Esmail

Ilyas Esmail

Founder

Founder @ Vigilbase

Related articles

Introducing the Vigilbase Network

Introducing the Vigilbase Network

Vigilbase now operates AS402630, a small but important step toward more reliable, independent infrastructure.

Ilyas Esmail
Introducing Unified SLA Tiers: Core, Priority, and Critical

Introducing Unified SLA Tiers: Core, Priority, and Critical

Historical article

The December 2025 service-tier announcement. See the current SLA for the scope and coverage of Vigilbase packages.

Ilyas Esmail

Stay ahead of threats

Get the latest cybersecurity insights and best practices delivered to your inbox.