Access, caching and protection

Access rules#

The site's Access pane controls who can reach it and under which name.

• Canonical host: other names (aliases) redirect here, e.g. example.com → www.example.com.
• Password protection (HTTP basic auth): a User and a Password (at least 8 characters) asked before every page — handy for staging sites. Leave the new password empty to keep the current one.
• Allow only from: IP addresses or CIDR ranges, one per line. Empty allows everyone.

Certificate renewals keep working whatever the access rules are.

Caching#

On the site's General pane, Caching and protection:

• Page cache stores pages for anonymous visitors in nginx's FastCGI cache for the time you choose; logged-in users, carts and checkouts bypass it (WordPress and WooCommerce rules included). Purge empties it, for example after a design change.
• Object cache gives the app a Valkey (Redis-compatible) object cache for WordPress or Laravel. Install the object cache once on the server's Databases section; the switch then appears on each PHP site.

Web application firewall#

With the WAF installed in the server's web stack (ModSecurity with the OWASP Core Rule Set), each site chooses:

• Detect only — attacks are logged but not stopped. Start here to check that the app works normally.
• Block — attacks are refused with a 403.
• Off.

Built-in protection#

Every site also gets, without any setting: hidden dotfiles (.env, .git) and backup files (.sql, .bak…), security headers (X-Content-Type-Options, Referrer-Policy), 30-day browser caching for static assets, CrowdSec blocking attackers at the firewall, and its own Linux user so it cannot read other sites' files.

WordPress sites have extra Security filters — see WordPress.