DEV Community: Lia

Self-Hosted WAF with a Low False Positive Rate: Why It Matters

Lia — Wed, 30 Sep 2026 03:25:48 +0000

Self-Hosted WAF with a Low False Positive Rate: Why It Matters

When you shop for a WAF, the headline number everyone shows is detection rate — how much attack traffic it catches. That's important, but it's only half the story. The other half is the false positive rate (FPR): how often the WAF wrongly flags legitimate traffic as an attack. A WAF that blocks 100% of attacks but also blocks 20% of your real users is worse than no WAF at all.

If you self-host, a low-FPR WAF protects your traffic without becoming a daily source of "why is the site down?" tickets. Here's what to look for.

What a false positive actually costs

A false positive is a real, innocent request — a customer's login, a partner's API call, a search query with an odd character — that the WAF drops because it looked malicious. The consequences:

Lost conversions — blocked customers don't retry, they leave.
Broken integrations — a partner API call rejected mid-flow.
Alert fatigue — your team starts ignoring the WAF because it "always complains."

High FPR pushes teams to loosen rules until the WAF stops helping. Low FPR means you can keep protection tight without breaking the business.

Why some WAFs trip on false positives

Traditional signature-based WAFs match requests against a list of known attack patterns. That's brittle: an unusual-but-valid input — a SQL-looking string in a search box, an encoded parameter — can trip a rule that was meant for something else. The more rules you stack to catch attacks, the more innocent traffic you risk catching too.

How a semantic engine lowers the rate

A semantic-detection engine (the approach SafeLine uses) doesn't just pattern-match. It analyzes the intent of a request — whether it's actually trying to exploit something — rather than whether it contains a suspicious-looking substring. Valid-but-odd requests pass; genuinely malicious ones are blocked. That distinction is what keeps the false positive rate low.

In SafeLine's published benchmark (its BlazeHTTP test against tens of thousands of attack payloads), the Community Edition posted a 0.07% false positive rate while still detecting the large majority of attacks — markedly lower than the double-digit FPR seen in some signature-rule configurations of traditional WAFs in the same test. The point isn't the exact figure; it's that a semantic approach is designed to keep legitimate traffic flowing.

What to check before you commit

Request intent, not just signatures — ask whether the engine understands the request or just matches strings.
Tunable thresholds — you should be able to tighten or loosen without rewriting rules by hand.
Transparent logs — when something is blocked, you need to see why, fast.
Self-hosted fit — run it where your traffic already flows, with no per-request billing.

Deploying it

Bring up SafeLine as a reverse proxy in front of your app:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add your site, point its upstream at your app, and let the detection engine filter traffic. Review the logs for a day of real traffic, allowlist any legitimate patterns that surface, and you have tight protection with minimal noise.

FAQ

Is a low false positive rate the same as high detection?

No — they're independent. A WAF can be great at one and poor at the other. You want both: catch the attacks and let real traffic through.

Should I trust a vendor's benchmark number?

Treat published benchmarks as directional, not gospel — your traffic is the real test. Run the WAF in front of live traffic and watch the logs before drawing conclusions.

Will a semantic engine ever false-positive?

Any filter can, on sufficiently unusual input. The advantage is far fewer of them, and clear logs make the rare miss easy to spot and allowlist.

Is this free to self-host?

The Community Edition is free to run indefinitely and covers up to 10 apps at 800 QPS, with the same detection engine as the paid tiers.

That's it — you can run tight WAF protection without flooding your team with false alarms.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Detect and Block Malicious Bots (Without Blocking Real Users)

Lia — Wed, 30 Sep 2026 03:23:57 +0000

How to Detect and Block Malicious Bots (Without Blocking Real Users)

Not all bots are bad. Search engines crawl your site to index it; monitoring and webhooks call your APIs legitimately. The problem is the other kind — scrapers, credential stuffers, spam bots, and DDoS clients — that abuse your resources or probe for weaknesses. The trick isn't blocking bots wholesale; it's telling the good from the bad and acting on the difference.

Here's a practical approach, and where a self-hosted WAF like SafeLine fits.

First, recognize the traffic

Bots reveal themselves through patterns a human never produces:

Volume and rate — hundreds of requests from one source far faster than a person can click.
Repetitive paths — the same endpoint hammered in a loop (login, search, checkout).
Thin or spoofed headers — missing User-Agent, or a fingerprint shared across thousands of requests.
Behavioral tells — same sequence, same timing, no variation.

Legitimate bots (Googlebot, Bingbot, status checkers) usually identify themselves and behave predictably. The noisy, evasive ones are what you want to stop.

