Choose your role

PHP Ledger for software houses: deployment and support boundaries

A client installation is an ongoing service responsibility. Review the release, recovery plan, access model and missing business workflows before offering it.

PHP Ledger uses PHP and MySQL in a lightweight modular application. Version 0.4.0 remains a development preview. Self-hosting gives control over the installation, but does not remove maintenance, accounting review or licence responsibilities.

What are you actually taking on?

You are taking responsibility for the application environment and support boundary you agree with the client, not just uploading files.

Clarify who updates the operating system and PHP, who manages the database, who checks backups and who responds when an operator reports a disputed balance. These tasks can belong to different people, but each needs an owner. An installation that works on delivery day can still fail the client if nobody maintains certificates, private storage or restore procedures later.

Separate technical support from accounting decisions. You can investigate why a request failed or a report differs from its expected fixture. An accountant should decide the appropriate treatment of a transaction, opening discrepancy or reporting policy. Neither role should silently inherit the other’s responsibility.

Which runtime facts must be verified?

Verify the exact PHP, extension, database and document-root requirements of the package you intend to install.

The current project requires PHP 8.2 or newer, with 8.3 recommended, and MySQL 8.4 with InnoDB. Required PHP extensions and installation instructions belong in the release package. A hosting panel advertising “PHP support” is not evidence that its database version, terminal access, writable private storage and web-root controls meet the whole profile.

Serve only www/phpledger/public. Configuration, dependencies, migrations and private files belong outside that document root. The historical application remains in Git history and must not be restored into the new runtime. Follow the requirements checklist and VPS guide rather than adapting an old upload recipe by guesswork.

How should you separate development, acceptance and live use?

Use distinct environments and explicit promotion decisions so fictional data and unfinished work cannot become client records accidentally.

1. Install the selected release in an isolated test environment.
2. Run the supplied checks and a client-relevant synthetic scenario.
3. Have the accountant review the expected accounting and cutover.
4. Rehearse backup and restore using that release.
5. Confirm the live scope, users and support ownership.
6. Publish only after the client’s authorised acceptance decision.

A passing build proves less than an observed workflow. A running container proves less than a usable application. A successful login proves less than a correct posting and recovery path. Keep evidence at the level of the claim you intend to make to the client.

What belongs in an upgrade plan?

Use a versioned release, a verified backup, a documented migration path and a recovery decision that accounts for database changes.

Do not overwrite a live installation with an arbitrary working tree. Review the release notes and preserve private configuration and keys. Schema changes require their own backup and upgrade evidence; reverting application files alone may not restore a compatible database. The backup and restore guide describes the questions an operator should answer before relying on a backup.

After an upgrade, check the routes and workflows actually used by the client. Inspect expected financial totals, access boundaries and any scheduled tasks. Retain the deployed version and migration receipts so a later support request can be tied to the real installation.

What integrations exist today?

The published integration layer provides scoped accounting reads using the existing users and company/book permissions.

The read API and MCP connection paths are useful for authorised reporting clients. They are not a general permission to post journals, send payments or accept generated accounting decisions. Use a separate named connection for each integration and keep its grant as narrow as the task requires. Review revocation and expiry rather than sharing an owner’s credential among unrelated jobs.

The retained outbound-event queue is a dispatch foundation with no enabled external transport or A75 connector. Creating a queue table does not establish delivery to a customer system. Any future connector needs its own configured destination, authentication, retry evidence and explicit activation.

How should extensions fit the architecture?

Use the existing service and access boundaries instead of building a parallel posting, authentication or database layer.

All financial modules should use the central posting path. A custom screen must not insert posted journal rows directly or bypass period checks. Keep financial decisions in small typed functions and preserve exact money rather than introducing floating-point calculations. An integration that calculates a second independent outstanding balance creates a reconciliation problem, even if its first demonstration looks correct.

Read the repository’s contribution guidance before developing an extension. Test the actual supported interfaces and keep compatibility claims bounded to the versions exercised. A useful client customisation includes its validation and upgrade obligations, not just its source code.

What licence information should you communicate?

Describe the published licence scope accurately and direct the client to the actual terms before making a contractual promise.

Current project-owned code and documentation use AGPL-3.0-or-later, and a separate commercial licence is available. Published 0.1.0 through 0.1.5 previews retain their original MIT grants. Dependencies, fonts, images and marks retain separate terms. The project’s licence-scope document is the primary project reference.

Do not promise rights beyond those terms or describe every historical 0.1.x release as MIT. If your business model depends on a particular redistribution, hosting or proprietary-extension arrangement, obtain the appropriate licence advice or agreement. This page is a deployment guide, not legal advice.

What should a support handover include?

Give the client enough information to identify the running version, obtain help and recover the service without exposing secrets.

• Installed version, document root and responsible operator.
• Where private configuration and backups are managed.
• Restore-test evidence and the agreed recovery process.
• User roles, integration ownership and revocation procedure.
• The supported workflows and known exclusions.
• How to report a problem with synthetic or redacted evidence.

Keep actual credentials in the agreed private store, not in the handover’s ordinary document or an issue tracker. Explain what your support arrangement includes without inventing a service-level commitment from the project’s open-source availability.

When PHP Ledger is not the right choice

Choose another system when the client needs completed invoicing, bills, stock costing or regional compliance now, or when you cannot support the hosting responsibly.

Use the Dolibarr comparison and the ERPNext comparison to frame a broader-module evaluation. Keep a working client system in place while you test this preview; avoid turning a development milestone into an unreviewed replacement project.

Coordinate the decision with your team

Read the companion guidance for accountants, for software houses and for business owners. A workable installation needs agreement between the person maintaining it, the person entering records and the person reviewing the accounting.

Project evidence

This guide describes the inspected repository and release scope as of 16 September 2026. The project repository, release package and product scope are the primary project references. Technical tests do not establish accounting approval, independent security review or a service commitment.