PHP version compatibility for self-hosting

Which PHP version should you choose?

Use a patched PHP 8.3 runtime for the recommended path; PHP 8.2 remains the supported minimum.

The current package targets PHP 8.2 and later rather than requiring a newly released language version merely because it exists. That choice matters to self-hosters: control panels and shared hosts expose different runtime versions, and the command-line binary may lag behind the web selector. PHP compatibility therefore has three parts: what the project permits, what the host actually supplies and what the exact release has been tested against. Keep those answers separate when deciding whether an installation is supported.

The 0.3.0 foundation changes passed the full project checks on PHP 8.2.33 and 8.3.33 during release preparation. The repository also defines an 8.4 test lane; the existence of that lane alone should not be described as evidence that every later source revision was run on 8.4. Record the actual version and results used for your package. A language version being accepted by Composer is useful evidence, but it is only one part of installation acceptance.

How long are these versions supported upstream?

PHP publishes support dates by branch; use those dates to plan upgrades before a security-support deadline.

These are upstream PHP dates, not promises that a hosting provider will maintain a plan until that date. A provider may remove a selector earlier, offer vendor-maintained older packages, or require a plan change. Ask how patch updates and branch changes are delivered. Do not infer that an old branch is safe because it still appears in a panel. Conversely, changing branches immediately before a bookkeeping deadline creates an avoidable operational risk if it has not been rehearsed.

Plan a staging check before the current branch reaches the end of its security window. Retain a compatible application and database backup before changing the server. A PHP upgrade should preserve the application’s configuration and dependency lock assumptions. Review both the application preflight and the full hosting path afterward; command-line success alone does not verify the web worker’s extensions or session handling.

What do common hosting panels actually prove?

Panel documentation proves available controls, while the purchased account determines which controls you can use.

A historical provider announcement is not a current compatibility certificate. For example, a post about adopting PHP 8.2 explains an earlier change, but it cannot prove what your account runs today. The sources linked below were rechecked on 16 September 2026. Provider defaults can change after that date. Use them to frame questions, then inspect the actual account before buying or installing.

Database support remains a separate question. A panel can provide PHP 8.3 while its bundled database is MariaDB or an earlier MySQL release. PHP Ledger’s documented database target is MySQL 8.4 with InnoDB. Do not turn a successful PHP-version check into a claim that the entire hosting plan is compatible. Document-root control, terminal access and migration privileges are equally relevant.

How do you check web and command-line PHP?

Inspect the CLI directly and confirm the web handler through the host’s private administration controls.

php -v
php -m
php www/phpledger/install/preflight.php

Run these commands from the extracted package root using the intended CLI binary. If the provider exposes a versioned binary at another path, use that path consistently for preflight, migration and initial-user creation. A panel selector commonly affects only the web handler. A shell command named php may still point at another version. Keep the actual version output with the installation record without publishing configuration or credentials.

For the web runtime, inspect the selected PHP handler or pool through the panel or server configuration. Do not leave a public phpinfo page behind as a diagnostic shortcut: its output can reveal paths and environment details. Check that the same required extensions are enabled in both runtimes. A missing extension can cause a command or request to fail even when the displayed PHP branch is correct.

Which extensions and dependencies matter?

Use package preflight and locked dependencies together, because PHP version alone does not describe the runtime.

BCMath is part of the exact-money implementation. Required database, string and cryptography support must also match the package instructions. Read the complete extension list in INSTALL rather than guessing from another PHP application. A host may allow one extension in a web pool but omit it from the CLI build. Preflight provides a concrete check of the runtime executing it; it does not silently repair missing modules.

The customer ZIP contains production dependencies matched to the project lock file. Do not replace its vendor directory with files copied from an unrelated project or a local workstation using a different PHP floor. Developers rebuilding dependencies should use the lock file and verify platform requirements in the target runtime. Installing the newest available dependency versions during a production upgrade changes the artifact under review and can introduce compatibility differences unrelated to the application release.

What should you test before changing the runtime?

Rehearse the exact package with synthetic data and a restored database before changing a business installation.

1. Record the old and proposed PHP versions, extension lists and web handlers.
2. Restore a matched backup into an isolated environment.
3. Run package preflight and inspect existing source records and reports.
4. Exercise sign-in, a draft, a balanced posting and an allowed reversal.
5. Confirm private paths remain inaccessible and backups still complete.

Use a representative restored dataset without exposing customer records to public test routes. Confirm the intended company and book on every check. If a failure appears only under the new runtime, preserve its nonsecret error and identify whether it belongs to the extension set, configuration, dependencies or application. Repeatedly changing all four makes the result harder to diagnose.

A passing smoke check is bounded evidence. It does not prove tax compliance, accounting review, capacity or every browser workflow. State which commands and paths were checked, and retain the outcome with the release record. This is particularly useful when a provider later changes its default handler and someone needs to determine why behavior changed.

When should you choose another hosting plan?

Choose another plan if it cannot supply the complete supported environment and a predictable update process.

What should you do next?

A provider that offers only an older PHP branch, no matching CLI, or no supported database cannot satisfy this installation procedure simply by accepting PHP files. Obtain an operator-assisted arrangement or select another host. If your business needs functionality absent from the preview, a newer PHP version will not add it. Review product scope before spending time on server adjustments.

Questions before you continue

Check these boundaries before applying the procedure to a business installation.

Sources and next steps

Technical references and project behavior were checked on 16 September 2026; hosting access remains plan-specific.

• Package installation instructions
• PHP upstream support dates
• cPanel PHP availability
• Plesk PHP handlers
• Hostinger PHP selector
• SiteGround historical PHP 8.2 announcement

The linked project files describe the current preview. Follow the instructions inside your exact downloaded package if a later release changes a command. Technical testing does not establish statutory compliance or independent accounting acceptance. See the project and preview limits.

• Check the rest of the stack
• Inspect a panel-based hosting plan