php.ini settings

Settings are edited per PHP version, not per site, because one php-fpm pool serves every site on that version.

rex php settings 8.3
rex php settings 8.3 set memory_limit=512M
rex php settings 8.3 set upload_max_filesize=64M

The app has the same editor on each version’s card in Settings.

Changing one restarts the pool

A set restarts that version’s php-fpm pool so the change takes effect — and every site on that version briefly restarts with it. Expected, quick, and worth knowing before you do it with a long request in flight.

The list is a whitelist

Six directives, and that is the whole list

memory_limit, upload_max_filesize, post_max_size, max_execution_time, max_input_time and max_input_vars. Nothing else is editable here.

Directives that would break the pool, contradict how rexenv wires php-fpm, or silently disable something the app depends on are not offered. A setting that can only produce a broken pool is not a choice. For anything outside the six, use the per-site alternatives below.

The defaults are rexenv’s, not PHP’s

Every one of the six is written into the pool whether or not you have set it, so an untouched PHP version runs these rather than PHP’s compiled numbers:

Setting	rexenv	PHP
memory_limit	1G	128M
upload_max_filesize	5G	2M
post_max_size	8G	8M
max_input_vars	5000	1000
max_execution_time	60	30

The sixth, max_input_time, defaults to -1, which means “use max_execution_time”. nginx’s global body limit is derived from the same defaults — the larger of upload_max_filesize and post_max_size — so an untouched version is not refused with a 413 on a body PHP would take.

Your own value always wins; clearing a field in Settings → Services → PHP versions → ini settings puts the default back, and the field shows it as its placeholder. On the CLI an unset key reads (default: 1G). Shipped in 0.8.2 — before it, an unset key ran PHP’s number, and the defaults reach every pool rexenv starts, existing sites included.

The usual ones

Setting	Why you would raise it
memory_limit	Large imports, page builders, WooCommerce with many extensions
upload_max_filesize	Media uploads failing at the WordPress level
post_max_size	Must be ≥ upload_max_filesize, or uploads fail confusingly
max_execution_time	Long imports and migrations
max_input_vars	Large menus, forms and importers dropping fields silently

`post_max_size` is the one people miss

Raising upload_max_filesize alone does nothing if post_max_size is lower — the upload fails with an unhelpful message, because PHP discards the whole request body before WordPress sees it. rexenv refuses the pair rather than storing a setting that would lie: upload_max_filesize (64M) exceeds post_max_size (8M) — PHP caps uploads at post_max_size, so raise post_max_size too. Its own defaults keep the order.

Two limits worth knowing before you tune

• A request is recycled after 5 minutes of wall clock unless you raise max_execution_time past it: php-fpm’s request_terminate_timeout is the larger of your value and 300s, and max_execution_time = 0 still gets the 5-minute guard. Every default site shares one pool, so workers stuck on a heavy import or a loopback self-request starve every site at once — on a port that still accepts, so no probe sees it.
• A FrankenPHP override site ignores all of this. It serves with its own embedded PHP, and the only ini line rexenv writes into a FrankenPHP backend is the mail catch-all’s sendmail_path. An Apache override site does run these: Apache hands .php to the same shared php-fpm pool over FastCGI.

Per-site alternatives

For something genuinely per site rather than per version:

• Per-site environment variables, in the site’s settings or rex site env.
• ini_set() in the application, for anything settable at runtime.

php_value in .htaccess is not one of them, even on the Apache override: PHP runs as a FastCGI pool rather than inside Apache, and mod_php is not among the modules rexenv loads for a site.

Checking what is live

The site’s Terminal tab:

php -i | grep memory_limit

That reads the CLI’s ini rather than the pool’s, so for the value the web request actually sees, use a phpinfo() page or check the site’s Environment card in the app.