The PHP policy of a server

Every machine decides what its customers may change about their PHP. That decision lives in one file, /etc/corecp/php-policy.yaml, and this screen is that file.

It is an allow-list. A directive that is not in it cannot be set by anyone, whatever the PHP build happens to support, and an extension that is not in it cannot be enabled. Widening it is an administrator's decision and nobody else's: a reseller narrows what their customers get by editing a package, and can never widen what your machine allows.

Opening it

1. Go to Servers and open the machine.
2. Under Quick actions, choose Set up the PHP policy.

Or go straight there:

https://panel.example.com/nodes/stck1.example.com/php-policy

What a node starts with

A fresh node carries eleven directives — the ones hosting customers actually ask for, at ceilings a shared machine can carry:

corectl php policy show

PHP POLICY (/etc/corecp/php-policy.yaml)

DIRECTIVE                        SCOPE    BOUND
display_errors                   request  On | Off
error_reporting                  request  E_ALL | E_ALL & ~E_DEPRECATED | …
max_execution_time               request  max 600
max_input_vars                   request  max 20000
memory_limit                     request  max 512M
opcache.max_accelerated_files    pool     max 100000
opcache.memory_consumption       pool     max 512
post_max_size                    request  max 512M
session.save_handler             pool     files | redis | memcached
session.save_path                pool     starts with tcp:// or redis:// or unix://
upload_max_filesize              request  max 512M

extensions: apcu, igbinary, imagick, memcached, opcache, redis

The three kinds of bound

A directive has exactly one, and the machine reads exactly one — a ceiling beside a value list would never be consulted, so the form makes you pick.

The third exists for one reason. The pair session.save_handler / session.save_path is in the customer set so that redis sessions are possible, and a path on your machine must never be one a customer may type. The prefix bound keeps it a session store URL and nothing else.

Scope is a fact, not a choice

request means PHP reads the value per request. pool means it is read once, when the interpreter starts — everything opcache, and the session handler. A pool-scope value is the same for every website of one account on one PHP version, and the screen says so under the field on the customer's side.

Getting this wrong is a silent failure: an opcache setting applied per request arrives after the memory it configures has already been allocated.

Adding or changing a directive

Click Add directive, or click a row to change one.

# a ceiling
corectl php policy set memory_limit --scope request --max 512M

# a value list
corectl php policy set display_errors --scope request --values "On,Off"

# free text held to a shape
corectl php policy set session.save_path --scope pool \
  --prefixes "tcp://,redis://,unix://" \
  --note "the session store, never a directory"

Every change reconciles the node immediately, so a narrowing takes effect now rather than at whatever the next change happens to be.

Narrowing, and what happens to websites that are over it

Take a directive out, or lower a ceiling under a value somebody already set:

corectl php policy unset max_input_time
corectl php policy set memory_limit --scope request --max 256M

At the reconcile that follows, the value stops being rendered into any pool. The website's own record keeps it — so widening the policy again brings it back without anybody editing the site — and the website's PHP screen badges it Not active with the reason, rather than showing a setting that does nothing.

Extensions

The switches list what customers may enable. Allowing is not installing: only what the PHP builds on this machine ship can actually be loaded, and a switch for a module no build has is marked as such.

corectl php policy ext-allow redis
corectl php policy ext-deny imagick

Denying one restarts the pools that had it, without it.

What no policy may contain

Ten directives are refused outright, on the node, from this screen and from the command line:

open_basedir, disable_functions, disable_classes, sys_temp_dir,
upload_tmp_dir, error_log, extension_dir, include_path,
auto_prepend_file, auto_append_file

The first three are the isolation of an account written down — PHP itself only lets open_basedir be tightened, never widened — and the rest name a place on your machine. All of them are rendered from the account's own home directory by the reconcile, and none of them is a customer's to move.

corectl php policy set open_basedir --max 1G
# open_basedir is never a customer setting on a shared node: it is the
# isolation of an account …

Packages are the other half

A plan can be stricter than the machine, per directive, through the settings registry (php.max.memory_limit and its siblings). The effective ceiling for a website is the stricter of the two, and the panel always names which of them it was. See Packages and limits for the plan side.

Checking your work

# the file, as the node reads it
corectl php policy show --json | jq .directives.memory_limit

# what one website actually gets
corectl php override list example.nl

# and that a second reconcile changes nothing
corectl reconcile && corectl reconcile