A homelab rarely fails in one dramatic way. It fails when a useful web app is reachable, a password form is guessable, and nobody has decided which requests are allowed to touch the origin. A WAF can help, but only if you treat it as a reverse proxy with a defined job, not as a label you place on every container.
SafeLine is documented as a self-hosted WAF that protects web apps by filtering and monitoring HTTP traffic between a web application and the Internet. Deployed in front of an app, it is a reverse proxy: clients reach the WAF first, and the WAF forwards traffic it considers safe to the origin while blocking malicious HTTP and HTTPS requests and unauthorized data leaving the app. That model is the whole decision. If a self-hosted service is not an HTTP or HTTPS application you can place behind that proxy, this checklist should stop you from promising protection the product docs do not describe. Source: https://docs.waf.chaitin.com/en/home
Sort services before you sort controls
Write down every service you want to protect and mark only those that speak HTTP or HTTPS. A photo library, a notes site, a dashboard, or a small API can belong on the list when you can name a domain, hostname, or IP, a listen port, and an upstream address. A database port, a raw game server, or a protocol that never becomes an HTTP request does not become a WAF application just because it runs on the same host.
The official application flow is concrete. In the Web Admin Console, open Applications and choose Add Application. Enter the original app domain, hostname, or IP. Enter the port SafeLine will listen on, such as 80 or 443, and check the SSL option for HTTPS apps. Enter the upstream, which is the real address used to forward traffic. After that, resolve the name you entered to the IP of the server where SafeLine runs, then reach the protected app through that name. If you cannot complete those four facts, the service is not ready for this path. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication
Keep the origin from being a shortcut. The value of the proxy is that clients pass through it before they reach the server. If the same app is still published on a second port, a second hostname, or a direct LAN address that bypasses the WAF, the checklist is unfinished even if the console shows a healthy application.
Match documented threats to homelab exposure
The product documentation names a wide set of web attacks, including 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. Core capabilities listed alongside that coverage are web-attack defense, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Source: https://docs.waf.chaitin.com/en/home
For a homelab, translate those names into exposure, not into a feature tour. A form or query string that reaches a database-backed app is a reason to care about injection and path traversal. A login page on a name that resolves from outside the house is a reason to care about brute force. A site that suddenly attracts scripted clients is a reason to care about bots and floods. An app you only use over a trusted VPN may still deserve the proxy if the origin would be dangerous when that VPN rule is wrong, but the checklist should say so explicitly.
Do not invent a connector for a particular self-hosted brand. The supplied docs describe a generic reverse-proxy application. They do not document a special integration for any homelab suite. If an app needs a custom header, a long-lived connection, or an existing proxy in front of it, test that behavior yourself and treat anything beyond domain, port, upstream, and DNS as unverified.
Pick controls by failure mode
Blocking web attacks is the baseline. The feature list says SafeLine defends against web attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal. Rate limiting is separate. The docs describe it as a way to throttle traffic that exceeds defined limits, aimed at DoS attacks, brute-force attempts, traffic surges, and other abuse. A CAPTCHA challenge is for bot attacks: human users are allowed through, while crawlers and bots are blocked. An authentication challenge is a password gate: when it is on, visitors must enter the password or they are blocked. Dynamic protection is different again: when it is on, HTML and JS from the web server are dynamically encrypted on each visit. Source: https://docs.waf.chaitin.com/en/home
A practical homelab mapping looks like this. Use attack blocking for any app whose parameters, uploads, or paths are reachable. Add rate limiting where login, search, or API routes can be hammered. Consider CAPTCHA where anonymous bots, not forgotten passwords, are the problem. Use the authentication challenge only when a shared password gate is acceptable for every visitor of that application, because it will block people who do not have that password. Turn on dynamic protection when you specifically want HTML and JS encrypted per visit, and verify that your own pages still work. None of these toggles replaces patching the origin app.
Published evaluation numbers are a tuning warning, not a score you should paste onto your hardware. On 33669 samples, the docs report SafeLine Balance at 71.65 percent detection, 0.07 percent false positives, and 99.45 percent accuracy, and SafeLine Strict at 76.17 percent detection, 0.22 percent false positives, and 99.38 percent accuracy. Strict raises detection and also raises the false-positive rate compared with Balance. For a homelab, that means you should watch the attack list after you change policy, especially if household tools start failing on ordinary requests. Source: https://docs.waf.chaitin.com/en/home
Confirm the host can carry the proxy
The deploy guide states minimums: Linux; x86_64 or arm64; Docker 20.10.14 or above; Docker Compose 2.0.0 or above; 1 CPU core, 1 GB memory, and 5 GB disk; and a CPU with SSSE3. Documented checks include uname -m, docker version, docker compose version, processor count, free -h, df -h, and lscpu | grep ssse3. A small lab box can meet the minimum and still feel tight once logs, database data, and several proxied apps share that 1 GB. Plan disk beyond the 5 GB floor if you expect to keep attack history.
ARM needs an extra decision. The deploy guide says SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. An arm64 homelab board is therefore not the same choice as an x86_64 mini PC. If you are looking at the LTS channel, note that LTS is no longer maintained starting from 9.1.0-LTS (14 August 2025), and the docs strongly recommend upgrading to the latest version. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy
The console itself is part of the exposure review. After install, the web console is https://<safeline-ip>:9443/. The initial admin account is retrieved with docker exec safeline-mgt resetadmin. Treat that management port as a privileged surface: it is how you add applications and read attack detail, so it should not be casually published beside the apps you are trying to protect.
Prove the path with the documented tests
After DNS points at the SafeLine host, use the official test cases with your own domain in place of the example host. The docs give SQL injection as /?id=1+and+1=2+union+select+1, XSS as /?id=<img+src=x+onerror=alert()>, path traversal as /?id=../../../../etc/passwd, code injection as /?id=phpinfo();system('id'), and an XXE-style query. A blocking page means the attack was defended. Then open the console attack list and click detail so you can see what was recorded, not only what the browser showed. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication
Repeat one normal visit after each test. A homelab WAF that blocks the sample attacks and also blocks your own bookmark is not finished. The docs state that SafeLine is production-ready, but that statement does not mean every policy is correct for your apps. Your proof is the proxy path, the block page, the attack detail, and a clean legitimate request.
Does a homelab WAF cover every self-hosted service?
No. The documented role is an HTTP and HTTPS reverse proxy in front of a web application. Services that you cannot describe with a domain, hostname, or IP, a listen port, and an upstream should stay outside this design until you have a real web path for them.
Which homelab host facts are actually required?
The deploy guide requires Linux on x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, at least 1 core, 1 GB of memory, 5 GB of disk, and SSSE3. ARM installs need a Pro license; the Personal Edition is not supported on ARM.
Should I enable every challenge on day one?
Not by default. Rate limiting targets excess traffic, brute force, surges, and abuse. CAPTCHA targets bots. The authentication challenge blocks visitors who do not enter its password. Dynamic protection encrypts HTML and JS on each visit. Enable the control that matches the failure you are seeing, then retest a normal session.
How do I know the WAF, not another hop, blocked the request?
Use the documented attack URLs against the name that resolves to the SafeLine server. A blocking page is the first sign. The console attack list and its detail view are the second. If the origin is still reachable on another address, fix that bypass before you trust the result.
What should I leave off this checklist?
Leave off claims the sources do not make: special integrations for named homelab apps, extra protocols, pricing, and any promise that a minimum lab host will behave like a large deployment. Also leave the management console unpublished to the same audience as the apps, and prefer a maintained release over the unmaintained LTS line if you are choosing a version now.
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.