Flowtriq vs Wanguard: Two Architectures
for DDoS Detection

Wanguard and Flowtriq are both legitimate DDoS detection platforms used by ISPs and hosting providers. They take fundamentally different architectural approaches to the same problem: identifying and mitigating volumetric attacks before they cause damage. This comparison is written by the Flowtriq team. We have an obvious bias, so we will be explicit about where Wanguard is the better choice.

We are not going to soft-pedal Wanguard's advantages or pretend that Flowtriq is the right answer for every environment. The reality is that both tools serve real operators in production, and the right choice depends on your infrastructure, team, and requirements.

The architectural difference

The most important thing to understand about this comparison is that Wanguard and Flowtriq are built on fundamentally different detection architectures. This is not a feature-list difference or a pricing difference. It is a structural difference in how each tool sees traffic and where detection happens.

Wanguard is a flow-collector architecture. It receives sFlow, NetFlow, or IPFIX telemetry from your switches and routers, analyzes sampled flow data at a central collection point, and triggers BGP-based mitigation or scripted responses when it detects anomalies. This is the traditional ISP detection model. Your network equipment exports flow summaries (typically sampling 1-in-1000 to 1-in-4096 packets), Wanguard's Sensor component processes these summaries, and the Filter component handles mitigation actions. The detection logic runs on a dedicated server that you deploy, manage, and maintain.

Flowtriq is a server-agent architecture. A lightweight agent runs on each server you want to protect, monitors all traffic at the kernel level via /proc/net/snmp and socket statistics, and reports telemetry to a cloud-hosted dashboard. Detection happens on the server itself using per-host baselines, not from sampled network data at an aggregation point. The agent sees every packet that reaches the server, not a statistical sample.

Neither approach is universally better. They solve different problems at different network layers. Flow-based detection gives you a bird's-eye view of all traffic traversing your network infrastructure. Agent-based detection gives you granular, per-server visibility with no sampling loss. The right choice depends on whether you need network-wide aggregate visibility or per-host detection depth.

Where Wanguard wins

We mean this section genuinely. These are areas where Wanguard is the stronger tool, not token acknowledgments.

Price at scale for large ISPs

For an ISP monitoring aggregate transit traffic at two or three aggregation routers, Wanguard's annual license model covers those collection points regardless of how many servers sit behind them. If you have 500+ servers generating traffic that flows through a handful of border routers, Wanguard's cost per monitored unit is substantially lower than any per-node pricing model. The license covers the sensors and filters, not the number of downstream hosts. For large-scale ISP operations where the server count is high but the flow collection points are few, this is a meaningful cost advantage that we cannot match with per-node pricing.

The math is straightforward. Wanguard's Sensor + Filter bundle runs roughly $1,590-$3,000+/year depending on configuration. At $9.99/node/month, Flowtriq costs $59,940/year for 500 nodes. Even at our annual rate of $7.99/node, that is $47,940/year. There is a clear crossover point where Wanguard's fixed licensing becomes significantly cheaper, and for large ISPs, that crossover point is well below 500 nodes.

Network-wide flow visibility

Wanguard sees ALL traffic crossing your network via flow exports from your routers and switches. This includes traffic between customers, traffic to upstream peers, traffic to IX partners, and traffic that never touches any individual server. For capacity planning, traffic engineering, peering analysis, and understanding aggregate traffic patterns across your backbone, flow-based tools provide network-wide visibility that agent-based tools structurally cannot.

If your operational requirements include questions like "how much traffic are we exchanging with AS 174 this month?" or "which peering link will hit capacity first?", Wanguard answers these directly from the same flow data it uses for detection. Flowtriq does not see inter-router traffic, peering traffic, or any traffic that does not reach a monitored server. This is not a feature gap we plan to close. It is an inherent limitation of the agent architecture.

Mature product with long track record

