Server maintenance

Reboot and service restarts

Restart Nginx, PHP-FPM, or an installed database engine from the Services list on a server's Overview. Reboot the whole server under Power in its Settings. Each returns a job you can follow. A restart is usually the right first step after editing configuration by hand.

PHP versions

PHP CLI, in a server's Settings, sets the default php on the command line, which Composer, cron and daemons use. You can pick any version a site on the server runs. The same section lists every PHP version Provisore manages and which of them a site on this server uses. Provisore tracks what the sites use, not which packages apt has installed.

You can remove a version once nothing uses it. Provisore refuses while any site runs on it or is being switched onto it, and while it is the server's default CLI version. The server refuses again if it still has a PHP-FPM pool for that version. To free a version, move or remove the sites that use it first.

Configuration files

Config files, in a server's Settings, opens the server's nginx.conf and, where PHP runs, its php.ini for editing. Each save is checked with nginx -t or php-fpm -t before the service reloads. Provisore keeps a timestamped backup of the previous file and puts it back if the check fails.

Drift

The app shows what Provisore has been asked to configure, so a daemon somebody stopped over SSH still shows as running. A drift check reads the server itself: systemd units, cron entries, firewall rules, and the default PHP. It lists every difference from Provisore's records, with the time it looked. Run it from Drift in a server's Settings, or with Check now on the Overview.

A check changes nothing, on the server or in Provisore's records. Resolve each difference with that resource's own controls. The records are what the next deploy applies, so a difference you leave alone is one the deploy may put back.

A server that has never been checked says so, rather than reporting no differences.

Drift also lists provisioning steps that have changed since the server was set up. The server still does what it was built to do, but not what a server built today would do. Re-apply provisioning rewrites the files those steps own and restarts Nginx and fail2ban, so requests can fail for a moment, and hand edits to those files are replaced. Running it a second time changes nothing more.

Removing a server

Delete a server's sites first, then remove it under Danger zone in its Settings. That frees a slot on your plan. A server you connected yourself keeps running as configured, because Nginx, systemd units, cron files, and your sites are all standard Ubuntu configuration. A server Provisore created on Hetzner is destroyed with everything on it, and Hetzner stops billing for it.