Get Answers,
Get Unblocked.

WAFio is a self-hosted security platform that combines three independent protection layers: an L7 Web Application Firewall with 14 semantic detection engines, an L3/L4 eBPF Network Firewall using XDP/TC kernel hooks, and kernel-level Runtime Security via eBPF kprobes. Everything runs inside your own infrastructure — no third-party cloud, no traffic proxying, no vendor dependency.

WAFio software is completely free — no tiers, no feature locks, no license keys, no agent limits. Every feature including all 14 semantic engines, the eBPF firewall, runtime security, and the full dashboard is included at no cost. For teams that need hands-on help, professional services are available: installation, SLA support contracts, and hardening audits. See <a href="/services">Services</a>.

WAFio follows an open-core model. Core detection logic, configuration schema, and deployment tooling are publicly available. The platform is freely downloadable and self-hostable without registration or license keys.

No. Download the binary, configure it, and run it. No sign-up, no API key, no phone-home required. WAFio does not require any external account to operate.

WAFio is built for any team that needs real application security without a SaaS dependency: individual developers, startups, SMEs, schools, government portals, fintech, e-commerce platforms, and regulated enterprises. The same binary protects a single VPS and a multi-host production fleet.

WAFio replaces the traffic inspection, injection detection, rate limiting, and network filtering functions of a cloud WAF — while keeping all data inside your own infrastructure. It adds two layers cloud WAFs cannot provide: eBPF kernel-level network filtering and runtime process security inside the host.

WAFio requires a Linux host (kernel ≥ 5.8 with BTF enabled for eBPF features), root or CAP_BPF privileges, and a 64-bit x86_64 architecture. The control plane and WAF agent run on most Linux distributions with minimal RAM overhead. The host agent requires a kernel with BTF support — most distributions shipping kernel 5.8+ satisfy this.

Any distribution running Linux kernel ≥ 5.8 with BTF enabled. This includes Ubuntu 20.04+, Debian 11+, CentOS Stream 9, Rocky Linux 9, Fedora 34+, and most modern cloud provider images (AWS AL2023, GCP COS, Azure Ubuntu). Older kernels without BTF support the WAF agent but not the eBPF host agent.

Yes. A single server can run the control plane, WAF agent, and host agent together. For development or small deployments, even a 1GB RAM VPS is sufficient to start. Production workloads benefit from dedicated agent hosts, but it is not required.

A basic deployment — control plane + WAF agent protecting one application — takes approximately 5 minutes. This includes downloading the binary, writing a minimal config file, and starting the service. Full eBPF host agent setup with systemd integration takes 15–20 minutes.

No. WAFio is a reverse proxy sidecar. The WAF agent sits in front of your application and intercepts HTTP traffic transparently. No SDK, no library, no code change required. Works with any language, framework, or runtime.

Yes. WAFio has no mandatory outbound connections. The binary is self-contained. Rule updates and configuration changes are pushed from your own control plane to agents via gRPC — no internet access required anywhere in the data path.

Yes. The WAF agent runs as a container or sidecar. The host agent is container-aware via cgroup and namespace attribution — events from containers are tagged with container ID, image name, and Kubernetes pod/namespace metadata. Works with Docker, Podman, and Kubernetes.

No. WAFio is Linux-only. The WAF agent, host agent, and eBPF subsystem are compiled exclusively for Linux x86_64. Windows Server is not supported and there are no plans to add Windows support — eBPF is a Linux kernel feature with no equivalent on Windows, and the runtime security layer depends on Linux kprobes and tracepoints. If you run Windows Server as your application host, consider running WAFio on a Linux VM or container in front of the Windows server and proxying HTTP traffic through it.

macOS is supported for the control plane in development environments — you can run the wafio control plane binary on macOS for local testing. However, the WAF agent and host agent are Linux-only for production use. FreeBSD, OpenBSD, and other BSDs are not supported. Production deployments must use a Linux host for agent nodes.

Current official builds target Linux x86_64. ARM64 builds are not yet in the official release pipeline. Running WAFio on AWS Graviton, Ampere, or Raspberry Pi requires compiling from source with GOARCH=arm64 — the Go codebase is architecture-agnostic, but eBPF CO-RE objects need to be compiled with the correct target architecture. Contact us at hello@wafio.cloud for the latest ARM64 build status.

It depends on the hosting type. Shared cPanel hosting is not supported — shared hosts do not provide root access or the ability to run custom system services. On a cPanel VPS or dedicated server with root access, WAFio can run alongside cPanel/WHM with some configuration. The standard approach: reconfigure Apache to listen on a non-standard port (e.g., 8080) via WHM → Apache Configuration → Global Configuration → HTTP Port, then run WAFio's WAF agent on port 80/443 as the front-facing proxy. WAFio forwards clean traffic to Apache on 8080. cPanel's "Reverse Proxy" feature in WHM (Apache → Module Handlers) can also assist with this routing. eBPF firewall and Runtime Security features require kernel ≥ 5.8 with BTF — available on modern CloudLinux 9 or AlmaLinux 9 cPanel hosts, but not on older CentOS 6/7 stacks. For managed cPanel environments where port changes are restricted, contact your host to confirm whether a reverse proxy configuration is permitted before deploying.