Wanguard has been in production at ISPs for over a decade. The product is stable. The web dashboard (Wanguard Console) is polished, the reporting engine handles long-term traffic trending, and Andrisoft provides commercial support with established SLAs. Wanguard is a known quantity in the ISP community. Network engineers who have used it at previous employers know its configuration model, its alerting behavior, and its quirks. There is institutional knowledge around Wanguard that a newer product cannot replicate.

For organizations where the buying decision involves a committee and the question "who else uses this?", Wanguard has a longer reference list. Flowtriq is growing, but we are honest about the fact that Wanguard has more cumulative production years across the ISP industry.

Data sovereignty

Wanguard is entirely self-hosted. Your flow data never leaves your network. The Sensor, Filter, and Console all run on your infrastructure, behind your firewall, under your control. For operators with strict data residency requirements, regulatory constraints, or institutional policies that prohibit sending telemetry to external SaaS platforms, this is a hard requirement that Wanguard satisfies and Flowtriq (as a cloud-hosted dashboard) does not.

This matters particularly for government-adjacent ISPs, operators in regulated industries, and organizations in jurisdictions with strict data localization laws. If "no data leaves the network" is a non-negotiable policy, Wanguard is the right choice regardless of any other comparison point.

No vendor dependency

If Andrisoft disappeared tomorrow, your Wanguard installation would keep running. The software is installed on your hardware, the detection logic runs locally, and your mitigation scripts execute independently. SaaS tools create an operational dependency on the vendor's uptime and continued existence. If Flowtriq's cloud dashboard goes down, your agents continue detecting and mitigating locally, but you lose centralized visibility and historical data access until service is restored. If Flowtriq as a company ceased operations, you would need to migrate to another tool. With Wanguard, the worst case is losing future updates and support while the existing installation continues operating.

Where Flowtriq wins

Deployment speed

Installing a Flowtriq agent takes 60 seconds. One command, one API key, the agent is running. No hardware procurement, no rack installation, no OS tuning, no PF_RING or DPDK configuration, no flow export setup on your routers. This is not just a convenience advantage. It means you can deploy detection during an active attack, not after a multi-day deployment project.

Wanguard deployment involves provisioning a dedicated server (Andrisoft recommends PF_RING or DPDK-capable hardware for high-throughput environments), installing the Wanguard Sensor and Filter components, configuring flow exports on every router and switch you want to monitor, tuning thresholds per subnet, and setting up the Console for web access. For a greenfield deployment, this is typically a multi-day project that requires network engineering expertise. When you are under attack and need detection now, this deployment timeline is a real problem.

Detection speed

Flowtriq's agent monitors traffic at the kernel level and detects anomalies in under 1 second. There is no sampling interval, no flow export delay, no collection-to-analysis pipeline. The agent sees every packet that hits the server and evaluates against per-host baselines continuously.

Wanguard's detection latency depends on your router's flow export interval, typically 10-60 seconds. The flow data must be exported from the router, transmitted to the Wanguard Sensor, parsed, aggregated, and analyzed before an alert fires. For sustained volumetric attacks that last minutes or hours, this latency is acceptable. For short-burst attacks that last under 30 seconds (increasingly common with modern botnets that rotate targets rapidly), the attack often completes before flow-based detection fires. This is not a Wanguard-specific limitation. It is inherent to all flow-based detection architectures.

Per-server granularity

Flowtriq knows exactly which server is under attack, what the per-host traffic breakdown looks like, what the server's normal baseline is, and how the current traffic deviates from that baseline. Each server has its own learned profile. An attack against one server in a rack does not affect the baselines or alerting for neighboring servers.

Wanguard sees aggregate flow data and can identify destination prefixes under attack. For a /24 subnet receiving a volumetric attack, Wanguard can tell you the prefix is under attack and break down the traffic by protocol. But it sees flows, not server behavior. It cannot tell you that server A in the /24 is the target while servers B through Z are unaffected. It cannot establish per-server baselines. If one server in a subnet has unusually high legitimate traffic (a CDN origin, a game server on event day), Wanguard's subnet-level thresholds must accommodate that outlier, which raises the threshold for the entire subnet and reduces sensitivity for every other server in it.

