On this page

# Topics

Webservers for Joomla

Q: Which web servers and versions are supported by Joomla?

Joomla 6 officially supports the following web servers: Apache HTTP Server 2.4 or later Nginx 1.26 or later (recommended: Nginx 1.29) Microsoft IIS 10 or later See: Joomla! Programmers Documentation: Requirements for Joomla! 6.x . In addition to a supported web server, Joomla requires a supported version of PHP and one of its supported database servers, such as MariaDB, MySQL or PostgreSQL. The required PHP extensions must also be installed. To use Search Engine Friendly (SEF) URLs, Apache requires the mod_rewrite module, while Microsoft IIS requires the URL Rewrite Module. Nginx provides URL rewriting through its own server configuration. Although not listed in the official system requirements, Joomla also runs very well on other modern web servers such as LiteSpeed Enterprise , OpenLiteSpeed and Caddy , provided they are correctly configured and meet Joomla's PHP and server requirements. For the best compatibility, security and performance, it is recommended to use recent stable versions of both your web server and PHP.

27 June 2026

Every Joomla site, no matter how simple or how large, sits behind a piece of software that almost nobody talks about: the web server. It is the program that listens for a browser request, hands the work to PHP, and sends the finished page back. Pick the right one and configure it well, and your site is fast, safe, and quiet. Get it wrong, and you fight broken URLs, slow pages, and security holes that have nothing to do with Joomla itself.

This article explains the web servers that run Joomla in the real world: Apache, Nginx, OpenLiteSpeed and LiteSpeed, Microsoft IIS, and a few newer options. It covers the basics for site owners, the setup details for administrators, and the technical behaviour developers need to know, including SEF URL rewriting, PHP handlers, performance, and security.

Joomla writes the page, but the web server decides how fast and how safely it reaches the visitor.

The goal is simple: help you understand which web server suits your Joomla site and how to configure it correctly.

1. The Basics

1.1 What is a Web Server?

A web server is the software that answers requests from browsers. When someone opens https://example.test/about-us, the browser sends an HTTP request, and the web server is the first program on your hosting that receives it. It then decides what to do: send a file straight back, or pass the request to an application like Joomla.

Two things share the name "web server", and it helps to keep them apart:

The machine (the physical or virtual server that hosts your site).
The web server software (Apache, Nginx, and the rest). This article is about the software.

1.2 Static Files Versus PHP

A Joomla page is not a file sitting on disk. Joomla builds it on the fly with PHP and the database. The web server has to tell the difference between two kinds of request:

Static files such as images, CSS, JavaScript, and fonts. The web server reads them from disk and sends them directly. This is fast.
Dynamic requests for pages that Joomla has to generate. The web server passes these to PHP, waits for the result, and returns it.

1.3 The Request Journey

Almost every Joomla page follows the same path:

Browser
   ↓
Web server (Apache / Nginx / LiteSpeed / IIS)
   ↓