WAFio's 14 semantic engines detect: SQL injection, XSS, command injection, Local File Inclusion (LFI), Server-Side Request Forgery (SSRF), LDAP injection, prototype pollution, Java deserialization / Log4Shell, PHP injection, Python injection, NoSQL injection, Server-Side Template Injection (SSTI), XML External Entity (XXE), and deserialization attacks. On top of these, OWASP CRS v4 adds 3,500+ signature-based rules covering additional attack categories.

Each semantic engine decodes, normalizes, and parses the payload for its target attack category. URL encoding, Base64, hex encoding, comment injection, whitespace tricks, and protocol obfuscation are all unwrapped before analysis. The engine evaluates the intent of the payload — not just its shape — making it resistant to common signature bypass techniques.

The eBPF Network Firewall uses XDP (eXpress Data Path) and TC hooks to inspect and drop packets at the kernel driver level — before the Linux network stack processes them. It blocks traffic based on individual IPs, CIDR ranges, ASNs (autonomous systems), port/protocol combinations, and per-source rate limits. Effective against SYN floods, port scans, brute force, and IP-based attack infrastructure.

Runtime Security uses eBPF kprobes and tracepoints to monitor live kernel activity: process execution (execve), file system operations (open, write, unlink on sensitive paths), outbound connections (connect, bind), privilege changes, and container boundary events. Every event is enriched with PID, parent process tree, binary hash, user, cgroup, and namespace identifiers.

OWASP Core Rule Set v4 is a community-maintained set of 3,500+ generic attack detection rules for HTTP applications. WAFio bundles CRS v4 and runs it via the Coraza engine alongside its own semantic layer. CRS detections are scored and filtered through WAFio's Decision Engine — Coraza never blocks directly; only the Decision Engine emits BLOCK/LOG/ALLOW.

Yes. The Java semantic engine specifically handles Log4j JNDI lookup obfuscation: nested ${lower:...} and ${upper:...} lookups are recursively unfolded up to 10 levels deep. URL-encoded colons and slashes in JNDI strings are decoded before analysis. Log4Shell variants that bypass single-pass detection are covered.

WAFio blocks the attack vectors that lead to SEO hijacking (SQL injection, LFI, RFI, malicious file uploads) at the HTTP layer before they reach the application. If an attacker finds another entry point, Runtime Security detects the spawned web shell process via kprobe on execve — a web server spawning /bin/bash triggers an immediate alert.

All WAFs can produce false positives. WAFio's Decision Engine uses configurable sensitivity levels (Safe / Balanced / Aggressive) and score thresholds per project. In Balanced mode with default thresholds, false positive rates on standard web applications are very low. You can tune per-project sensitivity, raise score thresholds, or add path exceptions for specific endpoints.

Each project has a configurable sensitivity level: Safe (1), Balanced (2), or Aggressive (3). Rules with a sensitivity level higher than your project setting are silently dropped — this is the primary false positive control. Lower sensitivity = fewer detections, fewer false positives. Raise it for higher-risk environments.

WAFio's Decision Engine sums weighted scores from matched rules. Requests above the block_threshold (default 5.0) receive HTTP 403. Requests between log_threshold (default 2.0) and block_threshold are logged but allowed. Below log_threshold, requests pass silently. Both thresholds are configurable per project via the dashboard or rules JSON.

WAFio supports path exceptions: configure specific URL paths to skip individual rule categories (e.g., skip SQL semantic check on /api/search while keeping XSS protection active). This is done per-project in the WAF configuration. Health check paths and webhook endpoints are common candidates for partial exceptions.

Yes. WAFio includes GeoIP country blocking. In the project WAF configuration, add country codes to the block list. Country identification uses MaxMind GeoIP data bundled with WAFio. Blocked requests receive a configurable HTTP response.

Yes — at two layers. The eBPF Network Firewall handles IP/CIDR/ASN blocks at the kernel level (dropped before userspace). The WAF agent also maintains block and allow lists at the application layer. Both are manageable from the dashboard in real-time, with no agent restart required.

WAFio's Decision Engine maps Coraza/CRS rule IDs to threat categories with configurable base scores and sensitivity levels. To add a custom rule: define the rule in CRS-compatible format, add a RuleMeta entry mapping the rule ID to a category and score. Custom rules can be deployed via the project rules_json configuration.

