This tutorial shows you how to install the CLI, PHP-FPM, and common extensions from Ubuntu repositories. It targets PHP 8.3 on Ubuntu 24.04 and uses explicit commands, runnable examples, verification steps, and production-safe defaults. You will finish with a result you can inspect rather than a code fragment that only looks plausible.
The primary focus is install PHP 8.3 on Ubuntu 24.04. The important engineering concerns are APT package selection, CLI and FPM configuration separation, enabled extensions, and service verification. Commands that change packages or services use sudo; application code should run as an unprivileged user.
Table of Contents
Prerequisites
- Ubuntu 24.04 LTS with current package metadata.
- PHP 8.3 CLI; PHP-FPM where the tutorial serves web traffic.
- A normal user account and
sudoonly for package or service administration. - A disposable project directory and a terminal.
- Composer when third-party packages are required.
cat /etc/os-release
php --version
php --ini
php -mConfirm that the CLI reports PHP 8.3 and note the loaded configuration file. PHP CLI and PHP-FPM have separate SAPIs and may load different php.ini files. Never assume that changing the CLI configuration also changes web requests.
How to Install PHP 8.3 on Ubuntu 24.04
Create an isolated working directory and keep generated files, secrets, dependency directories, and runtime data out of source control. Inspect every command before running it on a production host.
mkdir php-lab
cd php-lab
printf "vendor/n.envnvar/n" > .gitignore
php -v
php -m
<?php
declare(strict_types=1);
final readonly class ServerStatus {
public function __construct(public string $name, public bool $healthy) {}
}
$status = new ServerStatus('api-1', true);
echo json_encode($status, JSON_THROW_ON_ERROR | JSON_PRETTY_PRINT);sudo apt update
sudo apt install -y php8.3-cli php8.3-fpm php8.3-common php8.3-curl php8.3-mbstring php8.3-xml php8.3-zip
php -v
php -m
systemctl status php8.3-fpm --no-pager
Run commands one block at a time. A zero exit status is useful, but it is not sufficient verification. Inspect the output, resulting files, HTTP response, service state, or database rows that the step is intended to change.
How the Implementation Works
Install the CLI, PHP-FPM, and common extensions from Ubuntu repositories requires attention to APT package selection, CLI and FPM configuration separation, enabled extensions, and service verification. Keep input conversion close to the boundary, keep business rules in named functions or classes, and make side effects such as files, network calls, sessions, and database writes explicit.
PHP 8.3 supports strict, readable application code, but strict types do not validate external input automatically. Convert request, file, environment, and database values at a clear boundary before passing them into typed functions. Keep examples small enough to understand and complete enough to execute.
Use the CLI linter before running a changed file, enable full error reporting in development, and keep display_errors disabled in production. Treat warnings and deprecations as maintenance signals rather than hiding them.
Use declare(strict_types=1); in application files to make scalar calls from that file follow strict typing rules. It is not a validation framework: JSON values, form fields, headers, environment variables, and database results still require validation and conversion. Return useful errors at the boundary and keep internal exceptions out of public responses.
Names should explain intent rather than mechanics. Keep functions short enough that inputs, outputs, and failure behavior are visible. Avoid mutable global state because it makes request handling, tests, workers, and concurrent execution harder to reason about.
Verify the Result
- Lint every changed PHP file with
php -l. - Run the example with full development error reporting.
- Check the expected output or state, not merely the process exit code.
- Repeat with invalid, empty, boundary, and unauthorized input.
- Inspect logs and confirm that secrets and personal data are absent.
php -l app.php
php -d error_reporting=E_ALL -d display_errors=1 app.phpAdapt the filename to the example. For HTTP tutorials, verify status, headers, content type, and body with curl -i. For services, inspect systemd or container logs. For database work, query the durable state after both success and forced failure.
Common Errors and Fixes
The CLI and web page report different PHP versions
Check php --version, php --ini, the active PHP-FPM service, and the Nginx or Apache upstream. Restart or reload only after configuration validation. Remove temporary phpinfo() pages because they expose environment and module details.
Class, function, or extension not found
Run composer dump-autoload for project classes, verify PSR-4 case and paths, and inspect php -m for extensions. Remember that CLI and FPM can load different extension configuration.
The example fails even though the syntax is valid
Syntax validation cannot detect invalid credentials, unavailable dependencies, permissions, incorrect data, or application logic errors. Read the first exception and its previous cause, reproduce the smallest failing input, and inspect the boundary involved.
Topic-specific failure
Package not found usually means the Noble repositories are incomplete or the package index is stale. A CLI/FPM version mismatch means different binaries or configuration trees are active.
Production and Security Checklist
- Use Ubuntu-supported PHP 8.3 packages and apply tested security updates.
- Commit
composer.lockfor applications and deploy withcomposer install, not an unreviewed update. - Run PHP-FPM and application processes without root privileges.
- Keep credentials outside the repository and restrict their filesystem permissions.
- Disable
display_errorsin production and send structured errors to protected logs. - Validate input, parameterize SQL, escape output by context, and enforce authorization on every protected object.
- Set request, upload, execution, memory, and upstream timeouts deliberately.
- Back up durable data and test restoration before a risky upgrade or schema change.
- Monitor latency, errors, saturation, worker count, restarts, and dependency health.
- Document deployment, health verification, and rollback commands.
Frequently Asked Questions
Does this tutorial require PHP 8.3?
The commands and examples target PHP 8.3 on Ubuntu 24.04. Many language examples also work on nearby supported releases, but package names, defaults, and library requirements can differ.
Should I enable strict types?
Yes for new application code when the team understands the boundary rules. Strict types improve function contracts, but external values still need explicit validation and conversion.
Can I run the PHP development server in production?
No. The built-in server is for local development. Use a maintained web server or reverse proxy with PHP-FPM, TLS, resource controls, logging, and a supervised service.
How should I debug a blank page?
Check the HTTP status and PHP-FPM/web-server logs. Enable detailed display only in an isolated development environment. Production responses must not reveal stack traces, credentials, paths, or configuration.
How do I know the result is production-ready?
Production readiness requires automated tests, static analysis, dependency auditing, secure configuration, monitoring, backups, capacity limits, deployment validation, and a tested rollback—not only a successful local example.
Conclusion
You now have a repeatable path for install PHP 8.3 on Ubuntu 24.04. Keep the implementation explicit, test both success and failure, and promote the same reviewed artifact through environments. The strongest PHP systems are not defined by clever syntax; they are defined by predictable behavior, narrow permissions, useful observability, and safe recovery.