A layered response

Allowlist the good bots. If you want search engines to index you, let known crawlers through by identity rather than treating all automation as hostile.
Rate limit the rest. Cap requests per IP and per path so one client can't monopolize an endpoint.
Challenge the suspicious. Force a CAPTCHA or temporary block on clients that look automated but you're not certain about.
Block the known-bad. Drop traffic from sources with clear abuse signatures.

Where SafeLine fits

SafeLine is a self-hosted WAF that runs in reverse-proxy mode in front of your app, so every request passes through it first. For bot mitigation:

Bot management distinguishes automated clients from real users using behavioral and request analysis, so it can throttle or block the abusive ones while letting people through.
Rate limiting can be applied per path — ideal for login, search, and API endpoints that bots love to hammer.
Because it's self-hosted and free to run (Community Edition covers up to 10 apps at 800 QPS), you get bot protection without adding a per-request vendor bill.

The goal is surgical: stop the abuse, keep the legitimate traffic — including the good bots you actually want.

Putting it in front of your traffic

Deploy SafeLine as the proxy in front of your service:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add your site and point its upstream at your app. Enable bot mitigation, set rate limits on your highest-traffic paths, and allowlist the crawlers you trust. From there, malicious bots get throttled or blocked at the edge while real users and legitimate bots flow through.

FAQ

Won't blocking bots hurt my SEO?

Only if you block the good ones. Allowlist search-engine crawlers by identity and they'll index normally; you're targeting abusive automation, not legitimate crawlers.

Can a WAF tell a bot from a human reliably?

It uses behavioral and request signals, not a perfect test. Rate limiting and challenges handle the uncertain cases; outright abuse is blocked outright.

Do I need to write bot-detection rules myself?

No. SafeLine's bot management works out of the box; you tune thresholds and allowlists rather than hand-authoring detection logic.

Is this free to self-host?

Yes — the Community Edition is free to run indefinitely and covers up to 10 apps at 800 QPS.

That's it — your traffic now has bot filtering and rate limiting at the edge.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Prevent XSS with a WAF: Filter the Payload Before It Lands

Lia — Tue, 29 Sep 2026 03:12:36 +0000

How to Prevent XSS with a WAF: Filter the Payload Before It Lands

Cross-site scripting (XSS) is one of the oldest web vulnerabilities — and still one of the most common. It lets an attacker run script in your users' browsers: stealing sessions, defacing pages, or pivoting into deeper access. The good news is that XSS is also highly preventable, and a WAF is a strong first layer.

This guide covers where a WAF fits in XSS defense, and what your application still needs to do.

What XSS is, quickly

XSS happens when untrusted input is reflected into a page and executed as script. The classic case: a comment field that renders user text without escaping, so <script>...</script> runs in every visitor's browser. There are also stored and DOM-based variants, but the core problem is the same — untrusted data treated as code.

Where a WAF helps

A WAF sits in front of your app and inspects incoming requests. For XSS, that means it can block malicious payloads in the request — the <script> tags, event handlers, and obfuscated encodings — before they ever reach your application. That stops a large share of opportunistic, automated XSS attempts cold.

SafeLine, a self-hosted WAF, does this with a semantic detection engine that analyzes request content rather than matching a static signature list. It catches XSS patterns in parameters and bodies — including the kinds of encoding tricks attackers use to slip past naive filters — and drops the request at the edge.

A WAF is especially valuable as a safety net: even if a new input path ships without perfect escaping, the WAF catches the payload on the way in.

But a WAF is one layer, not the whole story

XSS defense is layered, and the application side matters just as much:

Output encoding / escaping — encode data for the context it's rendered in (HTML, attribute, JS, URL). This is the primary control.
Content-Security-Policy (CSP) — restrict which scripts can execute, drastically limiting the blast radius of any XSS that slips through.
Input validation — reject or sanitize unexpected input at the boundary.
HttpOnly + Secure cookies — make session cookies unreadable to script, so even a successful XSS can't easily steal a session.
Framework protections — most modern frameworks auto-escape; keep them on and avoid dangerouslySetInnerHTML-style escapes.

Think of the WAF as the perimeter and the app-side controls as the inner wall. Both should be in place.

Deploying the WAF layer

Bring up SafeLine as a reverse proxy in front of your app:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add your site and point its upstream at your app. With request filtering enabled, XSS payloads are blocked at the edge. Pair that with CSP and output encoding in your code, and XSS becomes a solved class of problem.

FAQ

Does a WAF fully prevent XSS on its own?

