Self-hosted service
chaitin/SafeLine avatar
chaitin/SafeLine

SafeLine: A Self-Hosted WAF with Strict Defaults and a Cloud Dependency to Check

SafeLine is a self-hosted WAF(Web Application Firewall) / reverse proxy to protect your web apps from attacks and exploits.

22,597 stars1,531 forksGoGPL-3.0

At a glance

What is it?
SafeLine is a Go-based, self-hosted web application firewall and reverse proxy that blocks SQL injection, XSS, and bot traffic. Its detection rates look strong, but the quickstart warns of cloud service dependencies that may complicate offline use.
Who is it for?
Adopt SafeLine if you run a small to mid-sized web app, want a self-hosted WAF with a web UI, and can tolerate a cloud connection for updates and possibly management. Skip it if you need a fully offline WAF, if your traffic exceeds the documented rate limits, or if you cannot verify the cloud dependency in your region.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 5 days ago.
What is it written in?
Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What SafeLine Actually Solves

SafeLine is a self-hosted web application firewall and reverse proxy. It sits between the internet and your web server, filtering HTTP and HTTPS traffic before it reaches the application. The README lists specific attack classes it blocks: SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. That is a broad set, but the core value is simpler: you get a WAF you control, without sending traffic to a commercial cloud provider. The intended user is someone who runs a web app, wants protection against common automated attacks, and prefers self-hosting over a SaaS WAF. The README claims over 400,000 installations, but you should treat that as a marketing figure, not a technical specification.

How the Reverse Proxy and Detection Engine Work

SafeLine acts as a reverse proxy. Clients connect to SafeLine, not directly to your origin server. SafeLine inspects each request, applies its policy set, and forwards allowed traffic to the backend. The README describes this as placing a shield between the web application and the internet. The detection engine covers the standard OWASP-style attack categories, but it also includes two non-standard features: dynamic protection and anti-bot challenges. Dynamic protection encrypts HTML and JS code on each visit, so the content changes per request. Anti-bot challenges present a puzzle to visitors; humans pass, while crawlers and bots get blocked. The rate limiting feature throttles traffic that exceeds defined limits, which the README ties to DoS attacks, brute force attempts, and traffic surges. The architecture is a typical reverse proxy with a policy engine, but the dynamic encryption is a distinctive mechanism that goes beyond simple signature matching.

Installing and Configuring SafeLine

The README points to an install guide for deployment details, but it does not include a direct Docker command in the text you provided. The quickstart section links to the install guide at docs.waf.chaitin.com, and it warns that users in mainland China may need the Chinese installation docs for cloud service connectivity. That warning is a critical config detail: SafeLine appears to require a connection to a cloud service, at least for some functions. The configuration guide for adding applications is also external, so you will need to consult those docs to set up your first protected site. The README mentions a live demo at demo.waf.chaitin.com:9443, which gives you a way to see the UI before installing. You can also check the MCP server for AI-assisted management, and there are integrations for Ingress-NGINX and Kong Gateway, but those are separate SDKs.

The Effect Evaluation Table and What It Really Shows

The README includes a comparison table with ModSecurity, CloudFlare Free, and SafeLine in two presets. On 33,669 samples, SafeLine's Balance preset shows 71.65% detection and 0.07% false positives, while the Strict preset shows 76.17% detection and 0.22% false positives. ModSecurity Level 1 detects 69.74% but has a 17.58% false positive rate. CloudFlare Free detects only 10.70% with 0.07% false positives. The accuracy column puts SafeLine Balance at 99.45% and Strict at 99.38%. These numbers come from the project's own evaluation, not an independent benchmark. The false positive rate is the most telling metric: SafeLine Balance matches CloudFlare's low false positive rate while detecting far more attacks. But you cannot verify these numbers from the README alone, and the sample set may not reflect your traffic.

Rate Limiting, Bot Challenges, and the Trade-offs