PCAP forensics

Flowtriq captures server-side PCAPs on every detected attack using a pre-attack ring buffer. When an attack is detected, the agent saves packet captures that include traffic from before the detection trigger, during the attack, and after mitigation. These PCAPs are available in the dashboard for download and analysis.

Wanguard does not provide packet captures as part of its detection workflow. It works with flow summaries, not raw packets. For post-incident analysis, compliance reporting, customer forensics, and evidence in abuse reports or legal proceedings, PCAPs are essential documentation that flow summaries cannot replace. A flow record tells you that 500,000 UDP packets hit a destination. A PCAP tells you the exact payload contents, source port patterns, TTL distributions, and packet structure that identify the specific amplification vector and botnet toolkit responsible.

Cloud and hybrid support

Flowtriq runs on any Linux server: AWS EC2, GCP Compute, Azure VMs, bare metal in a colo, budget VPS providers. The agent does not require flow exports from network equipment, which means it works in environments where you do not control the router layer. This is the entire cloud computing model. AWS, GCP, and Azure do not expose sFlow or NetFlow from their virtual network infrastructure in a way that Wanguard can consume.

If you run a hybrid infrastructure with some servers in a colo (where you have router access) and some in the cloud (where you do not), Wanguard can only cover the colo portion. The cloud servers are a blind spot. Flowtriq covers both environments identically because it operates at the server level, not the network level. For operators who are migrating workloads to cloud or running hybrid deployments, this is a significant coverage difference.

SaaS operational model

Flowtriq's dashboard is cloud-hosted. There is no hardware to maintain, no OS to patch, no database to back up, no SSL certificates to renew. Updates are automatic. The dashboard is always available. Support is included in every plan with no ticket caps. The operational burden of running Flowtriq is near zero compared to maintaining your own Wanguard infrastructure.

Running Wanguard means you are responsible for the server it runs on: hardware failures, OS security patches, database maintenance, disk space management, and performance tuning as your flow volume grows. This is fine for organizations with dedicated network operations staff. For smaller teams where the person managing DDoS detection is also managing DNS, email, and customer support, the operational overhead of self-hosted infrastructure is a real cost that does not appear on the license invoice.

Modern integrations

Flowtriq alerts to Slack, Discord, PagerDuty, OpsGenie, SMS, webhooks, and Prometheus natively. The alert payloads include attack classification, volume data, mitigation status, and direct links to the dashboard. Wanguard primarily alerts via email, SNMP traps, and custom scripts. You can build integrations by writing scripts that Wanguard's Filter component executes on detection events, but this requires scripting work for each alert channel. If your operations team lives in Slack or PagerDuty, Flowtriq's native integrations work immediately. With Wanguard, you are writing and maintaining custom integration scripts.

Attack classification

Flowtriq classifies attacks into 7 families (SYN flood, UDP amplification, DNS amplification, NTP amplification, ICMP flood, TCP flood, application-layer) with confidence scoring. The classification tells you not just that traffic is high, but what kind of attack it is and how confident the system is in that classification. This drives automated mitigation decisions: a high-confidence SYN flood triggers different FlowSpec rules than a UDP amplification attack.

Wanguard provides protocol-level breakdown (UDP, TCP, ICMP) and volume metrics, but limited semantic classification. It can tell you that you are receiving a large volume of UDP traffic to port 53, but the interpretation of "this is a DNS amplification attack using open resolvers with spoofed source addresses" requires operator analysis. For teams that want the system to identify the attack type and recommend or automate the appropriate mitigation response, classification depth matters.

Feature comparison

When to choose Wanguard

Wanguard is the right choice when your operational model aligns with its architectural strengths. These are genuine recommendations, not qualifications.

