DEV Community

禾
禾

Posted on

How to Decide If a Homelab WAF Fits Your Self-Hosted Apps

#homelab #waf #selfhosted #checklist

A self-hosted service is only as private as the path that reaches it. In a homelab, that path is often a port forward, a tunnel, or a reverse proxy that terminates TLS and forwards whatever HTTP request arrives. That hop can hide an internal address, but it does not decide whether a query string is an injection, whether a login flood is abuse, or whether a client is trying to walk the filesystem. A WAF for a homelab is the control that inspects HTTP traffic before the application sees it. This checklist is about whether that control belongs in front of the services you actually publish.

SafeLine is documented as a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet. It blocks malicious HTTP/S requests and is also described as preventing unauthorized data from leaving the app (https://docs.waf.chaitin.com/en/home). The same page describes the placement: clients pass through the WAF before they reach the server, because a WAF of this type is a reverse proxy rather than a client-privacy proxy. That is the decision, not a promise that SafeLine plugs into every homelab ingress product. The application guide says SafeLine receives traffic for the original site, cleans malicious requests, and forwards the remaining traffic to the upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If your current proxy is not described in these sources, treat SafeLine as the documented front door instead of assuming a side integration.

Start with exposure, not with an install

Before you add another service to a small host, write down which apps are already on a reachable network.

Is the service HTTP or HTTPS? SafeLine is a web application firewall built on nginx to proxy HTTP and HTTPS, clean attack traffic, and forward what remains (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). It is not documented as a filter for SSH, databases, or arbitrary TCP. Do not put non-web protocols on this list and expect coverage.

Who can already reach it? A photo archive, an admin panel, or a personal Git web UI that answers on a public name has a different risk from a service bound only to a private LAN. The documented model assumes clients pass through SafeLine before the server (https://docs.waf.chaitin.com/en/home). If nothing routes clients there, the policies never see the request.

What would a bad request do? The introduction lists 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 among the attack classes a WAF of this kind is meant to address (https://docs.waf.chaitin.com/en/home). Map the app to that list. A static file server can still face path traversal and floods. A login form can face brute force. An app that parses XML or fetches remote URLs can face XXE or SSRF. If none of those request classes can reach the app, a WAF may be the wrong layer.

Can you change DNS or the published address? After you add an application, the guide says to resolve the entered domain to the IP of the SafeLine server, then reach the protected app through that name (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A homelab name you cannot point at the WAF host will not follow the documented path.

Match the host to the documented minimum

The deploy guide requires Linux on x86_64 or arm64, Docker 20.10.14 or above, and Docker Compose 2.0.0 or above. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk, and the CPU needs the ssse3 instruction (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That is modest for a dedicated VM. It is not spare capacity on a board that is already swapping.

Check the host first. The same page lists commands for architecture, Docker version, Compose version, CPU, memory, disk, and ssse3. On ARM, the guide states that SafeLine requires a Pro license to work properly and that the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An arm64 homelab should stop at that sentence and confirm licensing before planning the rollout. Do not treat the x86_64 path and the ARM path as the same choice.

Installation can follow the documented automatic command, or a manual Compose layout under a directory such as /data/safeline, with at least 5 GB free, a locked-down environment file, and docker compose up -d. The console is served on the management port, 9443 by default, at https://:9443/ (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Keep that console off the public name you use for household services. It is an admin surface.

The guide also says the LTS line will no longer be maintained starting from 9.1.0-LTS, dated 14 August 2025, and it recommends moving to the latest version (https://docs.waf.chaitin.com/en/GetStarted/Deploy). For a host that may sit unattended, choose a maintained release and plan the upgrade instead of freezing an old tag.

Place each service as an application

The documented application record has three fields that decide the path. Domain is the name, hostname, or IP clients use. Port is the port SafeLine listens on, such as 80 or 443, with the SSL option checked for HTTPS apps. Upstream is the real address SafeLine uses to reach the original app (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Read those fields in homelab terms. Domain is the name you are willing to publish. Port is where SafeLine accepts visitors, not the port the app used when it was exposed directly. Upstream stays the private address of the app. After cutover, clients should not need that address.

Because this model makes SafeLine the reverse proxy, do not leave the old port forward aimed at the origin. Otherwise you built a shield and left the side door open. These sources do not describe a homelab bypass list, so the clean design is one published path through the WAF.

After the proxy works, the home page lists core controls you can evaluate: defenses for web attacks, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home). The feature list ties rate limiting to DoS, brute force, traffic surges, and other abuse. It describes a CAPTCHA challenge that allows human users and blocks crawlers and bots, an authentication challenge that requires a password, and dynamic protection that encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home). Enable a control because it matches a real case. An authentication challenge in front of a private dashboard is a different choice from dynamic encryption on a public page.

Prove the path, then decide

Once DNS points at SafeLine, the application guide suggests trying common patterns against your own domain: a SQL injection query, an XSS payload, a path traversal string, a code injection string, and an XXE string (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A blocking page means the request was stopped. The console attack list, including the detail view, is how you confirm the event was recorded rather than dropped by an unrelated network rule.

Use those checks only on a hostname you control. They are verification steps from the product docs, not a method for probing anyone else's site. Also load a normal page and complete a real login so the upstream, the TLS option, and any challenge still allow the people you intended to admit.

The home documentation includes an effect evaluation on 33,669 samples. In that table, SafeLine Balance is listed at 71.65 percent detection, 0.07 percent false positives, and 99.45 percent accuracy. SafeLine Strict is listed at 76.17 percent detection, 0.22 percent false positives, and 99.38 percent accuracy (https://docs.waf.chaitin.com/en/home). Treat those figures as a published comparison of detection modes, not as a guarantee for your apps. Strict is shown detecting more while also listing a higher false-positive rate. On a household service, start with a mode you can watch, then review blocked events before you tighten policy.

The same page calls SafeLine production-ready and points operators to Discord for community support and to GitHub issues for new issues (https://docs.waf.chaitin.com/en/home). That does not remove the homelab work of keeping Docker current, protecting the secrets written during a manual install, and knowing how to leave. Uninstall is documented as docker compose down in the SafeLine directory, followed by removing that directory if you are sure the data should go (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

Add the WAF when the service is a web app, clients can be directed to SafeLine, the host meets the CPU, memory, disk, Docker, and architecture rules, ARM licensing is settled if you are on arm64, and you can review the attack list after cutover. Wait when the service is not HTTP, when you cannot move the published name, when the board cannot spare the documented minimum, or when the origin port would stay open to the Internet. To protect self-hosted services, a reverse-proxy WAF only covers the path you actually send through it.

Does a homelab WAF replace a VPN?

No. The documented role is filtering HTTP and HTTPS in front of a web application (https://docs.waf.chaitin.com/en/home). A private network still fits admin tools you do not need on the public Internet. Use the WAF for web apps you choose to publish, and keep non-web services off that public name.

Can I keep another ingress and only add SafeLine beside it?

These guides do not document a plugin for other homelab proxies. They describe SafeLine as the reverse proxy that receives traffic, removes malicious requests, and forwards the rest upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Plan the published name, listening port, and upstream around that model. The management proxy setting is for console proxy layers, not a general recipe for chaining every app (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

What should I enable first on a small self-hosted app?

Confirm the application proxy and a normal visit first. Then rely on attack defense and, if the app has a login or is easy to flood, IP-based rate limiting, which the docs tie to DoS, brute force, surges, and abuse (https://docs.waf.chaitin.com/en/home). Add a CAPTCHA challenge or an authentication challenge when bots or anonymous visitors are the problem you can name. Dynamic HTML and JS encryption is a separate switch for pages where that behavior is acceptable.

How do I know SafeLine blocked the request?

The application guide says a blocking page means the attack was defended, and the web console attack list shows details when you open an event (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A block on the WAF name does nothing for a second port that still forwards straight to the origin. Close that direct exposure after the proxied name works.

Is the minimum spec enough for every homelab host?

It is the documented floor: 1 core, 1 GB of memory, 5 GB of disk, ssse3, a current enough Docker Engine and Compose, and Linux on x86_64 or arm64 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). ARM additionally needs a Pro license for proper operation, and the Personal Edition is not supported there. Leave room for the apps themselves, and do not install onto a volume that cannot hold the data directory.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)