Web servers and engines #

This section is for system administrators and product managers at hosting companies who must decide what serves an Exponential site on their machines, and set it up. It answers: which web servers and engines Exponential runs behind, which one the project recommends, which one fits which hosting model, and where the exact settings are.

Back to Hosting companies: start here.

Contents #

1. The short answer
2. The servers at a glance
3. Pages in this section
4. What every setup has in common
5. Related pages

The short answer #

• Exponential Velocity (the qbix engine) is the project's recommended way to serve a site at every stage, from development to production. It is a web server written in PHP that keeps the application loaded in persistent workers, answers repeat pages from its own response cache and serves HTTPS itself (Chapter 8).
• FrankenPHP, driven by the same exp:velocity command, is the production-ready alternative.
• Apache with PHP-FPM and nginx with PHP-FPM are the traditional setups. They remain fully supported and are what shared hosting usually offers, because Velocity needs a long-running process that shared hosting usually does not allow (README.md, "When a traditional server is still the right answer").
• Any other web server that can pass a request to PHP and rewrite a URL to index.php serves Exponential too (Operating system support, Web servers).

The servers at a glance #

The tiers come from Operating system support.

Pages in this section #

What every setup has in common #

Whatever serves the site, the same rules apply (Chapter 8, How a request is served):

• The document root is the installation root, the directory that holds index.php.
• The routing is written down once, in .htaccess_root. Velocity's engines and the generated FrankenPHP configuration implement the same list rule for rule. Apache (with AllowOverride All) and LiteSpeed Enterprise read it as .htaccess, which ./console exp:setup:htaccess --apply copies into place; OpenLiteSpeed reads only its rewrite rules (with autoLoadHtaccess, after a restart); nginx, Caddy and IIS never read it (Setting up .htaccess and config.php from the console).
• No PHP file runs because its path was asked for, except the front controllers at the root (index.php, index_rest.php, index_treemenu.php, and index_soap.php when SOAP is on; it was soap.php before 6.0.15, see the SOAP entry script is now index_soap.php).
• WebDAV, when you switch it on, needs a rule of its own for index_webdav.php (its name since 6.0.15; webdav.php only forwards to it until a later major version) on Apache, nginx or IIS, in the HTTPS virtual host too. Velocity does not serve it. See The WebDAV entry script is now index_webdav.php.
• Only listed asset paths are sent as files; settings/site.ini, the SQLite database or a kernel source requested by path reach index.php, never the file.
• The user that runs PHP must be able to write var/ and the settings/ directories, and one user (or one group) should write them, whichever server runs (Chapter 8, File permissions and ownership).

Check the routing on any server with the four requests of chapter 8, replacing the address with your own:

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/.git/config                      # 404 (403 from qbix)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/kernel/classes/ezcontentobject.php  # 404
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/robots.txt                        # 200 when the file exists
curl -s https://example.com/settings/site.ini | grep -c '^\[DatabaseSettings\]'                # 0

A 200 for the .git or kernel request means the rules are not active. Stop and fix that before the site is reachable from outside.

Related pages #

• Hosting companies: start here
• Performance
• Chapter 8: Serving the site
• Operating system support
• Velocity engines
• Setting up .htaccess and config.php from the console
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.