It blocks the majority of automated and known payloads, but it shouldn't be your only control. CSP and output encoding are still essential.

Will XSS filtering break legitimate form input?

Normal text passes through; only payloads that match attack patterns are blocked. Sanity-check your real forms after enabling, as you would with any new filter.

Is SafeLine's detection signature-based?

No — it uses a semantic engine that evaluates request intent, which catches obfuscated or encoded payloads that simple pattern lists miss.

Do I need to change app code to add the WAF?

No. It runs in front of your app as a proxy, so the filtering is infrastructure, not application logic.

That's it — your app now has a request-filtering layer against XSS at the edge.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Self-Hosted API Protection: How to Put a WAF in Front of Your API

Lia — Tue, 29 Sep 2026 03:10:27 +0000

Self-Hosted API Protection: How to Put a WAF in Front of Your API

APIs are where the valuable data lives — and where attackers go first. A public API endpoint is a direct door to your logic, your database, and your users' sessions. If you self-host your API, you can also self-host its first line of defense: a WAF sitting in front of it, filtering traffic before it reaches your handlers.

Here's how to protect a self-hosted API with a WAF, and where SafeLine fits.

Why APIs are attractive targets

Unlike a rendered web page, an API speaks machine-to-machine — and that means requests are structured, predictable, and easy to script. Attackers go after:

Authentication endpoints — credential stuffing, token abuse, brute force.
Injection in parameters — SQL or command injection through query strings and JSON bodies.
Abuse and scraping — automated clients hammering endpoints for data or compute.
Malformed payloads — probing for parser or deserialization bugs.

A WAF can't fix a broken auth scheme, but it can stop the bulk of automated abuse at the edge.

What a WAF does for an API

Placed as a reverse proxy in front of your API service, a WAF:

Inspects every request, including JSON bodies and query parameters, for attack patterns.
Blocks injection and known malicious payloads before they reach your code.
Rate limits per client, per key, or per path — so one abusive caller can't monopolize the API.
Manages bots, separating automated tooling from legitimate integrations.

Where SafeLine fits

SafeLine is a self-hosted WAF that runs in reverse-proxy mode, so you point your API's traffic at it and it forwards clean requests to your upstream service. For API protection specifically:

Its semantic detection engine analyzes request content — parameters, headers, and bodies — to catch injection and malicious payloads that static rules miss.
Rate limiting can be applied per path, which is ideal for throttling login, token, or search endpoints.
It's self-hosted and free to run (Community Edition covers up to 10 apps at 800 QPS), so protecting an internal or public API doesn't add a vendor bill.

SafeLine won't replace proper auth and input validation in your code — but it removes the flood of automated junk so your application logic only sees traffic worth handling.

Putting it in front of your API