Rate limiting and anti-bot challenges are two features that go beyond traditional WAF signatures. Rate limiting protects against brute force and traffic surges, but it requires careful threshold tuning. Set limits too low and you block legitimate users during a spike. The anti-bot challenge is a similar trade-off: it blocks crawlers and bots, but it also adds friction for real visitors. The authentication challenge is even more aggressive, requiring a password for every visitor. These are useful for high-risk endpoints, but they are not set-and-forget. The README presents them as features, not as knobs that need adjustment. In practice, you will need to test each one against your actual user base. The dynamic protection feature, which encrypts HTML and JS per visit, can break client-side scripts that rely on static content, so you should test it on a staging site first.

Limitations and Cases Where SafeLine Is the Wrong Tool

The most obvious limitation is the cloud dependency. The warning for mainland China users says the international version may fail to connect to cloud services. That implies SafeLine is not fully offline. If your deployment requires air-gapped operation or strict network isolation, this is a dealbreaker. Another limitation is the reverse proxy model itself: SafeLine must terminate or forward HTTPS traffic, which means you need to configure SSL certificates and ensure the proxy can handle your connection volume. The README does not provide performance numbers, so you cannot estimate how many requests per second it can handle. For a high-traffic site, a dedicated commercial WAF or a cloud-based service might be more appropriate. The GPL-3.0 license also has implications: if you modify and distribute SafeLine, you must release your changes under the same license. That is fine for internal use, but it restricts proprietary redistribution.

Alternatives: ModSecurity and CloudFlare

The README itself names two alternatives: ModSecurity and CloudFlare Free. ModSecurity is an open-source WAF that typically runs as a module inside a web server like Apache or Nginx. It uses rule sets, such as the OWASP Core Rule Set, and gives you granular control over rules. The README's table shows ModSecurity with a high false positive rate (17.58%) at Level 1, which suggests you will spend time tuning rules to avoid blocking legitimate traffic. CloudFlare Free is a cloud-based WAF that requires no self-hosting, but the table shows a low detection rate (10.70%) on the same sample set. The difference in approach is clear: ModSecurity is a rule engine you configure, CloudFlare is a managed service you configure through a dashboard, and SafeLine is a self-hosted appliance with a web UI and preset modes. If you want full control over rules, ModSecurity is the choice. If you want zero maintenance, CloudFlare is the choice. SafeLine sits in between, offering self-hosting with a simpler interface.

Maintenance, Upgrades, and License Considerations

The repository shows regular releases, with v9.4.0 pushed on 2026-08-17 and previous versions in July 2026. That suggests an active release cycle, but the README does not document an upgrade process. You will need to check the docs for upgrade instructions. The GPL-3.0 license is a real consideration: it is a copyleft license, so any distributed modifications must be open-sourced under the same terms. If you embed SafeLine in a commercial product, you must comply with GPL-3.0 or choose a different WAF. The maintenance cost includes keeping up with releases, testing new versions against your applications, and monitoring the cloud service connectivity. The README mentions an MCP server for AI-assisted management, which could reduce manual work, but it is an additional component to maintain. The integrations with Ingress-NGINX and Kong Gateway suggest SafeLine can fit into Kubernetes environments, but those are separate SDKs with their own documentation.

Editorial conclusion

Adopt SafeLine if you run a small to mid-sized web app, want a self-hosted WAF with a web UI, and can tolerate a cloud connection for updates and possibly management. Skip it if you need a fully offline WAF, if your traffic exceeds the documented rate limits, or if you cannot verify the cloud dependency in your region. Before deploying, check the install guide for the exact Docker command, test the live demo at demo.waf.chaitin.com:9443, and confirm that your network allows access to the SafeLine cloud services. The balance preset shows a 99.45% accuracy in the README table, but that number comes from the project's own evaluation, so run your own traffic samples against your real endpoints.

Official sources

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Community notes

Community notes