Coder Legion - Recent posts tagged uninstall

How to Uninstall a Self-Hosted WAF and Remove Its Data Directory Without Leaving Residue

Sun, 01 Nov 2026 03:36:10 +0000

SafeLine is described in its official documentation as a self-hosted WAF that protects web applications by filtering and monitoring HTTP traffic between the app and the Internet (https://docs.waf.chaitin.com/en/home). When you deploy it manually, the guide has you create a dedicated directory such as /data/safeline and tells you that SafeLine will write its configuration and data to that directory (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That has a direct consequence for uninstall: removing this WAF is not just about stopping containers. It is a two-phase job that stops and removes the Docker Compose project, then deletes the data directory. Skipping either phase, or running the commands from the wrong place, leaves a half-removed installation behind.

The misconfiguration: running `docker compose down` from the wrong directory

Docker Compose resolves its project from the compose.yaml file in the current working directory. In the manual deployment flow, the guide downloads that file after changing into the SafeLine directory (cd "/data/safeline") (https://docs.waf.chaitin.com/en/GetStarted/Deploy). A common mistake during cleanup is to log in and run docker compose down from /root, $HOME, or some other folder. Because there is no compose file there, Compose cannot find the project and aborts before touching anything. The screen that confirms the mistake looks like this:

$ docker compose down
no configuration file provided: not found

At that point the SafeLine containers are still running and the data directory is still on disk. Deleting files at this stage is also unsafe because the service has not been stopped first. The official uninstall steps are explicit about the sequence: enter the SafeLine directory with cd <safeline-directory>, run docker compose down, then remove the data with rm -rf <safeline-directory> (https://docs.waf.chaitin.com/en/GetStarted/Deploy).

The fix that stays fixed

Step one is to be in the directory that contains the original compose.yaml file. Run the stop command from there so Compose stops and removes the containers. A successful run prints per-service removal lines rather than the no configuration file provided error:

$ cd /data/safeline
$ docker compose down
[+] Running
<service> Removed
<network> Removed

Step two is to remove the data directory, which is what actually erases the configuration and stored data. The screen that confirms this phase is a missing-path error from ls after the removal completes:

$ rm -rf /data/safeline
$ ls -la /data/safeline
ls: cannot access '/data/safeline': No such file or directory

Together, the per-service removal output from docker compose down and the No such file or directory result from ls are the two confirmation points that the uninstall completed. If either one is missing, something was skipped.

FAQ

Why does the working directory matter for uninstall?

Compose loads compose.yaml relative to the directory you are currently in. The manual deployment guide places that file inside the SafeLine directory, and its uninstall section starts with cd <safeline-directory> for this reason (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Running docker compose down from another folder produces no configuration file provided: not found, or could target the wrong project if another compose file happens to be present, so the containers keep running and the data remains.

Is `rm -rf <safeline-directory>` optional after `docker compose down`?

No. docker compose down stops and removes the containers and network, but it does not delete the directory on the host. The deployment guide states that SafeLine writes its configuration and data to this directory, and the uninstall section includes rm -rf <safeline-directory> as a separate final step (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That directory also holds the .env file containing secrets such as the database password and internal tokens, so leaving it behind means leaving configuration and credentials on disk.

How do I confirm that nothing is left after uninstall?

Run two checks. First, docker ps -a should show no SafeLine containers still present. Second, ls -la <safeline-directory> should report No such file or directory. The removal output from docker compose down plus that missing-path result together confirm both phases finished.

What happens if I delete the data directory while the containers are still running?

That reverses the documented order. The official guide runs docker compose down before rm -rf <safeline-directory> (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Deleting the directory first can leave running processes writing to paths that no longer exist and can produce partial or inconsistent state. Always stop the Compose project first, then remove the 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.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Why I Use an Exit Checklist Before Turning Protection On

Sun, 01 Nov 2026 03:35:39 +0000

I do not turn a self-hosted WAF on until I can name the directory it will own and the exact commands that retire it. Protection is a traffic decision. Uninstall is a data decision. The deploy guide already joins those two ideas: SafeLine writes configuration and data into a directory you create, and a complete uninstall is docker compose down followed by removal of that same directory. I treat that page as a checklist, not as a rescue document.

SafeLine, as described on the product home page, is a self-hosted web application firewall placed in front of an application. It is a reverse proxy: clients pass through it before they reach the origin, and it filters, monitors, and blocks malicious HTTP and HTTPS traffic according to policy. The same page lists defenses for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoors, brute force, HTTP flood, and bot abuse. It also lists proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Rate limiting is aimed at DoS, brute-force attempts, traffic surges, and similar abuse. Captcha challenge, authentication challenge, and dynamic protection are described as controls that change what a visitor must do, or how HTML and JS are delivered, once they are turned on. None of that is a reason to skip the exit plan. It is the reason the exit plan has to exist before the first DNS change. Source: https://docs.waf.chaitin.com/en/home

Fit the host before you create state

The deploy guide sets a minimum: Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, 1 CPU core, 1 GB of memory, 5 GB of disk, and a CPU that supports ssse3. I run the documented checks for architecture, Docker version, Compose version, processors, memory, disk, and ssse3 before I create a directory. An ARM server has an extra gate: the same guide says SafeLine on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. If that license does not apply, I stop. I also choose a release line on purpose. The guide says the LTS version will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it strongly recommends that LTS users move to the latest version. Source: https://docs.waf.chaitin.com/en/GetStarted/Deploy

Write down the data directory first

Manual setup creates a directory such as /data/safeline and states that SafeLine will write configuration and data there. Five gigabytes is the documented floor, not a suggestion to fill the disk and sort it out later. The .env file in that directory holds SAFELINE_DIR, the image tag, MGT_PORT, the Postgres password, the subnet prefix, and generated secrets such as DETECTOR_MGMT_TOKEN, MGT_INTERNAL_TOKEN, and DETECTOR_AES_KEY. Install steps also create resources/run, resources/mgt, resources/sock, and resources/postgres/data, then symlink resources/run/safeline.sock to /var/run/safeline.sock.

That is the directory an uninstall will delete. If I do not use /data/safeline, the placeholder in the uninstall section is <safeline-directory>, so my checklist names the real absolute path. I do not keep unrelated backups, certificates I still need, or notes inside that tree. The removal command is rm -rf on the SafeLine directory. A misplaced parent path is not a small mistake.

Rehearse the documented uninstall

When I am sure I no longer want the instance, the deploy guide says to enter the SafeLine directory, run docker compose down, and then run rm -rf on that directory. I keep that order. docker compose down stops the Compose project. The removal command deletes the configuration and data the install guide told the product to store there, including the Postgres data path under that tree. I do not add image deletes, volume prunes, or extra file wipes and then call the longer list official. The published complete uninstall is those two actions.

The install guide does create /var/run/safeline.sock as a symlink. The uninstall section does not list a separate command for it. I note the symlink so I am not surprised, and I do not invent a cleanup step that the guide does not give. The administrator reset command, docker exec safeline-mgt resetadmin, belongs to a running management container. It is not a recovery tool after the directory is gone. The console itself is documented at https://<safeline-ip>:9443/ when MGT_PORT stays at 9443. If I changed that port in .env, the checklist uses the port I set, because the file is about to disappear with the directory.

Before any production name points at the host, I rehearse this on a spare machine: install, confirm the console, stop the project, remove only the SafeLine directory, and confirm the path is gone. That rehearsal is how I learn whether I recorded the path correctly.

Turn protection on only after the exit is clear

The application guide describes SafeLine as an HTTP and HTTPS reverse proxy developed based on nginx. In the Web Admin Console I add an application with a domain, a listen port, and an upstream. HTTPS means checking the SSL option. I then resolve that domain to the SafeLine server. Until DNS moves, visitors are not yet depending on this proxy, which is the right moment to finish the checklist. Source: https://docs.waf.chaitin.com/en/GetStarted/AddApplication

I separate the process is up from this site is protected. Rate limiting, captcha, an authentication password gate, and dynamic HTML or JS encryption are documented behaviors with visitor impact. I enable them only when I know which site they affect and how I will take that site off the proxy if the control is wrong. Full uninstall is the wrong rollback for one bad upstream when other applications share the same data directory. For one site, I stop sending that name to SafeLine. I use docker compose down and rm -rf only when I mean to retire the instance and accept the loss of its configuration and data.

After protection is actually on, the application guide sample requests for SQL injection, XSS, path traversal, code injection, and XXE are a narrow check, using my own domain. A blocking page, and an attack entry whose detail I can open in the console, tells me the proxy defended that request. It does not prove that every optional control is tuned.

The home page says SafeLine is production-ready. I read that as permission to plan a real cutover, not as permission to skip the directory and uninstall steps above.

How do I uninstall a self-hosted WAF and remove its data directory?

For SafeLine, follow the deploy guide. Change to the directory you created for it, run docker compose down, then remove that directory with rm -rf and the same path. The example install path is /data/safeline, but the uninstall instructions use whatever SafeLine directory you actually created. See https://docs.waf.chaitin.com/en/GetStarted/Deploy

Does directory removal delete rules and database files?

Yes. The install guide says the directory holds configuration and data, and the setup creates a Postgres data directory inside it. rm -rf on that directory removes those files. Copy anything you still need to a path outside that directory before you remove it. There is no documented archive step inside the uninstall section.

Can I remove the data directory while containers are still up?

The documented sequence does not do that. It stops the project with docker compose down first, and only then removes the directory. I treat that order as required because it is the order the uninstall section gives.

What belongs on the checklist before protection is turned on?

Confirm the host against the deploy guide, including the ARM license limit and the 5 GB disk floor. Record the absolute data directory and the console port. Keep secrets and anything you must retain outside the directory you may later delete. Add one application with domain, port, and upstream, and change DNS only after that record is complete. Decide separately whether rate limiting, captcha, authentication challenge, or dynamic protection should be on for that site.

When is full uninstall the wrong rollback?

It is the wrong rollback when you only need to take one site off the proxy. Uninstall stops the Compose project and deletes the shared configuration and data directory. Use it when you are sure you no longer want the instance, which is the condition the deploy guide states.