Free tools Windows power users keep installed
One-click scans. No signup required.
Upgrade PHP on an Ubuntu VPS as a staged runtime migration, not a single package command: identify the Ubuntu release and every PHP execution path, make a restorable backup, install the target runtime with matching extensions, switch Apache or Nginx deliberately, test both CLI and web requests, then observe traffic before removing the old version.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
On Ubuntu 24.04 LTS (Noble), the distribution repositories provide PHP 8.3 packages, including php8.3 and php8.3-fpm; the generic php-fpm metapackage resolves to the 8.3 FPM line in the Noble package index used for this guidance. The exact package versions can change through updates, so verify them with APT on your server.
As an Amazon Associate I earn from qualifying purchases.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 111. Define the migration before touching packages
A VPS can run several PHP runtimes at once. The command-line interpreter used by cron or a deployment job may differ from the PHP-FPM service serving Nginx, and Apache may load a separate module. Start by writing down the version you want, the application’s supported PHP range, and the point at which you will switch production traffic.
Identify Ubuntu, PHP, and the active SAPI
lsb_release -a || cat /etc/os-release
php -v
php -m
php --ini
apt policy php php-fpm
systemctl list-units --type=service 'php*-fpm.service'
php -v and php -m describe the CLI SAPI only. php --ini shows which configuration files that CLI process reads. List FPM pools and their per-version configuration as well:
#1 Best Overall
ls -la /etc/php/*/fpm/pool.d/
find /etc/php -maxdepth 3 -type f | sort
Check which web server is active and whether it uses an Apache module, Apache proxying to FPM, or Nginx:
systemctl is-active nginx
systemctl is-active apache2
systemctl --type=service | grep -E 'nginx|apache2|php.*fpm'
Record every place that invokes PHP: web requests, cron entries, systemd timers, queue workers, deployment hooks, backup scripts, and supervisor-managed processes. A site can appear healthy in a browser while a queue worker still runs the old interpreter.
Recommended Free Tools
Inventory extensions and application constraints
Save the enabled module list and compare it with the application’s requirements. Typical web applications may need database, XML, multibyte-string, cURL, and ZIP support, but installing every available extension increases maintenance surface and can introduce conflicts.
php -m | sort
php -r 'echo PHP_SAPI, " ", PHP_VERSION, PHP_EOL;'
Check the project’s declared PHP range and extension requirements in its dependency manifest. For Composer projects, run the dependency checker in a staging copy before production:
composer check-platform-reqs
Do not assume that a package named php-foo will follow the target version when multiple PHP lines are installed. Prefer explicitly versioned packages such as php8.3-foo when they are available for your Ubuntu release.
2. Back up and rehearse a recovery
Create a VPS provider snapshot or another restore point before changing packages. Separately back up databases, uploaded files, application secrets, and deployment artifacts. A snapshot that cannot be restored is not a rollback plan, so perform a restore test on a disposable instance or document and verify the provider’s recovery procedure.
Save the configuration and package state so you can reproduce the old setup:
sudo tar -czf php-vps-config-$(date +%F).tar.gz /etc/php /etc/nginx /etc/apache2
dpkg-query -W -f='${binary:Package}t${Version}n' | sort > package-list-$(date +%F).txt
sudo systemctl list-unit-files 'php*-fpm.service' > php-services-$(date +%F).txt
Remove the leading space before dpkg-query if your shell treats it specially; the command itself does not require elevated privileges. Store the resulting files outside the VPS as well as on it. Note the current FPM socket, pool user, document root, PHP configuration overrides, and any local package repository or pinning rules.
3. Choose an upgrade route
There is no universally safest route. The right choice depends on how much rollback time you need, whether the required extensions exist in Ubuntu’s repositories, and who will provide security updates.
| Decision | Advantages | Risks and checks |
|---|---|---|
| Native Ubuntu packages | Integrated dependency handling and security updates through Ubuntu’s package channels. | Target versions and extensions are constrained by the Ubuntu release; confirm that the application’s requirements are available. |
| Separately maintained PHP repository | May offer a newer or broader set of PHP builds when the distribution does not. | You add another security-update owner and a different upgrade policy. Verify repository trust, support for your Ubuntu release, and extension coverage before production use. |
| Apache module | Simple for a site already using Apache’s distribution PHP module. | Apache loads one module version for the relevant virtual hosts. Module changes can affect all sites on that server. |
| PHP-FPM behind Apache or Nginx | Separate pools and sockets allow parallel versions, per-site users, and a controlled cutover. | You must update the proxy or fastcgi_pass socket and monitor both the web server and FPM service. |
| In-place replacement | Fewer packages and less disk usage. | Rollback is harder if the new runtime breaks the application or a required extension is unavailable. |
| Parallel installation and cutover | The old runtime can remain available while the new one is tested; switching a socket or pool is reversible. | Uses more disk and can leave cron or workers pointed at the wrong version unless you audit every invocation. |
| PHP-only change | Limits the change set and makes failures easier to attribute. | It does not upgrade an end-of-life Ubuntu release or repair unrelated operating-system issues. |
| Full Ubuntu LTS upgrade | Moves the operating system and its supported PHP baseline together. | It is a larger migration with its own service, repository, and configuration risks. Do not combine it with a PHP-only change accidentally. |
Keep the Ubuntu release upgrade separate unless that combined migration is your explicit, tested plan. Ubuntu 24.04 LTS receives standard security maintenance until 31 May 2029; Ubuntu Pro and its Legacy add-on can provide longer coverage.
4. Refresh APT and simulate the package transaction
Refresh the local package index before inspecting or installing packages:
sudo apt update
apt policy php8.3-cli php8.3-fpm php8.3-mysql php8.3-xml php8.3-mbstring php8.3-curl php8.3-zip
The policy output shows which candidate version and repository APT will use. If a package is unavailable, stop and resolve the repository or Ubuntu-release issue rather than substituting an unversioned package blindly.
Simulate the install to expose removals, held packages, or dependency changes:
sudo apt-get -s install php8.3-cli php8.3-fpm php8.3-mysql php8.3-xml php8.3-mbstring php8.3-curl php8.3-zip
Review the simulation carefully. A PHP migration should not unexpectedly remove the web server, database client libraries, or application-critical extensions. Resolve held or broken packages before proceeding:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →apt-mark showhold
sudo apt --fix-broken install
Run the repair command only when APT reports a broken state, and inspect its proposed changes before accepting them.
5. Install the target PHP runtime and required extensions
Install a matched set for the target version. This example uses PHP 8.3 on Ubuntu 24.04; substitute the version and package names actually offered by your Ubuntu release:
sudo apt install php8.3-cli php8.3-fpm php8.3-mysql php8.3-xml php8.3-mbstring php8.3-curl php8.3-zip
Install only extensions the application needs. Common package names include database drivers such as php8.3-mysql, XML support through php8.3-xml, multibyte strings through php8.3-mbstring, HTTP clients through php8.3-curl, and archive handling through php8.3-zip. Names vary by Ubuntu release and PHP line; use apt search php8.3- and apt policy rather than guessing.
Installing a new CLI package does not automatically make Nginx serve it. Installing FPM does not change Apache’s loaded module. Treat each SAPI as a separate cutover.
6. Switch Apache deliberately
Apache with the PHP module
If Apache currently loads the distribution module, install the module package for the target version (the package may be named libapache2-mod-php or a versioned equivalent in your release). Identify the old and new module names before disabling anything:
apache2ctl -M | grep php
ls /etc/apache2/mods-enabled/ | grep php
Disable the old module and enable the new one using the names present on your host:
sudo a2dismod phpOLD
sudo a2enmod php8.3
sudo apache2ctl configtest
sudo systemctl reload apache2
Replace phpOLD with the actual module, such as php7.4; do not copy that placeholder literally. Ubuntu 24.04 release notes identify PHP 8.3.6 as the PHP package version at the 24.04 publication and note that PHP updates restart apache2. Plan for that restart and its brief connection impact, and confirm the installed package version rather than assuming it remains 8.3.6.
Apache proxying to FPM
If Apache is configured to use FPM, enable the proxy modules and the target FPM configuration supplied by your distribution, then validate the virtual-host configuration. The exact FPM configuration name is versioned, so inspect /etc/apache2/conf-available/ before enabling it:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemssudo a2enmod proxy proxy_fcgi setenvif
ls /etc/apache2/conf-available/ | grep php
sudo apache2ctl configtest
sudo systemctl reload apache2
Confirm that the virtual host’s proxy target references the new FPM socket or pool. A successful Apache reload proves syntax only; it does not prove that the application is executing on the intended PHP version.
7. Switch Nginx to the new PHP-FPM socket
Nginx does not execute PHP itself. It forwards dynamic requests to PHP-FPM, so the critical change is the socket or upstream in the relevant server block. Ubuntu’s PHP 8.3 FPM service commonly creates /run/php/php8.3-fpm.sock, but check the host rather than assuming:
Rank #4
systemctl status php8.3-fpm
ls -l /run/php/
grep -R "fastcgi_pass" /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null
Update the site configuration from the old socket to the actual new one:
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
If your configuration uses an upstream block or TCP address instead of a Unix socket, change that endpoint to the new pool according to the pool configuration. Validate before reloading:
sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status php8.3-fpm --no-pager
Keep the old FPM service and socket available during testing when disk space and package dependencies permit. This lets you point the server back to the previous socket without reinstalling packages.
8. Test compatibility before production cutover
PHP 8 removes deprecated functionality that existed in PHP 7.4, and PHP’s migration guidance documents new features alongside incompatibilities. A clean package installation is therefore not evidence that the application is ready.
Run automated and staging checks
- Run the complete application test suite on the target runtime.
- Run Composer dependency checks and update the lock file only through your normal dependency-review process.
- Restore a recent database backup into a staging copy and run migrations there first.
- Exercise representative CLI commands, queue workers, import/export jobs, and scheduled tasks with the target
phpbinary. - Test authentication, authorization, file uploads, image or document processing, outbound HTTP calls, email, payments, and any integration that uses a PHP extension.
- Check error logs for deprecation notices, fatal errors, missing classes, and permission failures under the FPM pool user.
Run a representative CLI job explicitly with the target binary when multiple versions exist, for example:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
/usr/bin/php8.3 path/to/your-job.php
Use your application’s real entry point instead of the illustrative path. Ensure cron and worker definitions are updated only after the staged tests pass.
9. Verify the runtime that users actually receive
Verify CLI, FPM, and the web request separately. First confirm the installed modules and service state:
php8.3 -v
php8.3 -m | sort
systemctl is-active php8.3-fpm
journalctl -u php8.3-fpm -n 100 --no-pager
Then expose a temporary diagnostic endpoint through the application or a protected test location. A minimal phpinfo() page can show the served PHP version, SAPI, loaded configuration file, and modules, but it reveals sensitive environment details. Restrict access, check it once, and delete it immediately after verification. A safer application-owned health endpoint can report the PHP version without publishing full configuration.
Best Value
Inspect the web-server access and error logs while making a request:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →sudo tail -f /var/log/nginx/error.log /var/log/php8.3-fpm.log
sudo tail -f /var/log/apache2/error.log
Use only the log paths that exist on your host. Confirm that the response is generated by the target FPM pool or Apache module, not merely that the page returns HTTP 200.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.10. Cut over, observe, and keep rollback available
After tests pass, reload the relevant service, update workers and cron definitions in the same maintenance window, and watch normal traffic. Keep the VPS snapshot, database backup, and old package configuration until the application has completed a normal traffic period that includes scheduled jobs and background work.
Monitor:
- HTTP 5xx rates, latency, and upstream timeout counts.
- PHP-FPM pool saturation, process limits, and slow requests.
- Application logs for type errors, removed APIs, and extension failures.
- Queue depth, failed jobs, cron exit codes, and payment or email callbacks.
- Disk usage and memory pressure after both runtimes have been installed.
Do not delete the old runtime immediately after the first successful page load. A compatibility problem may appear only in a nightly report, a weekly queue, or a rarely used administrative screen.
11. Roll back safely when a check fails
Rollback should reverse the traffic switch first, not begin with random package removal. For Nginx, restore the previous fastcgi_pass socket, run sudo nginx -t, and reload Nginx. For Apache, re-enable the previous module or FPM proxy target, run sudo apache2ctl configtest, and reload or restart according to the service’s normal procedure.
Stop or redirect workers that were changed to the new binary, then restore the database or files only if the failed migration modified data in a way the application cannot safely use. If configuration or package state is inconsistent, restore the VPS snapshot rather than layering more ad-hoc changes. Record the failing request, stack trace, extension, and package versions before retrying; that evidence identifies whether the issue is application compatibility, an unavailable extension, a pool permission problem, or a web-server routing mistake.
12. Remove obsolete packages only after the stability window
Once production has passed the agreed observation period and rollback artifacts are retained, identify what is still using the old version:
grep -R "php7|php8.1|php8.2" /etc/cron* /etc/systemd /etc/supervisor 2>/dev/null
systemctl list-units --type=service 'php*-fpm.service'
Replace the example version patterns with the versions actually present. Confirm that no virtual host, worker, deployment hook, or cron job still depends on the old runtime. Then remove obsolete packages in a separate maintenance step, previewing the transaction first:
sudo apt-get -s remove phpOLD-cli phpOLD-fpm
sudo apt remove phpOLD-cli phpOLD-fpm
sudo apt autoremove
Do not run autoremove without reviewing its proposal; it can remove packages that another application still needs. Keep configuration files until you are certain they are no longer useful for rollback or audit.
Common failure symptoms and targeted fixes
| Symptom | Likely cause | First checks |
|---|---|---|
| Browser shows “502 Bad Gateway” after an Nginx change | Nginx points to a nonexistent socket, or the FPM service is stopped. | Check ls -l /run/php/, systemctl status php8.3-fpm, and the Nginx error log; correct fastcgi_pass. |
| CLI reports the new version but the site reports the old one | CLI and web SAPI use different runtimes. | Check the FPM socket or Apache module and verify with a protected diagnostic endpoint. |
| “Class not found” or missing-function errors | An extension was not installed or enabled for the target SAPI. | Compare php8.3 -m with the application requirements and inspect FPM’s loaded configuration. |
| Apache fails to reload | Conflicting modules, invalid directives, or a proxy configuration error. | Run sudo apache2ctl configtest, inspect enabled modules and the journal, then restore the previous known-good module or proxy target. |
| Jobs fail while web pages work | Cron, systemd, or a worker still invokes the old binary or lacks the new extension. | Inspect command paths and service environments; run the job explicitly with the target binary and review its log. |
| APT proposes removing unrelated software | Dependency conflicts, held packages, or mixed repositories. | Stop, review apt-get -s output and apt-mark showhold, and resolve repository or package constraints before installing. |
Version and lifecycle considerations
Ubuntu 24.04’s release documentation recorded PHP 8.3.6 as the package version at launch and noted that PHP updates restart Apache. That historical version is not a promise about the package currently offered: apply security updates and verify the candidate with apt policy. The Noble repositories list the versioned PHP 8.3 CLI, FPM, and extension packages, while the unversioned php-fpm metapackage follows Ubuntu’s default FPM line.
If your VPS still runs Ubuntu 22.04 or an older release, check its repository contents and support window before choosing a target. Ubuntu’s 22.04 release notes specifically warned PHP 7.4 users to prepare for PHP 8 because deprecated functionality was removed. Moving from PHP 7.4 to PHP 8 is therefore an application migration as well as a package change; budget time for code fixes and dependency updates.
Quick Recap
A repeatable checklist
- Confirm the Ubuntu release, target PHP version, web server, SAPI paths, extensions, pools, workers, and application support range.
- Create and verify a VPS snapshot, database backup, file backup, and configuration/package inventory.
- Run
sudo apt update, inspectapt policy, and simulate the install. - Install the target CLI, FPM or Apache module, and only the required version-matched extensions.
- Point Apache or Nginx to the target runtime; validate configuration before reloading.
- Run automated tests, Composer checks, staging migrations, CLI jobs, and user-flow smoke tests.
- Verify the served runtime and modules, then remove any temporary diagnostic endpoint.
- Cut over workers and traffic, monitor a normal operating period, and retain rollback artifacts.
- Remove the old runtime only after confirming that no service or scheduled task still uses it.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
