DEV Community

禾
禾

Posted on

Shared Placement vs Separate Instances: How to Reverse Proxy Multiple Sites With a Single WAF Instance

#reverseproxy #deployment #websecurity #checklist

If you are deciding how to reverse proxy multiple sites with a single WAF instance, split the problem in two. First, how does SafeLine receive and forward one site? Second, should several sites share that placement? The docs answer the first question. They do not describe a special multi-site mode, so the second question is a placement choice, not a hidden switch.

SafeLine is a self-hosted web application firewall. Its introduction describes a reverse proxy in front of a web application: clients pass through the WAF, and the WAF filters, monitors, and blocks malicious HTTP and HTTPS traffic before that traffic reaches the origin (https://docs.waf.chaitin.com/en/home). Documented controls include defenses against SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, path traversal, and related attacks, plus IP-based rate limiting, a web access control list, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS protection. Those controls apply only to traffic that actually arrives at the instance you configured. They do not decide how you group sites.

The application guide says SafeLine is developed on nginx and acts as an HTTP and HTTPS reverse proxy. It receives traffic for the original website, cleans malicious requests, and forwards the remaining traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). In the Web Admin Console, open the Applications page, click Add Application, and enter a domain, hostname, or IP; a listen port such as 80 or 443; and the upstream address of the real application. For an HTTPS app, check the SSL option in that dialog. Then resolve the domain you entered to the IP of the server where SafeLine is running. That is the documented path for one application. These pages do not describe bulk import, origin autodiscovery, or a multi-site load-balancing pool. Do not plan a cutover that depends on any of those.

One shared placement

Choice A uses one SafeLine installation on the public path. Each site name resolves to that server, and each site is entered with the same domain, port, upstream, and DNS steps. You are repeating a documented application entry. You are not enabling an extra product mode. The benefit is one host, one console, and one set of Docker dependencies to operate. The deploy guide requires Linux, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk, plus an ssse3-capable CPU (https://docs.waf.chaitin.com/en/GetStarted/Deploy). The console example is https://:9443/, and MGT_PORT is the setting for that console port.

Shared placement fits sites that already share an owner, a change window, and a similar threat level. It is a weak fit when one site must stay up even if the proxy is restarted. A bad upstream, a full disk, or a down proxy affects every name that points at that IP. Before DNS moves, write one row per site: public name, listen port, whether the SSL option is required, upstream host and port, and the record you will change. The port field belongs to the application you are adding. The guide does not say that two applications may both listen on 443, and it does not say they may not. If the plan needs shared ports, prove that combination on a test console first. If you cannot prove it, do not cut production DNS over.

Check the upstream too. The guide defines it as the real address SafeLine uses to forward traffic. That address must be the origin, not the SafeLine server itself. A proxy that forwards to itself is a loop, not protection.

One instance per site

Choice B places a separate SafeLine installation in front of each site. Each copy still follows the same reverse-proxy steps: add that one application, then resolve only that domain to that instance IP. Isolation is the reason to choose it. A problem with the SSL option, a console lockout, or a bad upstream stays with one name.

The cost is a copy of the documented minimum for every site. Each installation needs its own host resources, its own data directory, and its own administrator login. After the stack is up, the deploy guide shows the initial admin username and password from docker exec safeline-mgt resetadmin. Two sites therefore mean two consoles and two attack lists, not one list that automatically covers both names. Architecture is part of the same choice. The deploy guide lists x86_64 and arm64, and it states that an ARM install requires a Pro license and that the Personal Edition is not supported on ARM. Do not place a site on ARM unless that license constraint is already solved. This comparison does not cover prices.

Avoid an undocumented shortcut. The manual deploy settings include SUBNET_PREFIX and MGT_PORT, so internal addressing and the console port can be set. The guide does not present several stacks on one machine as the way to protect many sites. If isolation is why you chose Choice B, use separate servers unless you have already tested a shared-host layout on your own.

Pick a boundary, then cut over

Use a shared placement only when one team can roll back every DNS record, every site has its own verified application entry, the listen ports are tested, and a single proxy outage is an accepted risk. Use a separate instance when owners differ, trust levels differ, or same-port behavior is unconfirmed. In both cases, move one name at a time. Confirm that a normal request reaches the intended upstream. Only then, on a site you own, try a probe of the kind shown in the application guide, such as a SQL injection or path traversal query, and confirm the blocking page plus the attack detail in that instance. Never send those probes to a site you do not control.

Neither placement adds a feature the docs do not list. A single instance is still a reverse proxy, with one application definition for each site you successfully add and verify. Several instances are several copies of that same model. Choose the failure boundary first. Then follow the documented install and application steps inside that boundary.

Can one installation front several sites?

The sources do not promise a multi-site mode. They show an Applications page and an Add Application action with one domain, one port, and one upstream. A shared installation is only a plan to repeat that action and verify each row before DNS changes. If a second application cannot be saved, or cannot listen as expected, stop and use a separate instance.

Do several sites have to share port 443?

No. The dialog asks for a listen port and gives 80 and 443 as examples. It also says to check SSL for HTTPS apps. It does not document virtual-host sharing rules. Treat shared ports as unproven until a test console accepts that exact combination. Distinct ports, or distinct instances, avoid the guess.

Does sharing a proxy lower the resource floor?

No. The install guide states a minimum of 1 core, 1 GB of memory, and 5 GB of disk for an instance. It does not say that floor shrinks as you add applications, and it does not publish a site-count capacity number. Treat the floor as a floor. Size the host for the traffic you expect. Choice B multiplies the floor because it multiplies instances.

Where must each domain point?

The application guide says to resolve the entered domain to the IP of the server running SafeLine. In a shared placement, point a name at that IP only after the matching application exists there. In a per-site placement, point each name only at the instance that contains that application. A name aimed at the wrong console will not inherit another site's upstream.

What should the cutover include, and what should it leave out?

Include a host that meets the deploy guide, a console login, one application entry per site, the SSL option when the app is HTTPS, DNS to the correct server, a normal request check, and a block check on a site you own. Leave out origin autodiscovery, an assumed shared-certificate workflow beyond the SSL checkbox, and same-host stacking of several installs. Those are not part of the documented path.

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)