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.
Table of Contents
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_confsThe 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_confsMoving 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 '<?php echo php_sapi_name();' > /home/testuser/domains/test.example/public_html/sapi.php
curl -s https://test.example/sapi.phpExpect fpm-fcgi on Apache or nginx_apache and litespeed on either LiteSpeed product. Load a WordPress site with permalinks enabled to prove rewrites work, and check .htaccess behaviour explicitly on OpenLiteSpeed by adding a rule and confirming when it takes effect. Watch the error log for the new stack for the first hour: /var/log/httpd/error_log for Apache, /var/log/nginx/error.log, or /usr/local/lsws/logs/error.log for the LiteSpeed family. If you plan to use LiteSpeed caching with WordPress, the LiteSpeed Cache setup guide covers the plugin side, which is the same on DirectAdmin.
CustomBuild web stack at a glance
Official documentation: LiteSpeed documentation, DirectAdmin documentation, Linux man pages.
Related guides: Choosing a VPS for a cPanel or DirectAdmin server in 2026 · Switching PHP versions and enabling extensions (pcntl, pdo_pgsql, mailparse, ionCube) with CustomBuild · Running Node.js and Python apps with Nginx Unit and per-user Redis on DirectAdmin.
Frequently asked questions
Does OpenLiteSpeed support .htaccess files on DirectAdmin?
Partly. It reads a subset of directives and loads rewrite rules at startup or graceful restart rather than per request, so panel-made changes are picked up but rules an application writes at runtime may wait until the next restart.
How long does switching the web server in CustomBuild take?
Building the new server and rebuilding PHP typically takes ten to thirty minutes depending on how many PHP versions are installed, followed by rewrite_confs; sites are briefly unavailable while the new daemon takes over ports 80 and 443.
Can I switch back to Apache after trying LiteSpeed or OpenLiteSpeed?
Yes. Set webserver apache and php1_mode php-fpm, rebuild Apache and PHP, and run rewrite_confs; re-check any per-domain .cust_openlitespeed files, because those customisations do not carry across.