Cachet 3.x: a self-hosted status page on PHP 8.3 and Laravel

What Cachet is for, and who ends up running it

A status page answers one question during an incident: is the thing down, and is anyone already working on it. Support inboxes and social accounts answer that question badly, because the same explanation gets retyped for every person who asks. Cachet exists to hold that answer in one place you control. The README describes it plainly as "the open source self-hosted status page system", and the repository topics list self-hosted and status-page alongside laravel and php. That combination tells you the audience: teams that already run their own servers and would rather not hand incident communication to a third party. Because the page is self-hosted, the incident history, the component names and the maintenance windows stay on infrastructure you own. That matters to organisations with data residency rules, and to anyone who does not want an external service to hold a public record of every outage they have had. It is a poor fit for a team with no one to run a PHP application, because a status page that is itself down during an incident is worse than no status page.

The Laravel architecture behind the status page

Cachet is a Laravel application, and the repository layout confirms it: app/, bootstrap/, config/, database/, public/, resources/, routes/, storage/ and the artisan console script at the root. That structure is the standard Laravel skeleton, so anyone who has deployed a Laravel app already knows where configuration, migrations and views live. The .env.example file shows the runtime surface. SESSION_DRIVER, QUEUE_CONNECTION and CACHE_STORE all default to database, which means a fresh install leans on the database for sessions, queued work and caching rather than requiring Redis on day one. Redis is still present as an option through REDIS_HOST and REDIS_PORT, and MAIL_MAILER defaults to log, so notification email is written to the log until you point it at a real transport. CACHET_PATH controls the path the status page is served from and defaults to /, which is the setting to change if you want the page under a subpath. CACHET_TRUSTED_PROXIES is empty by default, which is the setting to revisit behind a load balancer. CACHET_BEACON and CACHET_EMOJI are both false out of the box. The README does not document the internal data model, so the routing, controllers and migrations in routes/ and database/ are the places to read if you need to know how components and incidents are stored.

Installing Cachet 3.x and reaching the dashboard

The README does not carry install steps. It points to the documentation at docs.cachethq.io and lists an Installing Cachet page under the v3.x docs, so that page is the authoritative source and the versions it names may move independently of this article. What the README does state are the requirements: PHP 8.3 or later, Composer, and a supported database, which it lists as MariaDB, MySQL, PostgreSQL or SQLite. The repository also ships .env.example, and the file itself shows the keys a deployment must carry. Set APP_KEY, because it is blank in the example file, and pick your database connection. The example file defaults DB_CONNECTION to sqlite, which is the quickest path for a local trial. For a real deployment, switch it to mysql, mariadb or pgsql and fill in the host, port, database and credentials.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=

Those five keys and their example values come straight from .env.example, where the MySQL lines sit commented out below the sqlite default. The remaining setup steps are the ones the documentation prescribes, and because the artisan script is present at the repository root, the Laravel console is available for migrations and key generation. The README does not list those commands, so treat the docs page as the source for the exact sequence. What you should end up with is a migrated database and a populated APP_KEY in .env. The README also offers a hosted demo at v3.cachethq.io/dashboard with the credentials [email protected] and test123, and notes that the demo resets every 30 minutes, so you can look at the interface before installing anything. The README does not document rollback, backup or a downgrade path, and it does not list an upgrade procedure for 3.x beyond pointing at the docs.

Where Cachet 3.x is still thin

The release list is the first thing to look at honestly. The most recent release shown is v2.4.1 from 2023-11-07, and the entry before the 2.4 line is v2.3.18 from 2019-05-22. The default branch is 3.x, and the README carries a 3.x announcement linking to a discussion rather than a release. That means the code you get from the 3.x branch is ahead of the newest tagged release, and if you deploy from a tag you may be deploying the 2.x line. Decide which of those you want before you start, because the answer changes your PHP and database requirements. The second gap is operational documentation. The README covers requirements and links to the docs, but says nothing about backups, about running the queue worker that QUEUE_CONNECTION=database implies, or about what happens to scheduled maintenance windows when the scheduler is not running. The third is scope. Cachet renders a status page. It does not, based on the README, monitor your services for you, so something else has to decide that a component is down and tell Cachet about it. If you expected a monitoring tool with a status page attached, this is the wrong tool, and the README does not claim otherwise.

Cachet against a hosted status page service

The obvious alternative is a hosted status page product, where the vendor runs the page and you point your DNS at it. The difference is not cosmetic. A hosted page stays up when your infrastructure does not, because it is not on your infrastructure, which is exactly the failure mode a self-hosted page has to plan around. Cachet inverts that: you get control of the data and the presentation, and you take on the availability problem. The second difference is operational. With Cachet you supply PHP 8.3, a database, a web server, TLS, backups and a queue worker, and you upgrade on your own schedule. A hosted product removes all of that and charges for it. There is a middle position worth naming: if your team already runs Laravel applications, Cachet adds one more app to a stack you already operate, and the marginal cost is small. If your team does not, the first status page you run will also be your first Laravel deployment, and the learning curve lands during an incident, which is the worst time for it.

Licence, maintenance and what an upgrade costs you

The repository ships a LICENSE.md and a TRADEMARKS.md, and the metadata records the licence as NOASSERTION, which means the automated classifier could not resolve it to a standard identifier. Read LICENSE.md and TRADEMARKS.md directly rather than assuming a licence from the topic tags, and note that TRADEMARKS.md exists separately, which usually means the name carries conditions the code licence does not cover. On maintenance: the repository is not archived, and the last push to the default branch was on 2026-09-07, so work is happening. That is not the same as a shipped release. The newest release listed is v2.4.1 from 2023-11-07, so the gap between what is committed on 3.x and what is tagged is the real upgrade question. For cost, the upgrade surface is a Laravel upgrade: composer.json and composer.lock define the dependency set, the database/ directory holds migrations that need to run, and .env.example shows the environment keys your deployment must carry. Compare your current .env against the example after any upgrade, because keys like CACHET_TRUSTED_PROXIES and CACHET_PATH can be added or changed between versions. The README documents neither the upgrade path nor a rollback, so plan a database backup before you migrate.

Editorial conclusion

Adopt Cachet if you want a status page you host yourself, you are comfortable running a Laravel application, and you can meet PHP 8.3 with MariaDB, MySQL, PostgreSQL or SQLite. Do not adopt it if you need a managed service with an uptime commitment, or if your infrastructure is still on older PHP and you cannot move it. Before committing, read the 3.x announcement discussion, confirm the docs installation page matches your database choice, and check that the release you intend to run is the one you actually want, since the newest listed release is v2.4.1 from 2023-11-07 while the default branch is 3.x.

Frequently asked questions

Official sources

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