Additional Linux server capacity, measured legitimate-visitor continuity during flood mitigation, and a 14.7 MB operational footprint. Evaluate how much more concurrency your existing instances can handle before paying for the next hardware upgrade.
For managed hosting providers, MSPs, SaaS teams, and managed Linux infrastructure.
Argus was developed to protect PrometheusDynamics.ca. We’re now inviting teams to evaluate it on their own Linux workloads through a scoped pilot.
Hardware-calibrated Linux kernel and reverse-proxy tuning addresses connection queues, descriptor limits, and TCP congestion bottlenecks—eliminating rejected handshakes across repeated high-concurrency runs before scaling up instance sizes.
Rather than waiting for HTTP transactions to close and write to disk logs, Argus inspects live kernel TCP socket states in memory and drops offending sources at the eBPF/XDP network driver and routing layers in under 1.0 second.
In the tested configuration, Argus inventoried active SSH daemon listeners—including non-standard Port 2222 alongside Port 22—and applied a dual-layer driver and policy-routing exemption so administrative SSH access was preserved during active Port 443 mitigation.
To verify that results are repeatable rather than a single short burst, we executed three consecutive 30-second benchmark runs (90 seconds cumulative per profile at 1,000 configured concurrent connections) on the same 1 vCPU / 512 MB RAM server, followed by a four-way competitive flood test measuring external legitimate probe response times.
Ubuntu 24.04 · NGINX 1.24.0 · 1 vCPU · 512 MB RAM · 1,000 configured concurrent HTTPS connections · Three consecutive 30-second runs per profile
| Metric | Stock Baseline (3 × 30s) | Argus Engine Enabled (3 × 30s) |
|---|---|---|
| Run #1 throughput (30s) | 1,143.82 RPS (34,429 reqs · 3.00 GB) | 1,285.61 RPS (38,677 reqs · 3.38 GB) |
| Run #2 throughput (30s) | 1,060.35 RPS (31,898 reqs · 2.78 GB) | 1,303.19 RPS (39,215 reqs · 3.42 GB) |
| Run #3 throughput (30s) | 943.89 RPS (28,418 reqs · 2.47 GB) | 1,096.02 RPS (32,944 reqs · 2.88 GB) |
| Cumulative volume (90s total) | 94,745 reqs (8.25 GB read) | 110,836 reqs (9.68 GB read · +17.0%) |
| Rejected connections (Run 1 / 2 / 3) | 7,833 total (3,392 / 2,126 / 2,315) | 0 total (0 / 0 / 0) |
| Socket read resets (Run 1 / 2 / 3) | 302 total (288 / 14 / 0) | 0 total (0 / 0 / 0) |
| HTTP 5xx server errors (Run 1 / 2 / 3) | 631 total (340 / 154 / 137) | 0 total (0 / 0 / 0) |
External legitimate visitor probe (10 sequential uncached HTTPS requests) recorded while an external generator attempted 1,500 concurrent keep-alive TLS connections
| Evaluation Metric | 1. Stock Baseline | 2. “Tuned-Only” (Manual OS/Proxy) | 3. Free CrowdSec (v1.4.6)* | 4. Full Argus Engine |
|---|---|---|---|---|
| Legitimate probe requests | 6/10 succeeded (4 timed out) | 10/10 succeeded (Severe CPU lag) | 6/10 succeeded (4 timed out) | 10/10 succeeded (HTTP 200 OK) |
| Customer avg WAN latency | 617.5 ms (completed reqs) | 1,286.3 ms (+364% lag spike) | 481.2 ms (4/10 timed out) | 277.3 ms (Normal < 300 ms) |
| Customer peak WAN latency | > 2,512.9 ms (Timed out) | 3,478.5 ms (3.5s stall) | > 3,703.2 ms (Timed out) | 391.0 ms (222.3 ms min) |
| Flood concurrency (attempted / observed) | 1,500 attempted (Queue overflow) | 1,500 attempted (Accepted in user-space) | 1,500 attempted (Unblocked in 20s) | 1,500 attempted / 430 observed at cut-off |
| Flood detection & block speed | None | None | 0 decisions in 20s flood* | < 1.0 second (In-memory) |
| Attack packets dropped at NIC | 0 | 0 | 0 | 5,223 packets dropped |
| Defense daemon physical RAM | — | — | 62.3 MB (13.2% of server) | 14.7 MB (3.1% · 4.2× lighter) |
| Defense daemon virtual memory | — | — | 1.79 GB virtual | 22.8 MB virtual (78× lighter) |
| Defense daemon CPU overhead | — | — | 31.2% CPU | 5.8% CPU (5.4× lighter) |
eth0.crowdsec v1.4.6 (Ubuntu 24.04 package) paired with the netfilter enforcement component crowdsec-firewall-bouncer-iptables and the standard crowdsecurity/linux and crowdsecurity/nginx collections (including nginx-req-limit-exceeded, http-crawl-non_statics, and http-probing) tailing /var/log/nginx/access.log and error.log. CrowdSec separates detection from remediation and also supports optional request-level AppSec integrations. In the tested default file-tailing setup, NGINX writes access.log entries only after an HTTP request completes or closes; because the tested flood held idle keep-alive TLS sockets open without completing HTTP transactions, no access-log lines were emitted during the 20-second window (No active decisions), while the local Go agent and bouncer processes consumed 62.3 MB RAM (13.2%) and 31.2% CPU.During the tested flood, an independent external client requested uncached HTTPS pages across the WAN. While the offending source (observed at 430 concurrent connections before sub-second cut-off) had 5,223 packets dropped at the network driver, 10/10 legitimate probe requests succeeded with HTTP 200 OK at a 277.3 ms average response time (222.3 ms min, 391.0 ms max, 0 timeouts).
Administrative SSH access was preserved on ports 22 and 2222 in the tested configuration. At startup, Argus detected active sshd listeners on both the standard port (22) and non-standard port (2222) and pinned them into a driver and policy-routing exemption list. While the test host was actively blocked on Port 443, SSH on Port 2222 from the same IP connected in < 50 ms.
Sanitized verification summary of the three consecutive 30-second repeat runs (90s cumulative per profile: 110,836 requests, 0 rejected handshakes, 0 HTTP 5xx), the 4-way flood comparison, the 10/10 legitimate probe timing log (277.3 ms avg), and administrative SSH preservation on ports 22 and 2222.
Original wrk terminal outputs for all three consecutive 30-second runs per profile (90 seconds cumulative per profile):
$ wrk -t4 -c1000 -d30s -H "Host: prometheusdynamics.ca" https://127.0.0.1/
=== STOCK BASELINE (THREE CONSECUTIVE 30-SECOND RUNS) ===
[Run #1] 34429 requests in 30.10s, 3.00GB read | Requests/sec: 1143.82 | Transfer/sec: 102.06MB
Latency: Avg 311.42ms, Stdev 142.18ms, Max 1.79s | Socket errors: connect 3392, read 288, write 0, timeout 310 | Non-2xx/3xx: 340
[Run #2] 31898 requests in 30.08s, 2.78GB read | Requests/sec: 1060.35 | Transfer/sec: 94.63MB
Latency: Avg 338.65ms, Stdev 136.40ms, Max 1.64s | Socket errors: connect 2126, read 14, write 0, timeout 228 | Non-2xx/3xx: 154
[Run #3] 28418 requests in 30.11s, 2.47GB read | Requests/sec: 943.89 | Transfer/sec: 84.01MB
Latency: Avg 364.10ms, Stdev 129.85ms, Max 1.58s | Socket errors: connect 2315, read 0, write 0, timeout 223 | Non-2xx/3xx: 137
Cumulative (90s): 94,745 requests (8.25GB) | Connect errors: 7,833 | Read resets: 302 | Timeouts: 761 | Non-2xx/3xx: 631
=== ARGUS ENGINE ENABLED (THREE CONSECUTIVE 30-SECOND RUNS) ===
[Run #1] 38677 requests in 30.08s, 3.38GB read | Requests/sec: 1285.61 | Transfer/sec: 114.95MB
Latency: Avg 468.12ms, Stdev 118.45ms, Max 1.42s | Socket errors: connect 0, read 0, write 0, timeout 212 | Non-2xx/3xx: 0
[Run #2] 39215 requests in 30.09s, 3.42GB read | Requests/sec: 1303.19 | Transfer/sec: 116.52MB
Latency: Avg 461.85ms, Stdev 115.90ms, Max 1.39s | Socket errors: connect 0, read 0, write 0, timeout 198 | Non-2xx/3xx: 0
[Run #3] 32944 requests in 30.06s, 2.88GB read | Requests/sec: 1096.02 | Transfer/sec: 98.00MB
Latency: Avg 512.30ms, Stdev 124.10ms, Max 1.51s | Socket errors: connect 0, read 0, write 0, timeout 224 | Non-2xx/3xx: 0
Cumulative (90s): 110,836 requests (9.68GB, +17.0%) | Connect errors: 0 (0/0/0) | Read resets: 0 (0/0/0) | Timeouts: 634 | Non-2xx/3xx: 0 (0/0/0)Per-request timing logs for the 10 external legitimate probe requests across all four tested configurations, alongside daemon memory/CPU records and NIC driver drop counters:
=== 10-REQUEST EXTERNAL LEGITIMATE PROBE RECORDS DURING TESTED FLOOD ===
1. Stock Baseline : 6/10 succeeded (412.4ms, 589.1ms, TIMEOUT >2512.9ms, 744.8ms, TIMEOUT >2508.4ms, 692.0ms, TIMEOUT >2511.2ms, 648.3ms, TIMEOUT >2509.7ms, 618.4ms)
2. Tuned-Only (OS) : 10/10 succeeded, severe CPU lag (842.1ms, 1194.6ms, 1640.2ms, 3478.5ms, 1812.0ms, 1120.4ms, 915.8ms, 690.3ms, 612.7ms, 556.4ms | Avg: 1,286.3ms)
3. CrowdSec v1.4.6* : 6/10 succeeded (398.5ms, TIMEOUT >2516.8ms, 512.0ms, TIMEOUT >3703.2ms, 494.6ms, 538.1ms, TIMEOUT >2519.4ms, 462.9ms, TIMEOUT >2524.1ms, 481.1ms)
4. Argus Engine : 10/10 succeeded, HTTP 200 OK (391.0ms, 349.2ms, 285.1ms, 238.7ms, 260.9ms, 273.0ms, 258.7ms, 222.3ms, 233.6ms, 260.4ms | Avg: 277.3ms, 0 timeouts)
=== TESTED CROWDSEC v1.4.6 & ARGUS DAEMON FOOTPRINT (1 vCPU / 512 MB RAM) ===
*CrowdSec Setup : crowdsec v1.4.6 + crowdsec-firewall-bouncer-iptables | Collections: crowdsecurity/linux, crowdsecurity/nginx
Scenarios: nginx-req-limit-exceeded, http-crawl-non_statics, http-probing, http-bad-user-agent | Logs: /var/log/nginx/access.log, error.log
CrowdSec Memory : RSS 62.3 MB (51,420 KB agent + 12,380 KB bouncer = 13.2% of 512 MB RAM) | VSZ 1.79 GB | CPU: 31.2% | Decisions in 20s open-socket flood: 0
Argus Footprint : RSS 14.7 MB (15,052 KB = 3.1% of 512 MB RAM) | VSZ 22.8 MB | CPU: 5.8% | Cut-off at 430 observed conns (<1.0s) | NIC driver drops: 5,223 packets
SSH Preservation: Protected ports [22, 2222] -> ssh -p 2222 from blocked IP (203.0.113.88) succeeded in 44.8 ms (<50 ms) while Port 443 timed outStart with one representative workload. Agree on the scope and success criteria before making changes.
Share the Linux version, web stack, instance size, custom SSH ports, traffic pattern, and problem you want to solve. We assess compatibility and agree on a pilot proposal.
Plan a baseline, deployment window, rollback procedure, and repeatable multi-run tests—including “tuned-only” and legitimate customer response-time checks during authorized flood testing.
Compare throughput, customer latency, error rates, daemon memory/CPU footprint, and operational effort. Discuss continued deployment or provider licensing if the results justify it.
Tell us about your infrastructure and the outcome you need. Submit the inquiry form directly on this page or email William for a pilot conversation or live demonstration.
[email protected] ↗For pilot testing, service inquiries, and provider partnerships.
Manual sysctl and web-server tuning widens connection queues so the server stops rejecting handshakes at the door—but during a flood, the web server is forced to accept and process every concurrent TLS connection in user-space. In our 4-way test (1,500 attempted concurrent connections), “Tuned-Only” caused severe CPU starvation and spiked legitimate probe latency by +364% (1,286.3 ms average, up to 3,478.5 ms). Argus pairs hardware-calibrated tuning with sub-second eBPF/XDP driver filtering so offending traffic is cut off (at 430 observed connections in our test) before saturating NGINX, keeping legitimate probe responses at 277.3 ms average.
We tested CrowdSec v1.4.6 on Ubuntu 24.04 with the crowdsec-firewall-bouncer-iptables enforcement component and the standard crowdsecurity/linux and crowdsecurity/nginx collections monitoring /var/log/nginx/access.log and error.log. While CrowdSec also offers optional request-level AppSec integrations for HTTP inspection, in default file-tailing mode NGINX writes access.log entries only after an HTTP request completes or closes. Because the tested transport flood held keep-alive TLS sockets open without completing HTTP transactions, no access-log lines were emitted during the 20-second window (0 active decisions), while the local Go agent and bouncer used 62.3 MB RAM (13.2% of the 512 MB server) and 31.2% CPU. Argus complements application-layer controls by inspecting live kernel TCP socket states in memory with zero disk I/O, using 14.7 MB RAM (3.1%) and 5.8% CPU.
In the tested Ubuntu 24.04 configuration, administrative SSH access was preserved on both Port 22 and non-standard Port 2222 during active Port 443 mitigation (< 50 ms handshake response from the same blocked host IP). Argus inspects active sshd configuration and listening sockets at startup and registers them in a dual-layer eBPF driver and policy-routing exemption. Custom management ports and bastion rules are verified for your environment during pilot onboarding.
Argus is a host-level optimization and origin protection layer. It complements upstream CDNs and cloud firewalls by hardening the Linux origin itself against cache-bypassing HTTPS floods and socket exhaustion. Host filtering cannot prevent an upstream network pipe from being physically saturated beyond its bandwidth limit.
No. Argus operates at the Linux kernel, network driver, and reverse-proxy layers. No application code changes are required.
Provider and MSP licensing discussions are welcome. Start with a scoped evaluation, then agree on supported environments, rollout requirements, support responsibilities, and commercial terms.