- Can I install Cachet with composer require into an existing Laravel application?
- No. Cachet is a full standalone Laravel application, not a Composer library you pull into an existing app, so composer require will not give you a drop-in status page component. Integrate it service-to-service by deploying it as its own workload with its own database, queue worker, and scheduler, then calling its REST API and consuming its webhooks.
- What are the server requirements for self-hosting Cachet?
- Cachet expects a conventional Laravel runtime: PHP 8.x, a relational database such as MySQL, Postgres, or SQLite, and Redis or database-backed cache and queues. In production that typically means three workloads: the web process, a queue worker, and the cron-driven scheduler. If your platform standard is containers with managed Postgres and Redis it deploys cleanly; on a Node, Go, or Python-only stack you are adding a language runtime and a skills tax.
- Does Cachet have a REST API for automating incidents and maintenance windows?
- Yes. Cachet exposes a stable-ish REST API covering components, incidents and incident updates, metrics, schedules, and subscribers, authenticated with API tokens. That is enough to create incidents from deploy pipelines, monitoring alerts, or an internal ops CLI, and outbound webhooks for incident and component events let you sync into Slack, Teams, PagerDuty, or an internal event bus.
- Which PHP and Laravel versions does Cachet support?
- Cachet is built on Laravel and assumes PHP 8.x, but you should check the composer constraints and release notes for the exact tag you deploy rather than assuming support for the current Laravel release. The 2.x line has a low patch cadence and the long-running 3.x rewrite is a moving target, so pin a tagged release and test upgrades explicitly.
- Is Cachet still actively maintained?
- Maintenance velocity is low: the last tagged release was November 2023, and the 3.x rewrite has left adopters choosing between a quiet 2.x line and an in-progress 3.x. Security disclosure is community-only, which matters because a status page is internet-facing. Budget a standing maintenance allocation for CVE triage on Laravel, PHP, and Cachet itself.
- What license is Cachet under, and can I redistribute it to customers?
- GitHub reports the license as NOASSERTION because it could not detect a standard SPDX identifier, though the project was historically Apache-2.0. Before redistributing, bundling on-prem, or embedding Cachet in a commercial product, have legal read the actual LICENSE file. Treat this as a gating item rather than a checkbox.
- Can Cachet host multiple status pages or tenants on a single instance?
- Cachet is single-tenant by design: one status page per instance. Multi-brand, multi-customer, or per-tenant subdomain requirements imply multiple deployments plus a control plane you would have to build and operate yourself. Size that operational overhead before choosing it over a hosted alternative.
- How do I create Cachet incidents automatically from Prometheus Alertmanager or Datadog?
- Create an API token in Cachet, then have a small relay service translate Alertmanager or Datadog webhook payloads into Cachet incident API calls. Outbound webhooks for incident and component events handle the reverse direction into Slack, Teams, or PagerDuty. Keeping the translation in one relay keeps API tokens out of scattered monitoring configs.
- Does Cachet support SSO, granular RBAC, and audit logging?
- Cachet ships subscriber email notifications, 2FA, and Socialite login, which covers basic auth work. Native SSO/SCIM, granular RBAC, audit logging, and advanced subscriber segmentation are limited or absent without custom development. If those are hard requirements, compare the customization cost against a hosted status page SaaS before committing.
- How do I customize Cachet branding and theming without forking the project?
- Use Cachet's Blade-based theming and custom theme directory to apply branding without forking core, which keeps upstream security patches mergeable. Do the theming work on a non-production instance first. Keep customizations confined to the theme layer so version upgrades stay predictable.