A WAF install is the wrong moment to discover that the host cannot run the stack. I treat Docker Compose and SSSE3 as two separate gates, and I do not start either install path until both have been confirmed on the machine that will sit in front of the application.
SafeLine is a self-hosted web application firewall. It filters and monitors HTTP traffic between a web application and the Internet, and it is deployed as a reverse proxy so clients reach the WAF before they reach the origin (SafeLine introduction). The application guide describes the same design more specifically: SafeLine is an nginx-based HTTP and HTTPS reverse proxy that receives traffic for the original site, cleans malicious requests, and forwards the remaining traffic upstream (application protection guide). None of that protection exists until the host meets the published dependencies.
Two requirements, not one readiness command
The deploy guide does not offer a single probe that means "this server can run the WAF." It lists Linux, instruction architectures x86_64 and arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, at least 1 CPU core, 1 GB of memory, and 5 GB of disk, and it lists CPU SSSE3 as its own dependency (SafeLine deploy guide). A passing Docker version does not imply a passing Compose version. A visible SSSE3 flag does not imply that docker compose is new enough to launch the stack.
I run the confirmation commands from that guide on the target server, not on a laptop that will only open the console:
uname -m for instruction architecture.
docker version for the Docker engine.
docker compose version for Docker Compose.
cat /proc/cpuinfo | grep "processor" for CPU info.
free -h for memory.
df -h for disk.
lscpu | grep ssse3 for the SSSE3 instruction flag.
The Compose command I care about is the spaced form, docker compose version. Later in the same guide, the manual launch is docker compose up -d, and removal uses docker compose down. If the version command fails, the Compose dependency is not confirmed, even when docker version succeeds. A downloaded compose.yaml does not change that result. On the manual path, that file is fetched with wget into /data/safeline after Docker is available. The file is the stack definition. It is not the Compose client, and it does not print a version I can compare with 2.0.0.
How I read each result
Architecture is a match only when uname -m prints x86_64 or arm64. Those are the two values named in the dependency table. A nearby label is not a documented substitute.
For Docker, the floor is 20.10.14 or above. I read both the client version and the server version. The guide does not say a newer client can stand in for an older engine, so I require both reported versions to meet that floor.
For Compose, the floor is 2.0.0 or above. I compare the version printed by docker compose version with that floor. I do not infer it from the engine version, from the presence of compose.yaml, or from a container runtime that can start single containers.
For SSSE3, the documented check is lscpu | grep ssse3. A line containing ssse3 means the flag is present in that output. Empty output means the check did not confirm the flag. The guide does not publish a substitute command, a waiver, or an installer error string for that case, so I do not invent an equivalent CPU feature and continue.
Capacity is part of the same pass. The processor listing is how I compare the host with the 1-core minimum. free -h is the check against 1 GB of memory. df -h is the check against 5 GB of disk. On the manual path I create /data/safeline only after that disk budget is real, because the guide says SafeLine writes configuration and data there and that the directory needs at least 5 GB.
What a pass allows, and what it does not
A full pass is permission to choose an install path. It is not evidence that a site is protected.
The recommended automatic path is a root-privileged run of the published manager script with --en. The manual path installs Docker if needed, creates /data/safeline, downloads compose.yaml, writes .env, generates the documented secrets, tightens permissions, and then runs docker compose up -d. Neither description says the installer will first prove architecture, Compose 2.0.0, memory, disk, and SSSE3. I collect that output before either path changes the host.
Architecture still needs one decision after uname -m. For an ARM server, the guide says to set ARCH_SUFFIX=-arm and to use the documented ARM Postgres image, chaitin/safeline-postgres-arm:15.18. It also 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 result satisfies the architecture row only. It does not remove that license constraint.
After a manual launch, the console address in the guide is https://<safeline-ip>:9443/, and docker exec safeline-mgt resetadmin prints the initial administrator account. Those steps show that the stack started and that a password was issued. They are not a retroactive proof of the Compose version or of SSSE3.
I keep the raw preflight output with the change record: architecture, Docker client and server versions, Compose version, whether ssse3 appeared, processor lines, memory, and free space on the filesystem that will hold /data/safeline. If one floor is missed, I stop. A newer Compose binary does not offset an unsupported architecture, and a visible SSSE3 flag does not offset an old Compose client.
These checks also say nothing about DNS, upstream reachability, or a blocking page. Protection starts when an application is added with a domain, a listen port, and an upstream, and when that domain resolves to the SafeLine server. The sample attack URLs in the application guide are useful only after that proxy path exists.
Does an empty SSSE3 grep fail the requirement?
Yes, as a confirmation failure. The deploy guide lists CPU SSSE3 as a dependency and gives lscpu | grep ssse3 as the check. Output that contains ssse3 confirms the flag in that command. Empty output does not. No alternate flag or exception is documented there.
Does docker version also verify Docker Compose?
No. docker version answers the Docker 20.10.14 requirement. docker compose version answers the Docker Compose 2.0.0 requirement. The install guide lists them as separate software dependencies and supplies separate commands.
Can the automatic installer replace this preflight?
No. The automatic command is the recommended install path, and it requires root. It is not documented as a read-only probe of architecture, Compose, memory, disk, or SSSE3. I run the confirmation commands first.
Which architecture strings count as a match?
The dependency table names x86_64 and arm64. I confirm the live value with uname -m. On ARM, I also apply the documented ARCH_SUFFIX=-arm image setting and the stated Pro license requirement. The Personal Edition is not supported on ARM.
Do these checks mean a site is already protected?
No. They compare the host with the published install dependencies. SafeLine protects an application after installation and after that application is configured as a reverse proxy, with its domain resolved to the SafeLine server.
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/bvK1BAV
- 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
Top comments (0)