DEV Community

Lia
Lia

Posted on

How to Protect Self-Hosted Homelab Services with a Reverse-Proxy WAF

#homelab #waf #selfhosted #checklist

A homelab becomes harder to reason about the moment one web app is reachable from outside the house. A dashboard, a file portal, or an admin panel can sit on the public internet while the rest of the lab stays private. A web application firewall is a possible layer for that published app. It is not a substitute for updates, strong accounts, or keeping unused services off the internet.

SafeLine is documented as a self-hosted WAF that protects web apps by filtering and monitoring HTTP traffic between the application and the internet. Deployed in front of an app, it acts as a reverse proxy: clients pass through the WAF before they reach the server, and policies decide which traffic is forwarded and which traffic is blocked. That placement is the useful homelab question. Which services should terminate on the firewall, and which services should never be published at all?

Start with exposure, not with settings

Do not add a WAF entry for a service that only you use on the local network. A private bind address, a VPN, or another access gate may be the better control. Consider a WAF when three things are already true: the service is a web app, you intend to accept outside connections, and you can force those connections through a host you control.

The configuration guide describes SafeLine as an HTTP and HTTPS reverse proxy based on nginx. It receives traffic for the original site, cleans traffic it treats as malicious, and forwards the remaining traffic to the upstream application. Nothing in the install or application guides documents a connector for a particular homelab platform, a database listener, or raw TCP and UDP services. If you cannot proxy the service as a web app, do not assume an integration exists.

Use this checklist before you publish anything:

  • The origin speaks HTTP or HTTPS, and SafeLine can reach its real address as an upstream.
  • You can enter a domain, hostname, or IP address, plus the port SafeLine will listen on, such as 80 or 443.
  • HTTPS apps have the SSL option checked on that application entry.
  • DNS for the published name will point at the SafeLine server, not directly at the origin.
  • The origin is no longer reachable from the internet on its old port, so clients cannot bypass the proxy.
  • You can open the web console attack list and the detail view if a legitimate client is blocked.

Fail any item and stop. A shield that traffic can walk around does not change your risk.

What the documented filter covers

The product overview lists core capabilities as defenses for web attacks, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. Named attack types include 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. Source: https://docs.waf.chaitin.com/en/home

The same page describes rate limiting as a way to throttle traffic that exceeds defined limits, aimed at denial-of-service attacks, brute-force attempts, traffic surges, and other abuse. A CAPTCHA challenge is described as allowing human visitors while blocking crawlers and bots. An authentication challenge, when turned on, requires visitors to enter a password or be blocked. Dynamic protection, when turned on, dynamically encrypts HTML and JavaScript from the web server on each visit.

Those controls fit a small public admin UI. They do not patch the application, and they do not make a reused password safe. Treat them as a filter in front of an origin you still maintain.

The overview also publishes an effect evaluation on 33669 samples. It lists ModSecurity Level 1 at 69.74 percent detection, 17.58 percent false positives, and 82.20 percent accuracy; CloudFlare Free at 10.70 percent detection, 0.07 percent false positives, and 98.40 percent accuracy; 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. Read that table as the documentation's published metric, not as a promise for your own mix of browsers, scripts, and unusual query strings. Source: https://docs.waf.chaitin.com/en/home

Match the host to the documented floor

The deploy guide sets a minimum of Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and an environment of 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support ssse3. Those figures are a floor. They are not a sizing claim for a busy media stack sharing the same machine.

Confirm the box with the commands listed in that guide: uname -m, docker version, docker compose version, processor and memory checks, df -h, and an ssse3 check. Automatic install is documented as a root command that runs the published manager script. Manual install creates a data directory such as /data/safeline, downloads the compose file, writes an env file, generates detector and management tokens plus an AES key, restricts permissions, and starts the stack with docker compose up -d. The console then opens at https://:9443/ unless MGT_PORT is changed. The initial administrator account comes from docker exec safeline-mgt resetadmin. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

One homelab detail is easy to miss. The deploy guide states that SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. An arm64 board is a license decision, not only an architecture checkbox. An x86_64 host avoids that specific constraint as documented.

Keep the data directory on storage you can back up. The documented uninstall path is docker compose down in that directory, followed by removing the directory. Know that path before the host becomes important.

Add one application, then test the block

Log in to the web admin console, open Applications, and click Add Application. Enter the domain, hostname, or IP; the listen port; and the upstream address of the real app. Check SSL for HTTPS. After that, resolve the name you entered to the IP of the SafeLine server. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Verify with the sample cases on that page, using your own domain in place of the example host. The guide shows query patterns for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was defended. Then open the console attack list and click detail. Publish one app, confirm a block, and confirm a normal page still loads. Do not move the rest of the lab on the same afternoon.

Keep the console separate from published apps. The management port and the application listen ports do different jobs. Do not expose the console more widely than the services it protects, and do not reuse an application password as the console password. The authentication challenge is a visitor gate. It is not the administrator login.

Review blocks when an app changes. A new upload form, a reverse-proxy header, or a login flow can look hostile. Set rate limits tight enough to slow brute force and loose enough for your own clients. Enable CAPTCHA or the authentication challenge only when the app is sensitive and you can accept the extra step. If you enable dynamic protection, retest interactive pages, because HTML and JavaScript are encrypted on each visit.

A reverse-proxy WAF belongs in a homelab when you have chosen to publish a web app and you can force that traffic through a filter you operate. It does not belong in front of services you should not publish, and it does not replace patching the origin.

Does a homelab WAF replace a VPN?

No. Use a VPN or a private bind when the service should not be on the internet. Use a WAF when you have already decided to publish an HTTP or HTTPS app and you want requests filtered before they reach the origin. The controls answer different questions.

Can this protect every self-hosted service?

The documented model is an HTTP and HTTPS reverse proxy in front of a web application, configured with a domain, port, optional SSL, and an upstream. These sources do not describe a universal plugin for databases, raw TCP services, or a catalog of homelab apps. If you cannot proxy it that way, do not assume coverage.

What should I check on a small or ARM host?

Confirm Linux, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, ssse3, and at least 1 core, 1 GB of memory, and 5 GB of disk. On ARM, the deploy guide says a Pro license is required for proper operation and that the Personal Edition is not supported.

How do I know a test request was blocked?

The configuration guide says a blocking page means the defense worked for its sample cases. Open the web console attack list and click detail to inspect the event. Test only those documented patterns against your own domain.

Where should DNS point?

Resolve the application name to the IP address of the server running SafeLine. Clients should reach the WAF first. If DNS still points at the origin, the reverse proxy never sees the request.

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)