PHP (runs Joomla's index.php)
   ↓
Database (MySQL or MariaDB)
   ↓
HTML back to the browser

The web server is the gatekeeper at the top of this chain. It is the part most people never think about until something breaks.

2. What the Web Server Does for Joomla

2.1 The Single Entry Point

Joomla uses a front controller pattern. Nearly every front-end request ends up at one file, index.php in the site root, and the back-end runs from administrator/index.php. The web server's job is to route the request to the right entry point and let Joomla take over from there.

2.2 The Four Core Tasks

Whatever software you choose, you ask a web server to do the same four things for Joomla:

Task	Why Joomla needs it
Serve static files	Deliver images, CSS, and JavaScript quickly.
Run PHP	Execute `index.php` so Joomla can build the page.
Rewrite URLs	Turn clean SEF URLs into something Joomla understands.
Enforce HTTPS and rules	Force secure connections, block paths, set headers.

2.3 Why the Choice Matters

Joomla runs on all of these servers. The difference shows up in three places: how you configure SEF URLs, how fast the server handles many visitors at once, and how you harden it. The rest of this article walks through each server with those three points in mind.

3. Apache

3.1 The Traditional Default

Apache HTTP Server is the most widely used web server for Joomla, especially on shared hosting and cPanel servers. It has been the default for the LAMP stack (Linux, Apache, MySQL, PHP) for decades, and Joomla ships with an Apache configuration file out of the box.

3.2 The .htaccess File

Apache's signature feature is the .htaccess file: a per-directory configuration file that you can edit without touching the main server config. Joomla ships a ready-made one named htaccess.txt in the site root. To use clean URLs you rename it:

htaccess.txt   →   .htaccess

This single rename is the step most beginners forget. Without it, SEF URLs with rewriting enabled return "404 Not Found" for every page except the home page.

3.3 What the Joomla .htaccess Does

The shipped file is not just URL rewriting. It also blocks common attack patterns and routes the API. The core rewrite block looks like this:

RewriteEngine On

# Route the Web Services API to its own entry point
RewriteCond %{REQUEST_URI} ^/api/
RewriteCond %{REQUEST_URI} !^/api/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* api/index.php [L]

# Send everything else that is not a real file or folder to index.php
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

The two !-f and !-d conditions say: "if the request is a real file or a real directory, serve it directly; otherwise hand it to Joomla." That is how a request for /about-us reaches Joomla while /images/logo.png is served straight from disk.

3.4 The Trade-Off

Reading .htaccess in every directory on every request is flexible but slow at scale. On a busy site, moving those rules into the main Apache virtual host (and turning AllowOverride off) is faster, but you lose the convenience of per-folder edits. On shared hosting you rarely have that choice, so .htaccess stays.

3.5 Multi-Processing Modules (MPM)

Apache can handle requests in three different ways, called Multi-Processing Modules. The one your host picks affects how much memory the server uses and how well it copes with many visitors at once.

MPM	How it works	Trade-off
`prefork`	One process per request, no threads.	Very stable, but heavy on memory. Required by the old `mod_php`.
`worker`	Processes that each run several threads.	Lower memory use than prefork.
`event`	Like worker, but handles idle Keep-Alive connections more efficiently.	The best modern choice, and the natural partner for PHP-FPM.

For a Joomla site, the modern combination is the event MPM with PHP-FPM (see section 10). The old pairing of prefork with mod_php still works, but it uses far more memory under load. If your host offers a choice, prefer event plus PHP-FPM.

4. Nginx

4.1 Built for Concurrency

Nginx (pronounced "engine-x") was designed to handle many connections at once with very little memory. Where Apache traditionally starts a process or thread per connection, Nginx uses an event-driven model that scales smoothly under heavy traffic. This makes it popular for high-traffic Joomla sites, VPS hosting, and as a reverse proxy in front of other servers.

4.2 No .htaccess Here

The biggest surprise for people moving from Apache: Nginx does not read .htaccess files. All configuration lives in the server's main config files, which you edit once and reload. This is faster, but it means you cannot drop rules into a folder, and many copy-paste tutorials written for Apache simply do not apply.

4.3 The Joomla Nginx Rewrite

You place the SEF rewrite rule inside your server { } block. The Joomla equivalent of the .htaccess rule is short:

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
    fastcgi_pass   unix:/run/php/php8.3-fpm.sock;
    fastcgi_index  index.php;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

The try_files line is the heart of it: try the real file, then the directory, and if neither exists, send the request to index.php. That is the same logic as Apache's !-f and !-d conditions, written differently.

4.4 Things to Add by Hand

Because there is no Joomla-supplied Nginx file, you must add a few protections that .htaccess gives you for free, for example denying access to configuration.php and to the .git folder, and routing /api/ to api/index.php. The Joomla documentation publishes a full sample Nginx configuration you can adapt.

5. OpenLiteSpeed and LiteSpeed

5.1 Two Versions of the Same Idea

LiteSpeed is a high-performance web server that aims to be a faster, drop-in replacement for Apache. It comes in two forms:

LiteSpeed Web Server (LSWS) - the commercial product, common on managed hosting.
OpenLiteSpeed (OLS) - the free, open-source edition.

5.2 Apache Compatibility

LiteSpeed Enterprise is designed to work as a near drop-in replacement for Apache. It reads Apache .htaccess files directly, which lets you migrate a Joomla website from Apache with little or no configuration change: existing rewrite rules, redirects and many Apache directives keep working as expected.

OpenLiteSpeed, the free and open-source edition, also supports Joomla's .htaccess rewrite rules when Auto Load from .htaccess is enabled. It is not a complete Apache replacement, though: server and virtual host settings are managed through the OpenLiteSpeed configuration rather than Apache, and some Apache-specific modules and directives are not supported.

For a typical Joomla website that uses the standard .htaccess file for Search Engine Friendly (SEF) URLs and redirects, both editions work well. The main differences only appear with advanced Apache features and enterprise functionality.

5.3 The LSAPI Advantage

LiteSpeed runs PHP through its own interface, LSAPI, which is generally faster than the classic FastCGI used elsewhere. Combined with its built-in cache, LiteSpeed often delivers the best raw performance for a typical Joomla site without much tuning.

5.4 LiteSpeed Cache

LiteSpeed ships a server-level page cache. There is no official Joomla LSCache plugin in the way there is for some other platforms, but the server cache and Joomla's own caching still help. Test carefully: aggressive full-page caching can serve logged-in users the wrong content if you do not exclude the right pages and cookies.

6. Microsoft IIS

6.1 Joomla on Windows

Internet Information Services (IIS) is Microsoft's web server, built into Windows Server. Joomla runs on it, and it is the natural choice when a company already runs a Windows environment. It is far less common than the Linux servers, but it is fully supported.

6.2 The web.config File

IIS does not use .htaccess. Its equivalent is an XML file named web.config, and Joomla ships one as web.config.txt in the site root. As with Apache, you rename it:

web.config.txt   →   web.config

This file contains the URL Rewrite rules that send clean URLs to index.php. It needs the Microsoft URL Rewrite module installed in IIS, which is a separate download and the step people most often miss.

6.3 PHP on IIS

PHP runs on IIS through FastCGI. The path separators, file permissions, and case-sensitivity rules differ from Linux, so a few extensions that assume Linux paths can misbehave. For most core Joomla sites it works well, but it is wise to test third-party extensions before you commit.

7. Other Web Servers

7.1 Caddy

Caddy is a modern web server that automatically obtains and renews HTTPS certificates from Let's Encrypt with no manual setup. It runs Joomla through PHP-FPM and uses a short, readable config file. It is a strong choice for developers who want HTTPS to "just work", though it has a smaller community than Apache or Nginx.

7.2 Reverse Proxy Setups

Many real-world stacks combine servers. A common pattern puts Nginx in front as a reverse proxy and Apache behind it:

Browser → Nginx (static files, SSL, cache) → Apache (.htaccess, PHP) → Joomla

This gives you Nginx's speed for static files and Apache's .htaccess flexibility for Joomla. The catch is that Joomla must know the visitor's real protocol and address, which the proxy passes in headers like X-Forwarded-Proto and X-Forwarded-For. If those are not set, Joomla can build the wrong URLs or think every visitor shares one IP.

7.3 The Local Development Server

PHP has a tiny built-in web server (php -S) useful for quick local testing. It is single-process and not built for production, but it can serve a Joomla site for a developer checking something on a laptop. Tools like Docker, DDEV, and Laragon wrap a full Apache or Nginx stack for local work instead.

8. Choosing a Web Server for Joomla

8.1 A Practical Comparison

There is no single best answer. The right choice depends on your hosting, your traffic, and who maintains the server.

Server	Best for	SEF config	Reads .htaccess?
Apache	Shared hosting, cPanel, easy setup	Rename `htaccess.txt`	Yes
Nginx	High traffic, VPS, reverse proxy	Server config block	No
LiteSpeed	Performance with Apache compatibility	Reads `.htaccess`	Yes (commercial)
OpenLiteSpeed	Free performance server	Own rewrite settings	No (by default)
IIS	Windows environments	Rename `web.config.txt`	No (uses web.config)
Caddy	Automatic HTTPS, developers	Caddyfile rules	No

8.2 A Simple Rule of Thumb

On shared hosting, you usually get Apache or LiteSpeed and little choice. That is fine for most sites.
For a busy site on a VPS, Nginx or LiteSpeed will handle concurrent visitors better.
If you value Apache compatibility plus speed, LiteSpeed is the easy upgrade.
If you are locked into Windows, IIS is the supported path.

The web server matters, but for most Joomla sites, good PHP settings, caching, and an optimised database make a bigger difference to speed than the server brand.

9. SEF URLs and URL Rewriting

9.1 The Two Joomla Settings

Clean URLs in Joomla depend on two options in System → Global Configuration → Site:

Search Engine Friendly URLs - turns index.php?option=com_content&view=article&id=42 into /news/42-my-article. This works on any web server.
Use URL Rewriting - removes the index.php from the path so the URL becomes /news/my-article. This one needs the web server's rewrite engine and the matching config file.

9.2 Why It Breaks

The classic failure is turning on Use URL Rewriting without renaming the server config file. Joomla then produces URLs without index.php, but the web server does not know how to route them, and every internal link returns a 404.

The fix on Apache: rename htaccess.txt to .htaccess. On IIS: rename web.config.txt to web.config and install URL Rewrite. On Nginx and OpenLiteSpeed: add the try_files or rewrite rule to the server config.

9.3 The Base Path

If Joomla lives in a subfolder, for example https://example.test/blog/, Apache needs the right base. The shipped file has a commented line you uncomment and edit:

# RewriteBase /blog

Forgetting this is the second most common rewrite problem after forgetting the rename.

10. How PHP Runs Behind the Server

10.1 The Handler Matters

The web server does not run PHP itself. It passes the request to a PHP handler, and the handler you use affects speed and memory more than the server brand does.

Handler	Used with	Notes
`mod_php`	Apache (older setups)	PHP runs inside Apache. Simple but heavier; being phased out.
PHP-FPM	Nginx, Apache, Caddy	PHP runs as its own pool of processes. The modern standard.
LSAPI	LiteSpeed, OpenLiteSpeed	LiteSpeed's own interface. Fast and efficient.
FastCGI	IIS, others	Generic interface between server and PHP.

10.2 PHP-FPM in Plain Words

PHP-FPM (FastCGI Process Manager) keeps a pool of PHP workers ready and waiting. When a Joomla request arrives, the web server hands it to a free worker, which runs index.php and returns the page. Because the workers are separate from the web server, you can tune how many run, restart PHP without restarting the web server, and run different PHP versions for different sites on the same machine.

10.3 OPcache

Whatever handler you use, enable OPcache. It stores Joomla's compiled PHP in memory so the server does not recompile the same files on every request. It is the single biggest free speed win for any PHP site and is on by default in modern PHP builds.

10.4 Tuning the FPM Pool

PHP-FPM runs a pool of workers, and a handful of settings control how many it keeps and when it recycles them. The defaults are conservative; on a busy Joomla site you tune them to your available memory.

pm = dynamic              ; grow and shrink workers with traffic
pm.max_children = 20      ; hard ceiling on concurrent PHP workers
pm.start_servers = 4      ; workers ready at startup
pm.min_spare_servers = 2  ; keep at least this many idle
pm.max_spare_servers = 6  ; trim idle workers above this
pm.max_requests = 500     ; recycle a worker after N requests

The setting that matters most is pm.max_children: it caps how many Joomla requests run at the same time. Set it too high and a traffic spike can exhaust memory and crash the server; set it too low and visitors queue. A rough guide is to divide the memory you can spare for PHP by the average memory one Joomla worker uses (often 40 to 80 MB). The pm.max_requests line restarts each worker periodically, which quietly cleans up after any extension that leaks memory.

11. Performance and Caching

11.1 Layers of Speed

A fast Joomla site stacks several caches and optimisations, and the web server sits in the middle of them:

Browser cache        (set by the server, expires headers)
   ↓
Server page cache    (LiteSpeed Cache, Nginx FastCGI cache)
   ↓
Joomla cache         (System - Page Cache plugin, view caching)
   ↓
OPcache              (compiled PHP in memory)
   ↓
Database             (the slowest layer to reach)

The closer a request is answered to the top, the faster it is. A page served from the browser or server cache never even reaches PHP.

11.2 Compression

Turn on text compression at the server so HTML, CSS, and JavaScript travel smaller. Modern servers support Gzip and the newer, better Brotli. Joomla can also gzip its own output (Global Configuration → Server → Gzip Page Compression), but doing it once at the web server is usually cleaner. Do not enable both at the same time for the same content.

11.3 Static File Expiry

Tell browsers to keep images, CSS, and fonts for a long time with cache headers. On Apache this lives in .htaccess with mod_expires; on Nginx it is an expires directive in a location block. Long expiry plus versioned file names means returning visitors download almost nothing on a second visit.

11.4 HTTP/2 and HTTP/3

Enable HTTP/2 or HTTP/3 at the server. They let the browser fetch many files over one connection, which suits Joomla pages that load several CSS and JavaScript assets. They need no change inside Joomla; it is purely a server setting on top of HTTPS.

11.5 Scaling Out: Load Balancing

When one server is no longer enough, you scale out by running several application servers behind a load balancer that spreads requests across them:

            Load Balancer
           /      |      \
     Web 1      Web 2      Web 3
           \      |      /
            Shared Database
            Shared Media / Sessions

This adds redundancy (one server can fail without taking the site down) and lets you do maintenance without downtime. Joomla needs two things to run this way correctly. First, set Behind Load Balancer = Yes in Global Configuration so Joomla trusts the forwarded headers (see section 13.2). Second, share the state that would otherwise differ per server: store sessions in a shared place such as the database or Redis, and put user-uploaded media on shared storage so every server sees the same files. Most small and medium Joomla sites never need this, but it is the standard pattern for high-traffic installations.

12. Security and Hardening

12.1 Protect the Sensitive Files

A few files must never be downloadable. The most important is configuration.php, which holds your database password. Joomla stores it outside the web-served output by design, but a misconfigured server can still expose it. Block direct access to these on every server:

configuration.php and any *.bak or *.old copies.
Hidden folders such as .git and .env files.
The cli/ and tmp/ areas from direct web access.

12.2 Force HTTPS

Redirect all HTTP traffic to HTTPS at the server, and let Joomla back it up with Global Configuration → Server → Force HTTPS = Entire Site. On Apache this is a rewrite rule in .htaccess; on Nginx a return 301 in a port-80 server block. A free certificate from Let's Encrypt covers it, and Caddy or LiteSpeed can manage the certificate for you.

12.3 TLS and Modern Encryption

HTTPS is HTTP wrapped in TLS, the protocol that encrypts the traffic between browser and server. Before any page loads, the two sides perform a short TLS handshake:

The browser checks the server's certificate and confirms it is valid and trusted.
Both sides agree on a cipher (the encryption method).
They establish shared session keys.
The encrypted exchange of the actual page begins.

Configure the server to use TLS 1.3, and at most TLS 1.2 as a fallback. Switch off the old SSL and TLS 1.0/1.1 versions, which are insecure and rejected by modern browsers anyway. TLS 1.3 is also faster: its handshake needs fewer round trips, so the first page arrives sooner. This is a server setting; Joomla itself needs no change beyond Force HTTPS.

12.4 Security Headers Belong at the Server Too

Joomla ships a System - HTTP Headers plugin that sets most modern security headers from the backend. But one header it does not set, X-Content-Type-Options: nosniff, is best added at the server. The shipped Joomla htaccess.txt already includes it:

Header always set X-Content-Type-Options "nosniff"

Keep server-level and plugin-level headers in sync. If both set the same header with different values, the one that runs last wins, and that is usually the server or a proxy.

12.5 Block Bad Requests: WAF, Fail2ban, and Rate Limiting

The hardening above protects files and connections. The next layer stops abusive requests before they reach Joomla:

ModSecurity - a Web Application Firewall (WAF) that runs in Apache, Nginx, or LiteSpeed and inspects requests against rule sets such as the OWASP Core Rule Set. It blocks common SQL injection and cross-site scripting patterns at the server.
Fail2ban - watches your server logs and temporarily bans IP addresses that misbehave, for example repeated failed logins on administrator/ or a flood of 404s.
Rate limiting - caps how many requests one client may make in a window. On Nginx this is limit_req; it slows brute-force and scraping without affecting normal visitors.

A cloud service like Cloudflare can provide the same WAF and rate-limiting layer in front of any web server. These tools complement Joomla's own protections; they do not replace strong passwords, updates, and multi-factor authentication.

By default Apache and Nginx announce their name and version in the Server response header. Set ServerTokens Prod on Apache or server_tokens off; on Nginx so you do not advertise exactly what an attacker is looking at.

13. Under the Hood (Developer View)

13.1 How Joomla Sees the Server

Joomla reads the environment the web server hands to PHP through the $_SERVER superglobal. A few values matter for how Joomla builds URLs and detects HTTPS:

Variable	What Joomla uses it for
`HTTP_HOST`	The domain, to build absolute links.
`REQUEST_URI`	The requested path, to route the page.
`HTTPS`	To decide whether the connection is secure.
`SERVER_SOFTWARE`	Identifies Apache, Nginx, LiteSpeed, or IIS.
`HTTP_X_FORWARDED_PROTO`	The real protocol when behind a proxy.

13.2 The Behind-a-Proxy Trap

When Joomla sits behind a reverse proxy or a load balancer that terminates HTTPS, PHP can see plain HTTP and SERVER_ADDR for the proxy, not the visitor. Joomla then risks building http:// links on an https:// site, causing redirect loops or mixed-content warnings. The fix is to make the proxy send X-Forwarded-Proto and to set Behind Load Balancer = Yes in Global Configuration so Joomla trusts those headers.

13.3 Config Files Are Not Portable

Rewrite logic is identical in spirit across servers but written in four different languages. The same Joomla rule looks like this in each:

Apache  (.htaccess)   RewriteRule .* index.php [L]
Nginx   (server)      try_files $uri $uri/ /index.php?$args;
IIS     (web.config)  <action type="Rewrite" url="index.php" />
Caddy   (Caddyfile)   try_files {path} {path}/ /index.php?{query}

When you migrate a site between servers, you do not copy the file; you translate the intent. This is why a "working" Apache .htaccess does nothing on Nginx.

14. SEO and Metadata

The web server influences SEO well before any plugin does. Search engines reward sites that are fast, secure, and consistent, and all three start at the server:

Clean URLs: enable SEF URLs and rewriting so paths are readable and stable. Avoid changing them later without 301 redirects.
One canonical host: redirect http to https and pick either www or non-www, then redirect the other. Serving the same page on several hosts splits ranking signals.
Speed: compression, caching, OPcache, and HTTP/2 all improve Core Web Vitals, which feed Google's ranking.
Correct status codes: a missing page must return 404, a moved page 301. A server that answers everything with 200 confuses crawlers and wastes crawl budget.

None of this needs an SEO extension. It is configuration you set once at the server and in Global Configuration, and it pays off on every page.

15. Common Mistakes and Pitfalls

15.1 URL Rewriting Without the Config File

Symptom: the home page works, but every other page returns 404 after you switch on Use URL Rewriting.

Fix: rename htaccess.txt to .htaccess on Apache, or web.config.txt to web.config on IIS, or add the rewrite rule to Nginx or OpenLiteSpeed.

15.2 Copying Apache Rules to Nginx

Symptom: you paste an .htaccess snippet into Nginx and nothing happens.

Fix: Nginx ignores .htaccess entirely. Translate the rule into a location block and reload the server.

15.3 Mixed-Content and Redirect Loops Behind a Proxy

Symptom: the padlock breaks, or the site redirects forever, after moving behind a load balancer or CDN.

Fix: pass X-Forwarded-Proto from the proxy and set Behind Load Balancer to Yes in Global Configuration.

15.4 Exposed configuration.php or .git

Symptom: a security scan reports that /.git/ or a config backup is downloadable.

Fix: deny these paths at the server. The Apache .htaccess handles much of it; on Nginx and OpenLiteSpeed you add the deny rules by hand.

15.5 Double Compression

Symptom: pages look broken or download as garbled text after enabling Gzip in Joomla.

Fix: compress in one place only. If the server already gzips output, leave Joomla's Gzip Page Compression off.

15.6 The Subfolder RewriteBase

Symptom: rewriting works on a site in the web root but breaks when Joomla lives in a subfolder.

Fix: uncomment and set RewriteBase /subfolder in .htaccess, or the matching base path on other servers.

16. Best Practices

If you remember only a few things from this article, remember these:

Rename the shipped config file (htaccess.txt or web.config.txt) before you turn on URL rewriting.
Use PHP-FPM or LSAPI, never the old mod_php, and keep OPcache on.
On Apache, run the event MPM with PHP-FPM rather than prefork with mod_php.
Tune the FPM pool to your memory; size pm.max_children so a traffic spike cannot exhaust RAM.
Match the rewrite rule to the server; do not copy Apache rules to Nginx.
Force HTTPS at the server, prefer TLS 1.3, and pick one canonical host.
Compress and cache static files at the server, and avoid double compression.
Set Behind Load Balancer to Yes whenever a proxy, CDN, or load balancer sits in front.
Scale out with a load balancer plus shared sessions and shared media when one server is not enough.
Block configuration.php, .git, and backups from the web.
Add a request-layer defence (WAF such as ModSecurity, Fail2ban, or rate limiting) for busy or exposed sites.
Keep server-level and plugin-level security headers consistent.

17. Quick Reference

APACHE        Rename htaccess.txt → .htaccess  (reads .htaccess)
NGINX         try_files $uri $uri/ /index.php?$args;  (no .htaccess)
LITESPEED     Reads .htaccess (commercial); LSAPI for PHP
OPENLITESPEED Own rewrite rules; no .htaccess by default
IIS           Rename web.config.txt → web.config + URL Rewrite module
CADDY         Caddyfile rules; automatic HTTPS
SEF           Global Configuration → Site → SEF + Use URL Rewriting
APACHE MPM    event + PHP-FPM  (not prefork + mod_php)
PHP           PHP-FPM or LSAPI + OPcache on
FPM POOL      Tune pm.max_children to available memory
HTTPS         Force at server + Force HTTPS in Joomla; TLS 1.3
PROXY         Pass X-Forwarded-Proto + Behind Load Balancer = Yes
SCALE         Load balancer + shared sessions + shared media
SPEED         Brotli/Gzip, cache headers, HTTP/2, server cache
SECURE        Block configuration.php, .git, backups; nosniff header
DEFEND        WAF (ModSecurity) + Fail2ban + rate limiting

18. Summary

The web server is the layer beneath Joomla that most people never see, yet it decides how your site behaves under the surface. The themes repeat across every option:

Apache is the friendly default, driven by the .htaccess file Joomla ships for you.
Nginx trades per-folder flexibility for speed and scale, and needs its rules written into the server config.
LiteSpeed and OpenLiteSpeed chase performance, with the commercial edition reading .htaccess like Apache.
IIS runs Joomla on Windows through web.config and the URL Rewrite module.
Newer servers and proxy stacks add automatic HTTPS and clever caching, at the cost of a little extra setup.

Across all of them, the same four jobs decide success: route URLs correctly, run PHP efficiently, serve and cache static files, and enforce HTTPS and security rules. Get those right and the server brand matters far less than people think.

If your Joomla site is slow, throws 404s after a move, or breaks its padlock behind a CDN, the cause is often the web server configuration rather than Joomla itself. A careful look at the rewrite rules, the PHP handler, and the proxy headers usually finds the problem quickly, and it is exactly the kind of foundation work that keeps a site fast and safe for years.

Peter Martin

Joomla Specialist

Peter is a Joomla specialist and a Linux admin for fast, secure and scalable websites.

Frequently Asked Questions

Which web servers and versions are supported by Joomla?

Joomla 6 officially supports the following web servers:

Apache HTTP Server 2.4 or later
Nginx 1.26 or later (recommended: Nginx 1.29)
Microsoft IIS 10 or later

See: Joomla! Programmers Documentation: Requirements for Joomla! 6.x. In addition to a supported web server, Joomla requires a supported version of PHP and one of its supported database servers, such as MariaDB, MySQL or PostgreSQL. The required PHP extensions must also be installed.

To use Search Engine Friendly (SEF) URLs, Apache requires the mod_rewrite module, while Microsoft IIS requires the URL Rewrite Module. Nginx provides URL rewriting through its own server configuration.

Although not listed in the official system requirements, Joomla also runs very well on other modern web servers such as LiteSpeed Enterprise, OpenLiteSpeed and Caddy, provided they are correctly configured and meet Joomla's PHP and server requirements.

For the best compatibility, security and performance, it is recommended to use recent stable versions of both your web server and PHP.

Which web server is best for Joomla?

The best web server for Joomla depends on your website's requirements, including performance, compatibility, scalability and ease of management. Joomla runs reliably on all major web servers, but each has its own strengths.

Apache is the most widely supported web server for Joomla. It offers excellent compatibility, extensive documentation and is the default choice for many shared hosting providers.
Nginx is designed for high performance and scalability, making it an excellent option for busy Joomla websites and high-traffic environments.
LiteSpeed Enterprise is a commercial web server that delivers exceptional performance, built-in server-level caching and full Apache compatibility, including .htaccess support.
OpenLiteSpeed is the free, open-source edition of LiteSpeed. It offers excellent performance and supports Joomla's .htaccess rewrite rules, making it a popular choice for VPS and dedicated servers.
Caddy is a modern web server with automatic HTTPS, straightforward configuration and growing popularity among developers and self-hosted Joomla users.

For most Joomla websites:

Apache, best compatibility and ease of use
Nginx, best scalability for high-traffic websites
LiteSpeed Enterprise, best overall performance and Apache compatibility
OpenLiteSpeed, best free high-performance alternative
Caddy, easiest modern web server with automatic HTTPS

There is no single "best" web server for Joomla. Apache remains the safest choice for maximum compatibility, while LiteSpeed Enterprise and OpenLiteSpeed are excellent options for users seeking higher performance. Nginx excels in demanding environments, and Caddy offers a modern, easy-to-manage alternative.

Does Joomla work with Apache, Nginx, LiteSpeed, OpenLiteSpeed and Caddy?

Yes. Joomla supports all major modern web servers.

Apache remains the standard on many shared hosting platforms. Nginx requires its own rewrite configuration. LiteSpeed Enterprise is fully compatible with Apache's .htaccess files, while OpenLiteSpeed also supports Joomla's .htaccess rewrite rules when enabled. Caddy uses its own configuration format but runs Joomla without problems.

Is LiteSpeed or OpenLiteSpeed faster than Apache for Joomla?

In most cases, yes.

Both LiteSpeed Enterprise and OpenLiteSpeed generally outperform Apache in terms of response time, resource usage and the number of concurrent visitors they can handle. They are especially effective for PHP applications such as Joomla.

Actual performance depends on factors such as PHP, database optimisation, caching and hosting quality.

Does Joomla require Apache?

No.

Joomla does not depend on Apache and runs equally well on Nginx, LiteSpeed Enterprise, OpenLiteSpeed and Caddy. As long as the server meets Joomla's technical requirements and URL rewriting is configured correctly, Joomla can be hosted on virtually any modern Linux web server.

Which web server is the most secure for Joomla?

Security depends more on server configuration than on the web server itself.

Apache, Nginx, LiteSpeed Enterprise, OpenLiteSpeed and Caddy can all provide a secure environment for Joomla when they are properly configured, kept up to date and combined with HTTPS, secure PHP settings, firewalls and regular Joomla updates.

There is no single "most secure" web server for Joomla.

Should I switch from Apache to Nginx, LiteSpeed or OpenLiteSpeed?

If your Joomla website needs better performance or expects higher traffic, switching may be worthwhile.

LiteSpeed Enterprise offers the easiest migration because it is fully compatible with Apache configurations. OpenLiteSpeed also supports Joomla very well and provides excellent performance at no licensing cost. Nginx is highly scalable but typically requires more manual configuration.

For smaller Joomla websites on reliable hosting, Apache often remains an excellent choice.

What is the difference between LiteSpeed and OpenLiteSpeed?

LiteSpeed Enterprise and OpenLiteSpeed share the same performance-focused architecture but serve different audiences.

LiteSpeed Enterprise is the commercial edition. It is designed as a drop-in replacement for Apache, offering full .htaccess compatibility, seamless integration with existing Apache configurations and advanced enterprise features.

OpenLiteSpeed is the free, open-source edition. It delivers excellent performance for Joomla and supports Joomla's .htaccess rewrite rules when enabled, but some Apache-specific features and advanced enterprise capabilities are not included.

For most Joomla users running their own VPS or dedicated server, OpenLiteSpeed provides outstanding performance without licensing costs. Hosting providers that require maximum Apache compatibility often choose LiteSpeed Enterprise.

21 June 2026