# CustomBuild Web Stack 2026: Apache, nginx or LiteSpeed, Best Pick

Source: https://srvscripts.com/guides/custombuild-web-stack-apache-nginx-litespeed/
Updated: 2026-10-06
Publisher: srvScripts (https://srvscripts.com/)

CustomBuild lets a DirectAdmin server run one of four web stacks, and the choice is set with a single option that can be changed at any time. That flexibility is useful, but each stack has different implications for `.htaccess` support, PHP handling, caching and licensing. Current CustomBuild tracks Apache 2.4.68, nginx 1.31, OpenLiteSpeed 1.9 and LiteSpeed Enterprise 6.3.7, so all four are current upstream releases; the decision is about fit, not about which is maintained.

In short: Apache is the compatible default, nginx_apache adds an nginx proxy for static files while keeping .htaccess, OpenLiteSpeed gives event-driven performance for free with cached rewrite rules, and LiteSpeed Enterprise adds full on-demand…

**Short answer:** Apache is the compatible default, nginx_apache adds an nginx proxy for static files while keeping `.htaccess`, OpenLiteSpeed gives event-driven performance for free with cached rewrite rules, and LiteSpeed Enterprise adds full on-demand `.htaccess` handling and LSCache for a licence fee. For shared hosting choose LiteSpeed Enterprise or OpenLiteSpeed; for a small VPS with your own applications keep Apache with PHP-FPM. Switch with `./build set webserver <stack>` and the matching `php1_mode`, then rebuild and run `./build rewrite_confs`.

## The four options at a glance

**Apache** is the default and the most compatible. Every WordPress plugin, every legacy PHP application and every `.htaccess` rewrite trick works. With PHP-FPM and the event MPM it is far faster than its reputation, but it is still the slowest of the four under high concurrency and the most memory-hungry per connection.

**nginx_apache** puts nginx in front as a reverse proxy that serves static files and terminates TLS, then passes dynamic requests to Apache on a local port. You keep `.htaccess` compatibility for PHP while static assets are served by nginx. The cost is two daemons to monitor and a proxy layer that occasionally confuses applications that read the client IP from the wrong header.

**OpenLiteSpeed** is a free event-driven server with its own PHP SAPI (lsphp), a built-in page cache and high concurrency at low memory. It reads a subset of `.htaccess` directives, but on OpenLiteSpeed rewrite rules are loaded when the server starts or a graceful restart is triggered, not on every request. DirectAdmin’s CustomBuild handles the restart on `.htaccess` changes made through the panel, but changes made by an application at runtime may not apply until the next restart.

**LiteSpeed Enterprise** is the paid product: full `.htaccess` compatibility read on demand, Apache-equivalent configuration, LSCache with the official WordPress plugin, HTTP/3, and per-vhost isolation. It needs a LiteSpeed license in addition to the DirectAdmin license and is the usual choice for high-density shared hosting.

## Matching the stack to the workload

For a shared-hosting node with mixed customer sites, we default to LiteSpeed Enterprise when the budget allows and OpenLiteSpeed when it does not. Both handle a large number of idle keep-alive connections cheaply, and LSCache removes most of the PHP execution cost from WordPress-heavy servers. On a small VPS hosting a handful of your own applications, plain Apache with PHP-FPM is simpler to reason about and has no rewrite-caching surprises.

nginx_apache is the right pick when you have static-heavy sites and want nginx’s efficiency without giving up `.htaccess`, or when you need nginx-specific features such as its rate limiting or upstream handling in front of Apache. It is the wrong pick if your team does not already know nginx; debugging requires reading two sets of logs.

Standalone nginx (`webserver=nginx`) is also available but drops `.htaccess` support entirely, which makes it unsuitable for customers who expect to upload WordPress and have it work. It suits single-purpose servers where you control every application.

## Switching stacks

The switch is done from `/usr/local/directadmin/custombuild`. Back up the current configuration first because `rewrite_confs` regenerates every virtual host:

```
cd /usr/local/directadmin/custombuild
tar czf /root/webconfs-$(date +%F).tgz /etc/httpd/conf /usr/local/lsws/conf 2>/dev/null
./build set webserver openlitespeed
./build set php1_mode lsphp
./build openlitespeed
./build php
./build rewrite_confs
```

The `php1_mode` setting matters. Apache and nginx_apache work best with `php-fpm`; OpenLiteSpeed and LiteSpeed use `lsphp`. If you change the web server but leave the PHP mode alone, CustomBuild will warn and the sites will fail to execute PHP. Each PHP version slot (`php1_mode` through `php4_mode`) has its own mode setting, so check them all with `./build options`.

For LiteSpeed Enterprise, place the license serial where the build expects it and set the web server option:

```
./build set webserver litespeed
./build set php1_mode lsphp
./build litespeed
./build php
./build rewrite_confs
```

Moving away from a LiteSpeed product to Apache is the reverse sequence with `php1_mode php-fpm`. After any switch, run `./build all d` only if you also want everything else rebuilt; otherwise the targeted commands above are faster and less disruptive.

## Custom templates survive the switch, sometimes

Per-domain customisations live in `/usr/local/directadmin/data/users/<user>/domains/<domain>.cust_httpd`, `.cust_nginx` or `.cust_openlitespeed` depending on the stack, and global template overrides live under `/usr/local/directadmin/data/templates/custom/`. Rules written for Apache are not automatically translated. When you change web server, audit these files for every account, because a `.cust_httpd` file is simply ignored by OpenLiteSpeed and a customer’s IP allowlist or PHP override silently disappears.

Since 1.710 the templates use a unified `DOCROOT` token and subdomain `www` aliases are no longer added automatically. Any custom template still referencing `SDOCROOT` or `REALDOCROOT` breaks on that release regardless of web server, so the stack change is a good moment to bring custom templates up to date.

## Verify

After `rewrite_confs`, confirm the intended daemon is listening and that PHP runs through the expected SAPI:

```
ss -ltnp | grep -E ':80 |:443 '
systemctl status httpd nginx lsws --no-pager 2>/dev/null
echo '