Release notes

What changed in each release, and what it means for a machine you already run. For the full command reference see the docs.

Currently published v1.0.2-b74 Download

v1.0.2

2026-08-21

Per-service PHP configuration, a self-upgrade command, and a deploy that stops reloading php-fpm when nothing changed.

Per-service PHP settings

A php service with its own pool can now configure itself, in two files inside its own tree: .wor/php.ini for PHP ini settings (memory_limit, upload sizes, timezone) and .wor/php-fpm.ini for the pool's process manager (pm, pm.max_children and friends). No more editing the host's php.ini and hoping no other site minded.

WOR reads these files; PHP does not. A PHP-FPM pool cannot include a php.ini of its own, so WOR parses them and renders directives into the service's pool config — which php-fpm -t validates before anything reloads. A value php-fpm rejects rolls the pool back to exactly what it was, so one bad setting cannot take down the other services sharing that master. Only an allowlist of keys is accepted, and a key outside it is an error rather than a skipped line.

wor service reload

Applies those files on their own: re-renders the pool, validates it, reloads php-fpm and prints what is now in force — without reinstalling dependencies, rebuilding or restarting the service.

Configuration only. Restarting a process is still wor service restart and re-rendering a vhost is still wor host reload. It is also the only way to apply these files to a service whose source is not a git repository, which wor deploy requires.

Deploy no longer reloads php-fpm for nothing

wor deploy re-renders a pooled php service's config on every deploy, so an edit to either settings file ships with the code that needs it. But it now skips the write and the reload entirely when the result would be identical to what is already on disk.

Reloading the shared php-fpm master cycles the workers of every other service under it. A deploy that only changed code has no business doing that.

Settings that were never applied are now visible

wor info lists what each service asks for. wor diagnose and wor health warn when the running pool no longer matches those files — edited and never applied — or when a file no longer parses, which would fail the next deploy.

All three are read-only and never ask for sudo: a pool file they cannot read is reported as unchecked, never as wrong.

wor upgrade

Compares the running binary against the release this site publishes, shows you both, and installs the newer one once you confirm. --yes skips the confirmation.

Installation is handed to the install.sh inside the downloaded archive rather than reimplemented, so there is only one tested install path. Not available on Windows.

wor service chown

Hands one service's files back to the operator account, or to a user you name — for a tree left owned by root, by a CI rsync, or by an admin who is not the operator.

It changes the owner only, never the group, and re-grants the php-fpm pool afterwards. Rewriting the group would revoke the pool's access to the very files it has to read.

wor source clone asks about .wor

A clone replaces the service's whole tree, and the backup it takes first honours .gitignore — so a gitignored .wor could be lost with no copy anywhere. It now asks first: keep the current one (the default) or take the repository's.

Committing .wor to your repository is the tidy way to version this configuration alongside the code.