Pointing a domain name at a reverse proxy WAF IP is a DNS cutover, not a code change on the origin. Visitors should resolve the public hostname to the server that runs the firewall. That server accepts the request, filters malicious traffic, and forwards what remains to the real application. SafeLine is a self-hosted web application firewall built to sit in that position. The application guide says it acts as an HTTP and HTTPS reverse proxy: it receives traffic for the original website, cleans malicious attack traffic, and forwards safe traffic to the original application (Add Application). The product overview describes the same placement, with clients passing through the WAF before they reach the server (SafeLine docs home).

Do not publish the new DNS target until the host, the console, and the application entry are ready. A name that already points at an unprepared address will send real visitors to a proxy that cannot forward them.

Confirm the host that will own the public IP

The deploy guide sets a concrete minimum before installation. The operating system must be Linux. The instruction architecture must be x86_64 or arm64. Docker must be 20.10.14 or above, and Docker Compose must be 2.0.0 or above. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support ssse3 (Deploy guide).

Run the documented checks on the future WAF server, because that machine, not the origin, is the address you will put in DNS:

  1. Run uname -m and accept only x86_64 or arm64.
  2. Run docker version and docker compose version, then compare both with the minimum versions above.
  3. Run cat /proc/cpuinfo | grep "processor", free -h, df -h, and lscpu | grep ssse3 so CPU, memory, disk, and the ssse3 flag are visible.
  4. Write down the reachable IP of this server. That IP is the reverse proxy address. Keep the origin address separate for the upstream field.

Two constraints in the same guide should stop a bad cutover. SafeLine installed on ARM requires a Pro license to work properly, and the Personal Edition is not supported on ARM. The LTS line is no longer maintained starting from 9.1.0-LTS (14 August 2025); the guide strongly recommends upgrading to the latest version, and suggests waiting one month after a new release if you have concerns.

Install, then add the site, then change DNS

Keep the live DNS record on the origin until the proxy has an application that matches the public hostname.

  1. For a new host, the deploy guide recommends automatic installation with root privileges: bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en. When the command finishes, installation has succeeded and you can go straight to the web UI.
  2. For a manual install, create /data/safeline on a disk with at least 5 GB free, download the latest compose file from the release URL in the deploy guide, and write the documented .env values. Those include SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, SUBNET_PREFIX, IMAGE_PREFIX, and the detector tokens. Generate the secrets with the commands in that guide, restrict .env and the new data directories, then start the stack with docker compose up -d. On ARM, set ARCH_SUFFIX=-arm and the ARM Postgres image named in the guide. Use RELEASE=-lts only if you intentionally want the LTS line described above.
  3. Open https://<safeline-ip>:9443/ when MGT_PORT is still the default 9443. Run docker exec safeline-mgt resetadmin, then store the initial username and password printed by that command. Logging in only proves the console is up.
  4. In the web admin console, open Applications and click Add Application. Enter the domain, hostname, or IP clients will request, the port SafeLine will listen on, such as 80 or 443, and the upstream address of the original app. For an HTTPS app, check the SSL option. Upstream is where cleaned traffic is forwarded. It is not the address you publish in DNS (Add Application).

Resolve the public name to the proxy

  1. At the DNS provider that serves the hostname you typed into Domain, change the record so that name resolves to the IP of the server where SafeLine is located. That is the official cutover step. After it propagates, access the protected application through that domain name, not through a different hostname.
  2. Match the record name to the Domain field exactly. If visitors use www.example.com, that is the name that must resolve to the WAF IP and the name that must be entered in the application dialog. The guide allows a domain name, a hostname, or an IP address in that field, so use the same identifier clients will actually request.
  3. Do not put the upstream address in the visitor-facing record. Doing so sends clients to the origin and skips the reverse proxy. Leave the origin only in Upstream, and make sure the SafeLine host can reach that address.
  4. After resolvers show the WAF IP for that name, load a normal page through the domain. Then try the documented probes against your own hostname: a SQL injection query, an XSS payload, a path traversal string, a code injection string, and an XXE-style query. A blocking page means the request was defended. Open the console attack list and click detail to review the event (Add Application).

Before you announce the change, walk a short checklist. The Domain field and the DNS name are the same. The DNS target is the SafeLine server IP. The listen port is the port clients use, with SSL checked for HTTPS. Upstream is the real application, reachable from the proxy host. The console remains on its management port, 9443 by default, which is separate from the site listener. A benign request succeeds, and a test attack is visible in the attack list.

Once traffic arrives on that path, SafeLine can apply the controls described in the product overview: defenses for web attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal, plus IP-based rate limiting against traffic that exceeds defined limits (SafeLine docs home). Those controls inspect requests that pass through the proxy. A domain that still resolves to the origin never presents that traffic to SafeLine.

Which IP should the domain name use?

Use the IP of the server where SafeLine is installed. The application guide tells you to resolve the entered domain name to that server IP. The upstream value is the original application address and should not replace the public target for the protected name.

Should DNS change before the application exists?

No. Finish Domain, Port, the SSL option when the app is HTTPS, and Upstream first. The documented order is to complete those settings, then resolve the domain to the SafeLine server. Changing DNS earlier advertises a proxy that has no matching application yet.

Do visitors use the console port?

No. The deploy guide sets MGT_PORT to 9443 for the web console. Visitor ports are the application listen ports, and the add-application guide gives 80 and 443 as examples. Keep management access and site access separate when you test.

What should I recheck if the name resolves but the site fails?

Compare the requested hostname with Domain, the client port with the configured listen port, and the origin address with Upstream. Confirm the WAF host still meets the Docker, memory, disk, and ssse3 requirements, and that docker compose up -d finished. A successful resetadmin login does not prove the site proxy is correct.

How can I tell filtering is on the new path?

After the domain resolves to the WAF IP, send a documented test attack to that hostname. Expect a blocking page, then find the same event in the console attack list and open detail. If a direct request to the origin never appears there, that request did not pass through the reverse proxy.

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.