Skip to content

Runtime and PHP settings

Both choices live on the site's Settings tab and can be changed at any time.

Runtime

RuntimeWhat runs
PHP 8.2 to PHP 8.5PHP, with the extensions listed below
StaticNo PHP at all. HTML, CSS, JavaScript and other files are served as they are

New sites default to the newest PHP version. Pick the newest your application supports: older versions stop getting security fixes first, and there is no performance reason to stay behind.

Static is not a stripped-down PHP. A .php file on a static site is served as a plain file, source and all, so never switch a PHP site to Static while PHP files are still in the document root.

Web server

Web serverChoose it when
nginxDefault. Faster, and pretty URLs work with no configuration
ApacheYour application needs .htaccess

.htaccess does nothing on nginx

nginx never reads .htaccess. Every rewrite, redirect, header and access rule in that file is silently ignored, and no error appears anywhere. A site migrated from another host keeps its .htaccess, looks like it is configured, and is not.

If your application ships an .htaccess it actually depends on, switch the web server to Apache. If it only needs pretty URLs, nginx already does that.

On nginx, a request for a file that does not exist is handed to index.php, so WordPress permalinks, Laravel routes and any other front controller work untouched. Your application decides what a missing page returns, not the web server.

Two more differences worth knowing:

  • Hidden files. On nginx every path containing a name starting with a dot is refused with 403, which covers .env, .git/ and friends. Apache has no such rule, so on Apache you must block them yourself in .htaccess.
  • Directory listings. nginx never lists a directory. On Apache the behaviour depends on your own .htaccess; add Options -Indexes if you rely on it.

Switching after creation

Changing the runtime or the web server replaces the site's containers. The portal warns you before saving:

text
Saving will briefly take your site offline (a few seconds while the new runtime starts). Continue?

The replacement waits for the new containers to answer a health check before the old ones stop, so in practice you see a few seconds of mixed old and new, not a hard outage. Expect longer the first time a given PHP version is used on the machine your site lands on.

Document root

Your files live in public_html. By default that whole directory is the document root, which is right for WordPress, Drupal, plain PHP and static sites.

Applications that keep their entry point one level down (Laravel, Symfony, Flarum) set Document root subdirectory to public. Everything above it, vendor/, storage/, configuration files, then stays unreachable from the web.

The field takes a relative subdirectory only:

text
Subdirectory only — letters, digits, _ and -, optionally separated by /. No leading slash, no path traversal.

PHP settings

The PHP Settings card appears on any PHP runtime. Six settings, each a dropdown, with three presets (Default, WordPress, Laravel) that fill all six at once.

SettingDefaultValues offered
Max upload size2M2M to 512M
Max POST size8M2M to 512M
Max execution time30s30s, 60s, 120s, 300s, 600s
Memory limit128M64M, 128M, 256M, 512M
Display errorsOffOn, Off
Error reportingE_ALL & ~E_DEPRECATEDE_ALL, E_ALL & ~E_NOTICE, E_ALL & ~E_DEPRECATED

Raising the upload size also raises the request size limit in front of the site, so you do not have to change anything else. The hard ceiling is 512 MiB whatever the setting says.

Saving PHP settings does not apply them

The first time you save this card the site restarts and the values take effect. Every later change to the same settings is stored but does not reach PHP. The site keeps running with the old values, and nothing tells you.

After changing a value, go to Actions and use Restart site. Then check the value from the console:

bash
php -i | grep memory_limit

Limits that override your settings

  • Memory limit is per request, but the whole site has 512 MiB. On nginx up to 15 PHP requests run at once, all sharing that one budget. Setting 512M therefore does not hand one request 512 MiB, it removes PHP's own brake and lets a few concurrent requests exhaust the site instead. What follows is not a clean PHP fatal error: the site runs out of memory as a whole, and requests that had nothing to do with it die too. 256M is the highest value that is safe to treat as normal.
  • On nginx, a request is cut off after 300 seconds no matter what Max execution time says, so the 600s option has no effect there. Long work belongs in a cron job, which gets its own timeout of up to 3600 seconds.
  • Max POST size should never be below Max upload size. Uploads at that size fail silently. The portal warns you when the combination is wrong.
  • Display errors belongs on Off in production. On prints file paths and sometimes source code to visitors.

Static sites have a fixed 8 MiB request limit

The PHP settings card does not appear on a Static site, and its request body limit is fixed at 8 MiB. There is no way to raise it. If a form on a static site needs to accept larger uploads, it is not a static site.

Extensions

Every PHP version ships the same set. The ones worth naming:

mysqli, pdo_mysql, pdo_sqlite, mbstring, gd, imagick, curl, xml, dom, simplexml, zip, zlib, intl, bcmath, exif, sodium, openssl, opcache, redis, sqlite3, fileinfo, iconv, posix.

Not installed, and not installable by you: soap, ldap, imap, apcu, memcached, mongodb, xsl, tidy, gmp, ssh2, xdebug. If your application requires one of these, hosting is the wrong product for it.

Every pcntl_* function and dl() are disabled. Code that forks or installs extensions at runtime will fail. exec() and shell_exec() are available.

An edited file can take 60 seconds to go live

Compiled PHP is cached and the cache is rechecked once a minute. After an upload or a deployment, a page can keep serving the old code for up to 60 seconds. It is not a caching plugin and not your browser. Wait, or use Restart site under Actions to clear it immediately.

What's next