Yes. WAFio is multi-tenant. Each project has its own WAF configuration: sensitivity level, score thresholds, blocked countries, rate limit settings, and path exceptions. One control plane manages multiple projects and agents independently.

The WAF agent adds a p99 detection latency of under 5ms per request. For most applications, the actual overhead is 1–3ms. The eBPF firewall adds sub-microsecond per-packet overhead for blocked traffic (dropped at kernel driver level). Allowed traffic passes with near-zero overhead. Runtime Security uses eBPF with no sampling — overhead is negligible for typical syscall rates.

The WAF agent uses approximately 50–150MB RAM under typical load, depending on concurrent request volume and rule set size. The control plane uses 80–200MB. The host agent is lightweight — eBPF programs run in the kernel and the userspace agent consumes minimal CPU. Resource usage scales linearly with request volume.

WAFio is designed to fail-open on agent panic. If a detection engine panics, the request is allowed through with an error metric recorded — your application continues to serve traffic. The agent also supports zero-downtime upgrades via tableflip: SIGUSR2 spawns a new process that inherits listeners, drains the old one, and exits cleanly.

Download the new binary and replace the existing one. For systemd deployments, send SIGUSR2 for zero-downtime reload (tableflip), or do a standard systemctl restart. Database migrations run automatically on startup with the --migrate flag, or manually via the wafio migrate up command.

Yes. Multiple WAF agents can connect to a single control plane. Agents receive configuration updates via gRPC bidirectional streaming — rule changes push to all agents without restart. The control plane itself can run behind a load balancer. Database (PostgreSQL + TimescaleDB) is the stateful component.

The control plane maintains a persistent gRPC bidirectional stream with each agent. When you update a project's WAF configuration in the dashboard, the new bundle is pushed to all connected agents immediately. No agent restart, no polling delay.

No. WAFio is fully self-hosted. No request payload, IP address, user session, or security log is sent to WAFio servers or any third-party infrastructure. All data stays inside your own network. There is no telemetry, no phone-home, and no cloud dependency in the data path.

WAF decision events are stored in your PostgreSQL + TimescaleDB database (waf_decisions table, hypertable partitioned by time with 30-day auto-retention). Host security events are stored in the same database. Manticore Search is used for fast dashboard queries. All storage is inside your own infrastructure.

WAFio's architecture supports compliance requirements that mandate data sovereignty: no request payload leaves your server, no third-party processes your traffic, and audit logs are fully under your control. Compliance status depends on your overall environment and controls — WAFio provides the infrastructure foundation, not a compliance certificate.

Yes. WAFio has no mandatory outbound connections. Data residency is architectural — all processing happens inside your network. Air-gapped deployments (no internet access) are fully supported.

First, check the dashboard for the blocked request details: which rule category triggered, the score, and the matched payload. Options to fix: (1) Lower project sensitivity from Aggressive to Balanced. (2) Raise the block_threshold. (3) Add a path exception for the affected endpoint. (4) Increase the RuleMeta.Sensitivity for the specific noisy rule to prevent it from scoring at your current sensitivity level.

Verify the WAF agent is connected: check agent status in the dashboard or look for "bundle received" in the agent log. Confirm the agent is configured as the upstream proxy for your application (traffic must route through the WAF agent, not bypass it). Check that the control plane is reachable from the agent host on the gRPC port (default :9090).

Common causes: (1) mTLS certificate mismatch — re-provision the agent credential from the dashboard. (2) Wrong gRPC server address or port — check WAFIO_GRPC_SERVER in agent config. (3) SNI mismatch if connecting over IP — set WAFIO_GRPC_SERVER_NAME to the server's hostname. (4) Firewall blocking port 9090 on the control plane host.

The host agent requires a Linux kernel ≥ 5.8 with BTF (BPF Type Format) enabled. Check: uname -r (kernel version) and ls /sys/kernel/btf/vmlinux (BTF present). The agent must run as root or with CAP_BPF + CAP_PERFMON capabilities. Check systemd unit file for the correct User and AmbientCapabilities settings.

Login endpoints often send passwords or tokens that trigger detection rules (special characters, base64 content). Solutions: (1) Add a path exception for /login or /api/auth that skips specific rule categories. (2) If the endpoint is internal-only, use the AllowLocalIPs configuration to bypass bot challenge for local/private address ranges. (3) Add the endpoint to the path exception list in the project WAF config.

Run wafio migrate up manually from the directory containing config.yaml to see the specific error. Common causes: PostgreSQL TimescaleDB extension not installed (run CREATE EXTENSION IF NOT EXISTS timescaledb in psql), wrong database credentials, or a migration version mismatch. Use wafio migrate version to check current state.

Send a detailed report to hello@wafio.cloud with a description of the vulnerability, reproduction steps, and potential impact. Do not discuss security vulnerabilities in public channels. We aim to acknowledge reports within 48 hours and provide a remediation timeline within 5 business days.