Cachet 3.x: A PHP and Laravel Status Page You Host Yourself

The gap Cachet fills: incident communication without a vendor account

When a service degrades, the people affected usually find out from each other rather than from you. A status page is the countermeasure: one public URL that reports component health and incident history. Commercial status page products exist, and they are the usual answer. Cachet takes the other route. The README describes it as "the open source, self-hosted status page system", which means the page, its database and its incident records sit on infrastructure you control. That matters to teams whose incident notes cannot leave their own network, and to anyone who does not want a third party's availability to determine whether their own outage notice is reachable. The audience is narrow and identifiable: PHP shops, teams already running Laravel, and operators who would rather patch a server than sign a contract. It is not aimed at people who want someone else to be on call for the status page itself.

What the 3.x branch changes, and why the version number matters

Cachet 3.x is not a routine release. The README links a discussion thread titled "Cachet 3.x Announcement", described as covering "the Cachet rebuild and our plans for 3.x". Rebuild is the operative word. The default branch is 3.x, while the newest tagged releases listed are v2.4.1 from November 2023 and v2.4.0 from the previous month. Before those, the previous tag was v2.3.18 in May 2019, a gap of more than four years. That history is the single most useful thing to know before evaluating Cachet. A project that went quiet for four years and then restarted on a new branch is a different proposition from one with steady incremental releases. The README also states the requirement for PHP 8.3 or later, which is a modern floor and consistent with a rebuild rather than a patch. If you are running an older PHP version, the 3.x branch is not available to you without an upgrade.

Requirements and the database choices the README names

The stated requirements are short: PHP 8.3 or later, Composer, and a supported database from the list MariaDB, MySQL, PostgreSQL or SQLite. Composer is the PHP dependency manager, so installation is expected to run through it rather than through a downloaded archive. The database list is wider than many PHP applications offer, and SQLite is included alongside the server-grade options. That inclusion is worth noting for what it implies: SQLite is a file-backed database, so a single-file deployment is technically possible for small installations. It also implies a limit. A status page on SQLite is a status page whose data lives on one disk on one host, and the README does not present SQLite as a high-availability choice, only as a supported one. The README directs readers to docs.cachethq.io for installation, upgrades and documentation, with a specific quick link to the v3.x installation page. The repository README itself does not reproduce the install commands.

Getting it running: what the material actually gives you

This is where the supplied material runs thin, and it is worth being direct about that. The README names the requirements, points to https://docs.cachethq.io/v3.x/installation for the install procedure, and stops. It does not print a composer create-project line, a migration command, or an environment file template. So the honest instruction is: read the v3.x installation page before you plan a deployment, because the README alone is not sufficient to install the application. What you can confirm from the repository is the shape of the work. Composer must be present, PHP must be 8.3 or higher, and a database must be chosen and reachable. The demo gives you a way to look at the product before committing to any of that: the README lists a dashboard at v3.cachethq.io/dashboard with the credentials test@test.com and test123, and notes that the demo resets every 30 minutes. Those credentials are published in the README and are for the demo only. Treat anything you see there as disposable, because the reset wipes it.

The licence field says NOASSERTION, and that is a real problem

The repository metadata reports the licence as NOASSERTION. That is not a licence name. It means the hosting platform could not map the project's licence file to a known identifier, or that no standard licence file was detected. For a self-hosted tool you intend to run inside a company, this is the first thing to resolve, and it is not something the README addresses at all. The README's only legal-adjacent content is the security section, which asks that vulnerabilities be emailed to support@cachethq.io and states that reports are reviewed on a case-by-case basis. That is a disclosure channel, not a licence statement. Before deploying Cachet, read the licence file in the repository and have someone who can make that call decide whether its terms fit your use. This article cannot give you legal advice, and the metadata alone does not tell you what the terms are. A project with an unclear licence identifier and a rebuild in progress is a combination that deserves a look before it deserves a server.

Where Cachet is the wrong tool

The failure mode is not technical, it is operational. A self-hosted status page inherits your infrastructure's failure modes. If the host running Cachet goes down with the service it is supposed to report on, the status page is down too, and it has failed at the one job it had. That is a design consequence, not a bug, and the README does not claim otherwise. The second case is upgrade risk. With the default branch on 3.x, the newest tagged release on the 2.4.x line, and a documented rebuild in between, anyone running 2.x faces a migration whose details are not in this material. The README points to docs.cachethq.io for upgrades, which is the right place to look, but it does not summarize what changes. The third case is team size. A status page needs someone to update it during an incident, and a self-hosted one also needs someone to patch PHP and Composer dependencies. A small team without that capacity will end up with a stale status page, which is worse than none, because it asserts health that may not exist.

The alternative: hosted status pages, and the actual difference

The obvious alternative is a hosted status page service, where a vendor runs the page on their infrastructure and you pay a subscription. The difference in approach is not cosmetic. With a hosted service, the page's availability is decoupled from yours, so an outage in your own network does not take the notice down with it, and updates arrive without you touching PHP or Composer. You also get a vendor to escalate to. The costs are the mirror image: your incident data lives in someone else's database, the page's uptime depends on a third party, and pricing scales with usage rather than with your server bill. Cachet's answer is that you keep the data and the page, and you accept the operational load. Neither is universally correct. If your status page must survive your own outage, a self-hosted page on the same infrastructure is the weaker choice, and no amount of configuration fixes that. If your constraint is data residency or vendor count, Cachet's trade is the one you want. The decision is about which failure you can tolerate, not about which product is better.

Maintenance cost and what to check before you commit

Running Cachet means owning a PHP application. PHP 8.3 or later is the floor, Composer is the dependency manager, and the database is one of four options you must keep patched. Every one of those is a moving part with its own update cadence, and the project's own history shows why that matters: the jump from v2.3.18 in May 2019 to v2.4.0 in October 2023 is a four-year gap in tagged releases, and the 3.x rebuild is still the default branch rather than a tagged release in the material provided. A team adopting Cachet should plan for the possibility of doing its own dependency maintenance rather than waiting for upstream tags. Concretely, before you deploy: open docs.cachethq.io/v3.x/installation and follow it end to end on a throwaway host, read the licence file that produced the NOASSERTION metadata, and decide which database you are actually going to run in production rather than which one is easiest to start with. If those three checks pass, Cachet is a reasonable fit for a PHP team that wants its status page in its own database. If any of them stalls, the hosted route is the lower-risk answer.

Editorial conclusion

Adopt Cachet if you already run PHP 8.3 infrastructure and want incident communication to live in your own database rather than a vendor account. Do not adopt it if you need a managed service with a support contract, or if you cannot commit to following the 3.x rebuild, since the most recent tagged release, v2.4.1 from November 2023, sits on a different line from the default 3.x branch. Verify first that your target database (MariaDB, MySQL, PostgreSQL or SQLite) is among the supported options and that your PHP version meets the 8.3 floor, because the README states that requirement plainly and the 2.x releases predate it.

Official sources

1. cachethq/cachet on GitHub
2. Issues
3. Project website
4. README
5. Releases