Deploy SafeLine as the proxy in front of your API service:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add a site whose upstream is your API (for example http://127.0.0.1:8080). Route your API's DNS or gateway at SafeLine's listener, then set rate limits on your most-sensitive paths (auth, token refresh). From there, every request is filtered and throttled before it touches your API.

FAQ

Does a WAF replace API authentication?

No. You still need solid auth and authorization in your app. A WAF stops automated abuse and injection; it doesn't decide who's allowed in.

Will it break legitimate API clients?

Rate limits are set above normal client behavior, and the detection engine targets malicious patterns — legitimate requests pass through. Test against your real client traffic when configuring.

Can it inspect JSON request bodies?

Yes — a semantic engine evaluates the request content, including structured bodies, rather than only matching URLs or headers.

Is this free to self-host?

The Community Edition is free to run indefinitely and covers up to 10 apps at 800 QPS, which is plenty for a typical API footprint.

That's it — your API now has a filtering and rate-limiting layer in front of it.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Prevent Application-Layer DDoS Attacks on Your Web App

Lia — Mon, 28 Sep 2026 02:25:37 +0000

How to Prevent Application-Layer DDoS Attacks on Your Web App

Most people picture DDoS as a firehose of garbage packets aimed at a network. But the attacks that actually take down modern web apps are usually quieter: application-layer (L7) DDoS, where the flood looks like normal traffic. It's a wave of legitimate-looking HTTP requests designed to exhaust your app, database, or upstream.

Because the requests aren't obviously malicious, a plain firewall can't tell them apart from real users. A WAF in front of your app is the right place to draw the line. Here's how.

Why L7 DDoS is tricky

A network-layer DDoS is easy to spot — it's just volume. An application-layer attack blends in:

Requests hit real URLs with valid headers.
They may come from many IPs (a botnet), so blocking by address alone doesn't scale.
The damage comes from cost — each request triggers expensive work: a database query, a render, an API call.

The goal isn't to crash your server with bandwidth; it's to make your app do so much real work that it falls over.

The defense playbook

A few controls together blunt most L7 floods:

Filter the obviously bad. Drop malformed requests, known attack signatures, and malformed HTTP before they reach your app.
Rate limit per IP and per path. Cap how much any single client can ask of a given endpoint.
Manage bots. Identify and throttle automated clients; let humans through.
Cache aggressively. Serve static and repeatable responses from cache so they never reach your app.
Scale the origin behind the WAF so a spike doesn't instantly exhaust capacity.

Where SafeLine fits

SafeLine is a self-hosted WAF that runs as a reverse proxy in front of your app, so every request is inspected before it reaches your code:

The semantic detection engine filters abnormal and malicious HTTP traffic, dropping the junk that would otherwise hit your app.
Rate limiting caps requests per client and per path, so a flood can't monopolize your origin.
Bot management separates automated traffic from real users, letting you throttle or block the flood without hurting legitimate visitors.
Because it runs at the edge of your stack, malicious requests are stopped early — before they trigger expensive backend work.

SafeLine won't replace a full CDN-scale DDoS solution for nation-state-sized floods, but for the common L7 attacks that knock over small-to-mid web apps, it's a strong, self-hosted first line of defense.

Deploying it in front of your app

Bring up SafeLine as the proxy in front of your service:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add your site and point its upstream at your app. Enable bot mitigation and set sensible rate limits on your heaviest endpoints. Traffic is now filtered and throttled at the edge, so a flood has to get past the WAF before it can touch your app.

FAQ

Can a WAF stop all DDoS attacks?

It handles the common application-layer floods that target web apps. Very large volumetric attacks also need upstream/network mitigation, but most real-world incidents are L7 — exactly what a WAF addresses.

Won't rate limiting hurt real users during a spike?

Set limits above normal human patterns. Legitimate traffic sails through; only abusive automated volume gets throttled.

Does this replace caching and scaling?

No — they're complementary. SafeLine filters and throttles; caching and scaling absorb the rest. Together they're far more resilient than any one control.

Is this hard to self-host?

The one-line installer brings up the whole stack as containers, and the console walks you through adding a site.

That's it — your app now has a filtering and rate-limiting layer in front of it.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Stop Credential Stuffing Attacks: Protect Your Login Endpoints

Lia — Mon, 28 Sep 2026 02:20:58 +0000

How to Stop Credential Stuffing Attacks: Protect Your Login Endpoints

Credential stuffing is one of the most common — and most quietly damaging — attacks against web apps. It's not a clever exploit of a zero-day; it's brute force at scale, using passwords stolen from other breaches to log into accounts elsewhere. If your users reuse passwords (most do), some of those attempts will eventually work.

The good news: credential stuffing is largely automated, and automated traffic is exactly what a WAF placed in front of your login endpoint is good at stopping. Here's a practical defense.

What credential stuffing looks like

An attacker feeds a list of email:password pairs — harvested from past breaches — into a script that fires login requests at your site. Two traits give it away:

Volume from few sources — thousands of attempts from a narrow set of IPs or a botnet.
Automated behavior — requests arrive faster than a human types, often with missing headers, fingerprinted clients, or shared user-agents.

Humans don't log in 500 times a minute. Bots do.

Layer your defenses

No single control stops everything, but a few stack cleanly:

Rate limit the login path. Cap how many attempts a single IP or account can make per minute. Genuine users rarely need more than a handful.
Detect and challenge bots. Identify automated clients by behavior, not just IP, and challenge or block the ones that look like stuffing tools.
Add MFA or step-up auth for suspicious logins. Even a correct password from a flagged session hits a second factor.
Watch for credential-stuffing signatures — known-bad IP ranges, impossible travel, and repeated failures across many accounts.

Where SafeLine fits

SafeLine is a self-hosted WAF that sits in reverse-proxy mode in front of your app, so every login request passes through it first. For credential stuffing specifically:

Its semantic detection engine inspects requests and flags abnormal or malicious patterns before they reach your login handler.
Bot management distinguishes automated clients from real users, so scripted stuffing traffic can be throttled or blocked.
Frequency/rate limiting can be applied per path — including your login endpoint — to cap attempts and starve the attack of throughput.

SafeLine won't replace MFA, but it removes the bulk of automated noise before it ever touches your application logic.

Putting it in front of login

Deploy SafeLine as the reverse proxy in front of your service:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

In the console at https://<your-server-ip>:9443, add your app and point its upstream at your login service. Then configure a frequency limit on the login route so no single source can hammer it. From that point, login attempts are filtered and rate-limited at the edge.

FAQ

Does a WAF alone stop credential stuffing?

It removes the bulk of automated traffic, but pairing it with MFA and account-level lockouts closes the gaps a WAF can't see.

Will rate limiting lock out real users?

Set limits above normal human behavior (a few attempts per minute), and legitimate users are unaffected while bots are throttled.

Is this the same as a brute-force attack?

Similar, but credential stuffing uses real leaked credentials rather than guessing randomly — which is why detecting automation matters more than detecting wrong passwords.

Do I need to change my app code?

No. SafeLine operates in front of your app as a proxy, so the defense is infrastructure, not application logic.

That's it — your login endpoint now has a layer of automated protection in front of it.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Free WAF for Self-Hosted Apps: Protect Your Stack Without the Bill

Lia — Thu, 24 Sep 2026 02:29:11 +0000

Free WAF for Self-Hosted Apps: Protect Your Stack Without the Bill

If you self-host your apps, you've already committed to owning the infrastructure. That's good news for security: it means you can drop a free WAF in front of your stack without signing up for another monthly bill. For anyone running services on a VPS, a homelab, or a small cloud instance, a self-hosted WAF is some of the cheapest insurance you can buy.

Here's how to protect self-hosted apps for free, and why SafeLine's Community Edition is a practical default.

Why self-hosted apps need a WAF

Any app you expose to the internet — a dashboard, an API, a CMS — is a target. Attackers scan for injection flaws, exposed admin panels, and known exploits automatically, around the clock. A WAF sits in front of your app and filters that traffic before it reaches your code.

The catch with many WAFs is the price: cloud services bill per request or per protected app, which adds up fast across a self-hosted stack with several services. Running the WAF yourself removes that line item.

What "free" should still give you

Not all free WAFs are equal. A free option is only worth it if it does the job:

Blocks the common web attacks (SQL injection, XSS) by default.
Mitigates automated bots and credential stuffing.
Deploys in minutes, not days.
Runs on hardware you already have.

If a "free" tool needs you to write a pile of rules before it blocks anything, it isn't really free in time.

SafeLine Community Edition: a free self-hosted pick

SafeLine is a self-hosted WAF by Chaitin, and its Community Edition is free to run indefinitely. It covers up to 10 applications at 800 QPS, which is plenty for a personal stack or a small set of self-hosted services.

Under the hood it uses a semantic detection engine — it analyzes request intent rather than matching a static signature list — to catch injection and bot traffic. You get the protection without becoming a rule-tuning specialist.

Deploying it in a few minutes

The one-line installer brings up the full stack (management console, detection engine, database, and cache) as containers:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Then:

Open the console at https://<your-server-ip>:9443.
Add a site and set its upstream to your app (for example http://127.0.0.1:8080).
Point your DNS or reverse proxy at SafeLine's listener.

That's it — traffic now flows through the WAF before reaching your app. The minimum host is modest: about 1 CPU, 1 GB RAM, and 5 GB disk.

When free stops being enough

The Community Edition's two caps are 10 apps and 800 QPS. If you run more services or push more traffic, the paid tiers lift those limits — Lite raises the app cap, and Pro removes it entirely — while keeping the same detection engine. You upgrade for headroom, not for better protection.

FAQ

Is this really free, or a trial?

The Community Edition is free to run with no time limit. The only constraints are the 10-app and 800-QPS ceilings.

Can it sit in front of multiple apps?

Yes — up to 10 on the free tier. Each protected site or API counts as one app.

Do I need to write detection rules?

No. The semantic engine blocks common attacks out of the box; you tune only if you want to.

What if I outgrow the free tier later?

Upgrading is a licensing change that raises the caps; your configuration and protected sites carry over.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Best Self-Hosted WAF for Small Business: What to Look For

Lia — Thu, 24 Sep 2026 02:27:29 +0000

Best Self-Hosted WAF for Small Business: What to Look For

Small businesses get attacked at roughly the same rate as everyone else, but they rarely have a security team to absorb the hit. A web application firewall (WAF) is one of the highest-leverage defenses you can put in front of your site — and for a small business, a self-hosted WAF is often the most sensible way to run one.

This guide walks through what actually matters when you're picking a WAF for a small business, and why a self-hosted option like SafeLine's free Community Edition deserves a serious look.

What a small business actually needs from a WAF

Enterprise WAF buying guides are full of features most small businesses will never touch. Strip it back to what you really need:

Protection from the common stuff — SQL injection, cross-site scripting, and automated bots are the daily background noise of the internet. A WAF should block these out of the box, without you hand-writing rules.
Easy to set up — if deployment takes a senior engineer a week, it won't happen. The best WAF for a small business is the one you'll actually turn on.
Low or no cost — small margins mean every recurring subscription is a decision. Free is a strong default when the protection is real.
Minimal upkeep — you don't have spare cycles to babysit it. It should run quietly once configured.

Why self-hosted fits small businesses

A self-hosted WAF runs on infrastructure you already control — a spare VM, a small VPS, or a node in your existing stack. That changes the economics in your favor:

No per-app or per-request billing. Cloud WAFs often charge by traffic or by the number of protected services. Self-hosted shifts that to a flat server cost you're likely already paying.
Data stays with you. Traffic inspection happens on your own hardware, which matters if you have residency or compliance preferences.
No lock-in. You're not tied to one vendor's console, pricing changes, or feature gates.

The trade-off is real but small: you own the box, so you handle the host. For most small businesses that's a fair exchange for removing a monthly bill.

How to evaluate options

When you compare self-hosted WAFs, score them on four things:

Detection quality — does it actually catch injection and bot traffic, or just pattern-match a stale signature list?
Install friction — how many commands from zero to a protected site?
Resource footprint — can it run on a modest box alongside other services?
Price ceiling — what do you pay as you grow?

Where SafeLine fits

SafeLine is a self-hosted WAF by Chaitin. Its free Community Edition is a strong fit for small businesses because it covers the needs above without a subscription:

Free forever, self-hosted, and covers up to 10 applications at 800 QPS.
Ships with a semantic detection engine that blocks SQL injection, XSS, and bots without signature tuning.
Installs with a single command and runs on a modest host — roughly 1 CPU, 1 GB RAM, and 5 GB disk at minimum.
Management console on https://<your-server-ip>:9443.

That combination — free, low-footprint, and genuinely protective — is exactly what most small businesses are looking for.

Getting started

The fastest path is the one-line installer, which brings up the whole stack (console, detection engine, database, cache) as containers:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Open the console, add your first site, and point its upstream at your app. If you grow past 10 apps or 800 QPS, paid tiers (Lite and Pro) raise the ceiling without changing how the WAF behaves.

FAQ

Do I need a WAF if I already use HTTPS?

Yes. HTTPS encrypts traffic; it doesn't stop an attacker from sending a malicious request to your login form. A WAF inspects what's inside the request.

Is the free tier enough for a small business?

Often, yes — 10 apps at 800 QPS covers a typical small-business footprint. Upgrade only when you outgrow those caps.

Will running it myself be a lot of work?

Minimal. Once installed and pointed at your sites, it runs as a background service. You check the console occasionally, like any other server component.

What if I don't have a spare server?

A small VPS (the size that runs the console) is enough to start, and it can often share the host with other lightweight services.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine WAF Pricing: Community vs Pro — Which Should You Choose?

Lia — Wed, 23 Sep 2026 02:28:15 +0000

SafeLine WAF Pricing: Community vs Pro — Which Should You Choose?

When you're picking a WAF, the pricing question usually isn't "can I afford it" but "which tier actually matches my setup." SafeLine makes this unusually simple: the free Community Edition and the paid Pro plan run the same detection engine. You're not buying better protection as you pay more — you're buying more headroom.

Here's how to decide which tier fits before you deploy.

The short version

Tier	Price	Applications	Throughput
Community	Free	10	800 QPS
Lite	~$10 / month	20	higher cap
Pro	~$100 / month	Unlimited	higher cap

Two things stand out. First, the free tier is genuinely usable — 10 apps at 800 QPS covers a lot of real workloads. Second, the only thing paid tiers change is capacity. The WAF behavior is identical.

Community: start here by default

Unless you already know you'll exceed the free caps, begin on the Community Edition. It's free forever, self-hosted, and includes the full detection engine — SQL injection and XSS blocking, bot mitigation, and the reverse-proxy mode that sits in front of your upstreams.

For a personal project, a small business with a handful of sites, or a staging environment, Community is often the only tier you'll ever need. There's no reason to pre-pay for headroom you haven't measured yet.

Pro: when scale is the constraint

Pro (~$100/month) removes the application cap entirely — unlimited applications — and raises the throughput envelope well above the free tier's 800 QPS. Choose it when:

You're protecting more than ten distinct apps or APIs.
Your traffic regularly pushes past 800 QPS.
You're standardizing WAF protection across a growing estate and don't want to count seats.

You're not getting "more security" than Community; you're removing the two ceilings that would otherwise block you from scaling.

Lite: the middle step

Between them sits Lite (~$10/month), which doubles the app cap to 20 applications. If you've outgrown free but don't need unlimited scale, Lite is the quiet winner — a small monthly cost for a meaningful capacity bump.

How to choose in practice

Under 10 apps and under 800 QPS? Stay on Community. Done.
Between 10 and 20 apps? Lite covers you for about the price of a coffee per week.
Over 20 apps, or unpredictable growth? Pro's unlimited cap removes the question.

Because the engine is the same everywhere, you can start free, watch your real app count and QPS in the console, and upgrade only when the numbers tell you to. There's no penalty for beginning on the free tier.

FAQ

Is Pro's WAF protection better than Community's?

No — the detection engine is identical. Pro lifts the app and throughput limits; it doesn't change how attacks are detected or blocked.

Can I upgrade later without reconfiguring everything?

Yes. Moving up is a licensing change that raises the caps. Your protected sites and configuration carry over.

Why would I pay if the free tier has the same engine?

Only if you exceed the 10-app or 800-QPS ceiling. If you don't, Community is the right answer and costs nothing.

Is there a trial of Pro?

The Community Edition is free to run indefinitely, so you can validate the engine on real traffic before deciding whether a paid tier's headroom is worth it.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine WAF Community Edition Limitations: What You Get for Free

Lia — Wed, 23 Sep 2026 02:24:34 +0000

SafeLine WAF Community Edition Limitations: What You Get for Free

SafeLine ships a free Community Edition that you can run on your own server with no time limit and no feature trial. That makes it one of the few self-hosted WAFs you can actually put in front of production traffic without pulling out a credit card. But "free" does come with a ceiling, and it's worth knowing exactly where that ceiling sits before you commit.

This article walks through what the Community Edition includes, the two hard limits you'll hit, and the point at which stepping up to a paid tier makes sense.

What the Community Edition actually gives you

The free tier is not a stripped-down demo. It's the same detection engine that powers the paid plans, just with capacity caps. Concretely, the Community Edition covers:

Up to 10 applications behind the WAF.
Up to 800 QPS (queries per second) of protected traffic.
The core semantic detection engine — the part that blocks SQL injection, XSS, bot traffic, and common web exploits without signature tuning.
A management console, logs, and the reverse-proxy mode that sits in front of your upstream services.

If your setup fits inside those two numbers, you get the full protective value of SafeLine at zero cost. For a personal site, a small portfolio of internal tools, or a handful of low-traffic services, that's often the entire story.

Where the limits actually bite

There are exactly two hard constraints on the Community Edition, and both are about scale rather than features:

10 applications. Each protected site or API counts as one app. Once you pass ten, you can't add more on the free tier.
800 QPS. This is the throughput ceiling for inspected traffic. Bursts above it won't be denied outright, but you've left the envelope the free tier is sized for.

Notice what isn't limited: there's no expiry, no blocked attack category, and no "contact sales after 14 days" wall. The limits are capacity, not capability. That's a meaningful difference from vendors who gate the actual protection behind a paid plan.

When it's time to move up

If you're consistently near either cap — or you simply expect to grow past it — SafeLine offers two paid tiers that lift the ceilings rather than change how the WAF behaves:

Lite — roughly $10/month, raising the cap to 20 applications. A small step up for growing teams.
Pro — roughly $100/month, with unlimited applications for larger estates.

Because the detection engine is identical across tiers, upgrading is about headroom, not about suddenly getting better protection. You move up when your app count or traffic volume demands it, not because the free tier is "missing" a feature.

Getting started on the free tier

The fastest way to see the Community Edition in action is the one-line installer, which brings up the whole stack (console, detection engine, database, cache) as containers:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Once it finishes, open the console at https://<your-server-ip>:9443, add your first site, and point its upstream at your app. You're now protecting up to 10 applications at 800 QPS for free.

FAQ

Is the Community Edition a time-limited trial?

No. It's free to run indefinitely. The only constraints are the 10-app and 800-QPS ceilings.

What happens if I exceed 800 QPS?

The limit is a sizing ceiling, not a hard cutoff that starts dropping traffic. But if you're consistently above it, a paid tier gives you the headroom to run comfortably.

Do I lose any protection features on the free tier?

The detection capabilities are the same across tiers. Paid plans raise the app and throughput limits; they don't unlock a separate set of WAF features.

Can I switch from Community to Pro later?

Yes. Since the engine is the same, moving up is a licensing change that lifts the caps — your configuration and protected sites carry over.

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

SafeLine WAF Docker Compose Example

Lia — Tue, 22 Sep 2026 03:23:26 +0000

SafeLine WAF Docker Compose Example

SafeLine ships as a set of containers, and Docker Compose is the simplest way to bring up the whole stack — management console, detection engine, and the supporting database and cache — on a single host.

The fastest path

The official one-line installer handles the compose file for you:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

It writes a docker-compose.yml in the SafeLine directory and starts the services. After it finishes, open the console at https://<host-ip>:9443 to add your protected sites.

What the stack contains

A typical SafeLine compose defines a few services working together:

Management console — the web UI on :9443 where you configure sites and view logs.
Detection engine / proxy — the component that actually inspects and forwards traffic on :80 / :443.
Database — stores configuration and records.
Cache — used for session and challenge state.

An illustrative compose looks like:

services:
  safeline-mgt:            # management console
    image: chaitin/safeline-mgt:latest
    ports: ["9443:9443"]
  safeline-detector:       # inspection + reverse proxy
    image: chaitin/safeline-detector:latest
    ports: ["80:80", "443:443"]
  safeline-pg:             # database
    image: chaitin/safeline-pg:latest
  safeline-redis:          # cache
    image: chaitin/safeline-redis:latest

Treat the exact image names, tags, and ports above as illustrative — pull the authoritative docker-compose.yml from the official installer or docs, since these can change between versions.

Customizing

Once it's up, common tweaks:

Persist data — add named volumes for the database and config so they survive container recreation.
Change ports — if :80/:443 are taken, map the proxy to different host ports and adjust your upstream/DNS accordingly.
Protect a site — in the console, add a site whose upstream is your app (e.g. http://127.0.0.1:8080).

FAQ

Do I need to write the compose myself?

No — the installer generates it. Hand-writing is only if you want a custom layout.

Can I run it alongside other compose stacks?

Yes; just keep the ports and volume names from colliding with other services.

Free tier?

The Community Edition covers 10 apps at 800 QPS for free.

That's it — a single compose stack gives you a running self-hosted WAF.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Set Up SafeLine WAF on Kubernetes

Lia — Tue, 22 Sep 2026 03:21:31 +0000

How to Set Up SafeLine WAF on Kubernetes

If your apps already run on Kubernetes, SafeLine fits right in — it's a containerized reverse-proxy WAF, so you deploy it like any other workload and route protected traffic through it.

Where SafeLine sits

Client → Ingress / LoadBalancer → SafeLine Service → SafeLine pod → upstream app Service

SafeLine becomes the inspection tier in front of the services you want to protect. Each protected app is configured as an upstream pointing at its in-cluster Service DNS (for example http://my-app.default.svc.cluster.local:8080).

Approach

The common pattern:

Deploy SafeLine as a Deployment + Service. The Service exposes the console port (:9443) for management and the proxy ports (:80 / :443) that receive inspected traffic.
Point your Ingress (or LoadBalancer) at the SafeLine Service for the hosts you want protected, instead of pointing directly at the app.
Add protected sites in the SafeLine console (https://<safeline-ip>:9443), with each upstream set to the target app's cluster-internal Service address.

A minimal Deployment shape looks like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: safeline
  namespace: safeline
spec:
  replicas: 1
  selector:
    matchLabels: { app: safeline }
  template:
    metadata:
      labels: { app: safeline }
    spec:
      containers:
        - name: safeline
          image: chaitin/safeline:latest   # confirm the exact image/tag in the official docs
          ports:
            - { containerPort: 9443 }      # management console
            - { containerPort: 80 }        # proxy
            - { containerPort: 443 }       # proxy (TLS)
          resources:
            requests: { cpu: "1", memory: "1Gi" }

Confirm the exact image, tag, and any companion services (database / cache the stack uses) against the official documentation before applying.

Persistence and scaling

Mount a PersistentVolumeClaim for SafeLine's config and logs so they survive pod restarts.
For higher throughput, scale replicas and keep configuration consistent across them.

FAQ

Can one SafeLine protect several apps in the cluster?

Yes — each protected site maps a domain to an in-cluster Service upstream, so multiple apps behind one SafeLine is straightforward.

Where do I terminate TLS?

Either at SafeLine or at your Ingress; forward to the upstream over HTTP or HTTPS as you prefer.

Free tier?

The Community Edition covers 10 apps at 800 QPS for free.

That's it — SafeLine runs as a normal Kubernetes workload and filters traffic to your services.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)