Install PHP Ledger on shared hosting or cPanel
A compatible shared-hosting account needs more than a PHP selector. Verify its database, .htaccess support, file boundary and recovery process.
What should you ask the provider first?
Ask about the exact account’s controls, because panel software availability does not establish plan compatibility.
Before buying or changing a hosting plan, send a short requirement list: PHP 8.3 for web requests; the package extensions; MySQL 8.0.19+ (8.4 recommended) or MariaDB 10.4+, with InnoDB; permission to create tables, triggers and views; Apache or LiteSpeed with .htaccess rules allowed, or a document root you can point at www/phpledger/public; and a private writable session directory. Terminal or SSH access is optional; it helps with command-line recovery. A salesperson saying PHP applications are supported has not answered those questions.
Keep the provider’s response with the installation record. If a control needs administrator help, establish who performs that change and how long it normally takes. For example, a customer may select only PHP versions already installed by the server administrator. The panel product supporting a version does not mean your plan exposes it. A separate database service may also differ from the software running on the web server.
How do cPanel and Plesk differ from a complete hosting promise?
Both panels expose server controls, but the operator decides which versions and permissions your account receives.
| Control | cPanel route to investigate | Plesk route to investigate |
|---|---|---|
| Web PHP | Domain PHP selection and installed EasyApache packages | Domain PHP settings and installed handlers |
| CLI PHP (optional) | Terminal access and the chosen executable | SSH access and the chosen executable |
| Database | Server version and user privileges | Server version and user privileges |
| Public root | Domain/subdomain document-root setting | Domain hosting document-root setting |
| Recovery | Backup contents, retention and restoration access | Backup contents, retention and restoration access |
The official documentation reviewed on 16 September 2026 describes panel capabilities, not a completed installation on every host. Use the dated availability table for the original research and its limits. This guide does not endorse a provider or claim that a plan bearing either panel brand has passed PHP Ledger acceptance.
Step 1: upload the verified folder
Unzip the verified package on your computer and upload the single phpledger folder it creates into your website.
Download the release ZIP and its checksum from the download page. Use the packaged archive with dependencies, not a repository source snapshot that lacks vendor files. Verify the checksum before unpacking. Rename the folder now if you want a different address, because its private settings store absolute paths. Upload it with the File Manager or FTP, for example to public_html/accounts. Never unzip a new version over an older installation, and retain the earlier package for recovery.
The package-root .htaccess sends requests to www/phpledger/public and refuses every private path, and the package-root index.php refuses to start if the server ignores those rules. If the panel lets you choose a (sub)domain’s document root, pointing it at www/phpledger/public is the most secure layout. Do not move internal files into public or change the package layout; that can break resource paths. Confirm that includes, install, tools and vendor cannot be fetched directly, while public CSS, fonts and the front controller remain reachable.
Step 2: select and verify the runtime
Select a supported PHP handler for the domain. The browser installer reports the version and extensions it finds; with terminal access, you can also check the command-line binary.
php -v
php -m
php www/phpledger/install/preflight.phpRun these optional commands from the package root after configuring the database. If bare php resolves to an older version, ask the provider for the correct executable path and substitute that path consistently. Do not guess a cPanel or Plesk filesystem path from another server. The host may install multiple handlers, use a different operating system or restrict shell commands. Record the verified binary and avoid depending on a default that can change without notice.
Compare the CLI output with the PHP handler configured for the domain. Sessions, extensions and limits can differ between them. A successful CLI migration followed by a web fatal error often points to that mismatch. Investigate the actual error privately; do not publish a full configuration dump or disable the package’s platform checks to make the error disappear.
Step 3: provision the database and private settings
Use a dedicated database and account, and verify view/trigger rights before applying the schema.
Create an empty application database on a supported MySQL or MariaDB server. Assign a dedicated account rather than reusing credentials shared with unrelated websites. Installation requires schema-changing privileges scoped to this database. A host may withhold those privileges on low-cost plans; if so, arrange an operator-assisted installation or select another plan. Do not change the migration statements to fit a restricted account. Their checks and triggers protect posted history.
The browser installer writes the private configuration for you, or offers it as a protected download to place with the hosting file manager. For CLI setup instead, copy the package’s config.local.example.php to config.local.php inside includes and edit the private copy. Supply the actual host, port, database, user and unique nonempty password. Configuration values in that file override environment values, so an old file can silently target an unintended database. Check the effective destination privately. Restrict file access to the operator and PHP process; neither configuration nor OAuth keys belong in the public directory.
Which environment should the hosted installation use?
Set PL_ENV=production for both web and CLI PHP, and leave hosted-demo mode disabled.
Apply the environment through the server or hosting provider’s private configuration mechanism. Do not copy development credentials or the public demo’s reset scheduler into customer hosting. Confirm the effective setting before installing. The optional read integrations need their separately documented public URL and private OAuth-key setup; ordinary browser installation does not configure those automatically.
Step 4: install with explicit success checks
Open the folder’s address in a browser straight after uploading; the installer starts by itself.
It checks the prerequisites, confirms through the site’s own address that private files cannot be downloaded, then asks for the database details. With the database on the same server (localhost) no setup key is needed. A database on another server needs the one-time code the installer writes to www/phpledger/storage/installation/setup-code.txt; read it with the file manager. Until setup completes, anyone who reaches the address with a database on the same server could claim it, so do not leave a fresh upload waiting. Operators who prefer the command line can run these checks instead, each only after the preceding command succeeds:
php www/phpledger/install/preflight.php
php www/phpledger/install/migrate.php
php www/phpledger/install/preflight.phpThe first check should identify a recognized empty or pending schema. The migration command applies the supplied chain. The final check should report current schema. Stop on a nonzero status, unknown receipt, checksum mismatch or interrupted migration. Repeating a normal successful installation skips matching receipts; deleting a failed receipt is not a supported recovery procedure. Keep the command outcome and package identity without recording secrets.
Create the owner account with a username, email address and password; the owner can sign in with either, and a logo is optional. The CLI path uses the package’s stdin password procedure instead. Do not place a password in a command argument, support ticket or screenshot. Creating the sign-in account and configuring a company are separate steps. For a fresh fictional company, select dates and functional currency deliberately. Existing businesses require the opening-balance process; do not label an established business as new merely to get past a readiness gate.
Step 5: verify the restricted runtime and recovery
Test normal use after privileges are restricted and preserve the account that defines the effective-source views.
The two source views added in 0.3.0 use the account that ran migration 016 as their definer. A provider who removes a temporary installer account can leave those views unable to execute. Agree on a stable dedicated migration account and verify view reads using the actual web account. The same issue matters when a backup is restored under a different database name. Test the restored view definitions, dependencies and results, not just the presence of their names.
Sign in over HTTPS, record fictional receipt and expense entries, follow their journals and compare the trial balance. Check session retention, direct navigation and unavailable private paths. Then rehearse a database/configuration/application restore separately. A panel’s backup-completed label does not establish that its archive includes triggers, views and a compatible package, or that the person on call can restore them.
When is shared hosting the wrong choice?
Choose a managed VPS or another service if required database, .htaccess or recovery controls are unavailable.
What should you do next?
Shared hosting can be a sensible operational arrangement when the provider supplies the required controls and you understand the restrictions. It is a poor fit when support cannot identify the database version, explain restore behavior or permit the public-root boundary. It is also the wrong application choice when you need a regional filing connector, multiple stock locations or reviewed country tax rules immediately. Those gaps are independent of the hosting platform.
Questions before you continue
Check these boundaries before applying the procedure to a business installation.
Can I upload everything into public_html?
Yes. Upload the phpledger folder into public_html or a subfolder such as public_html/accounts. On Apache or LiteSpeed the package-root .htaccess keeps every folder except www/phpledger/public private. Do not move files out of the folder or change its layout.
What if my hosting plan has no terminal?
Setup runs in the browser, so no terminal is needed. Upload the folder, create the database in the panel and open the folder’s address. Terminal access only helps with the alternative CLI setup and expert recovery.
Sources and next steps
Technical references and project behavior were checked on 16 September 2026; hosting access remains plan-specific.
- Package installation instructions
- Package upgrade and recovery instructions
- cPanel PHP and MultiPHP documentation
- cPanel terminal availability
- Plesk installable PHP versions
The linked project files describe the current release. 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.