• You are a large ISP monitoring aggregate transit traffic at a few central collection points. Your detection needs are at the network layer, not the server layer. You want to see all traffic crossing your border routers, IX peering links, and customer-facing interfaces in a single flow analytics platform.
• Network-wide flow visibility for capacity planning is a core requirement. You use the same tool for DDoS detection and for traffic engineering, peering analysis, and transit utilization reporting. You need long-term traffic trending data across your entire backbone, not just per-server metrics.
• Data sovereignty means nothing can leave your network. Regulatory, contractual, or institutional policy requires that all monitoring telemetry stays within your network boundary. No exceptions, no external SaaS.
• You have network engineering staff to manage dedicated monitoring hardware. You have a NOC team that manages infrastructure professionally. Running a dedicated Wanguard server with PF_RING, keeping the OS patched, and maintaining the database is routine operational work for your team, not an additional burden.
• Your server count is high enough that per-node pricing exceeds Wanguard's annual license. You have hundreds or thousands of servers behind a handful of border routers. The economics of per-node pricing do not work at your scale. Wanguard's fixed license model gives you DDoS detection coverage across all of them for a predictable annual cost.
• You value having no SaaS vendor dependency. You want infrastructure you fully control. If a vendor goes out of business or has an outage, you want your monitoring to keep running without interruption.

When to choose Flowtriq

Flowtriq is the right choice when you need server-level visibility, operational simplicity, and modern tooling integration.

• You need per-server detection. You need to know exactly which host is under attack, not just which prefix. Per-server baselines mean the system learns each server's normal traffic profile and alerts on deviations specific to that host.
• You deploy across cloud, bare metal, and VPS environments. You have servers in AWS, some in a colo, and a few budget VPS nodes. You need one tool that covers all of them identically without requiring different detection methods for different environments.
• You want detection running in minutes, not days. Whether you are setting up protection for the first time or adding a new server to an existing fleet, you want the install to be a single command with immediate visibility.
• PCAP forensics and attack classification matter for your use case. You need to provide customers with incident reports that include packet captures, attack vectors, and timeline data. You use attack classification to drive automated mitigation decisions.
• You want modern alerting without scripting. Your team uses Slack, PagerDuty, and Discord. You want native integrations that work immediately, not custom scripts you have to write and maintain.
• You do not want to manage dedicated monitoring infrastructure. You do not have a NOC team. The person managing DDoS detection is also managing everything else. You want the monitoring platform to be someone else's operational problem.
• You want predictable, transparent pricing with no annual negotiation. $9.99/node/month, published on the website, no sales calls, no quote requests, no annual contract negotiations. You can calculate your exact cost before you sign up.

Can you run both?

Yes. Some operators run Wanguard for network-wide flow visibility and capacity planning alongside Flowtriq for per-server detection and PCAP forensics. These are different tools operating at different layers. Wanguard watches your border routers and gives you aggregate transit analytics. Flowtriq watches your servers and gives you per-host detection with sub-second response. They do not conflict, and the Flowtriq agent adds negligible overhead to servers already being monitored via flow exports.

This dual-stack approach is particularly common for ISPs that have invested in Wanguard for years and want to add server-level detection without replacing their existing flow analytics infrastructure. You keep Wanguard for what it does well (network-wide visibility, capacity planning, peering analysis) and add Flowtriq for what it does well (per-host detection, PCAP forensics, attack classification, modern alerting).

Frequently asked questions

The bottom line

Wanguard and Flowtriq are genuinely good tools that solve related but distinct problems. Wanguard excels at network-wide flow visibility, capacity planning, and cost-effective monitoring for large ISPs with dedicated NOC teams. Flowtriq excels at per-server detection speed, PCAP forensics, attack classification, and operational simplicity for teams that want modern tooling without managing infrastructure.

The right choice depends on your architecture, your team, and your requirements. If you need both network-wide flow analytics and per-server detection, running both is a valid production architecture. If you are choosing one, the decision comes down to whether your primary need is aggregate network visibility (choose Wanguard) or per-host detection with modern integrations (choose Flowtriq).