Cachet Laravel Package

Technical Evaluation

Architecture fit. Cachet is not a Composer library that gets pulled into an existing Laravel application — it is a full standalone Laravel application (the Dependents: 0 figure confirms it is not consumed as a package). Any integration is therefore service-to-service, not code-level: you deploy Cachet as its own workload with its own database, queue worker, and scheduler, then talk to it over its REST API and webhooks. Teams expecting a drop-in composer require status component will be disappointed; teams expecting a self-hosted Statuspage.io equivalent will find a reasonable fit.

Integration feasibility. Reasonable, with clear seams:

• Stable-ish REST API for components, incidents, incidents updates, metrics, schedules, and subscribers, authenticated via API tokens — enough to drive incident creation from deploy pipelines, monitoring alerts (Prometheus Alertmanager, Datadog webhooks), or an internal ops CLI.
• Outbound webhooks for incident/component events allow syncing into Slack, Teams, PagerDuty, or an internal event bus.
• Blade-based theming and a custom theme directory allow branding without forking core.
• Built-in subscriber email notifications, 2FA, and Socialite login reduce custom auth work.

Technical risk. This is where a TPM should slow down:

1. License is NOASSERTION. GitHub could not detect a standard SPDX license. Historically Apache-2.0, but before any redistribution, on-prem bundling, or embedding in a commercial product, legal must read the actual LICENSE file. Treat this as a gating item, not a checkbox.
2. Maintenance velocity is low. Last tagged release was November 2023, and the long-running 3.x rewrite has created a fork in the road: adopting 2.x means accepting a low patch cadence; adopting 3.x means tracking a moving target. Neither is a comfortable default for a customer-facing surface.
3. Security patch dependency. Status pages are externally exposed. You inherit responsibility for CVE triage on Laravel, PHP, and Cachet itself, with community-only disclosure channels.
4. Single-tenant by design. One status page per instance. Multi-brand, multi-customer, or per-tenant subdomain requirements imply multiple deployments and a control plane you would have to build.
5. Feature ceiling. Native SSO/SCIM, granular RBAC, audit logging, and advanced subscriber segmentation are limited or absent without custom work.

Key questions to resolve before commitment:

• Is self-hosting a hard requirement (data residency, air-gap, cost), or would a hosted SaaS status page clear the bar faster?
• Do we need SSO/SCIM, audit logs, or multi-page tenancy? If yes, the customization cost likely exceeds the value.
• What is our internal SLA for security patching on an internet-facing service, and can we meet it with a community-only upstream?
• What is the distribution model — internal SaaS, or redistribution to customers? This determines whether the license question is fatal or merely a review item.
• How many subscribers and what notification volume? This sizes the queue and email provider.
• Which team owns PHP/Laravel operations, and do they have bandwidth for a standing maintenance allocation?

Integration Approach

Stack fit. Cachet assumes a conventional Laravel runtime: PHP 8.x, a relational database (MySQL/Postgres/SQLite), Redis or database-backed cache and queues, a cron-driven scheduler, and a queue worker. If the platform standard is containers on Kubernetes or ECS with managed Postgres and Redis, this drops in cleanly as a three-workload deployment (web, queue worker, scheduler). If the org is Node/Go/Python-only, this introduces a language runtime and a skills tax that should be priced explicitly.

Migration path. Run Cachet as a parallel communications channel before it becomes the primary one:

1. Stand up a non-production instance behind SSO, themed to brand.
2. Mirror a single low-risk service's incidents into it via API, keeping existing channels authoritative.
3. Build the automation (alert → incident, deploy → maintenance window) and validate webhook delivery end to end.
4. Cut over one service at a time; retire legacy comms per service once subscriber lists are migrated.

Compatibility considerations.

• Pin the PHP minor version and the database major version to whatever the chosen Cachet tag declares; do not let the base image float.
• Verify the Docker image tags against the source tag — community images can lag releases.
• Confirm the API version you build against matches the deployed major version; 2.x and 3.x are not drop-in compatible.
• Test the scheduler and queue worker under load, not just the web container — most "Cachet is broken" reports trace to one of those two.

Sequencing.

1. Legal/license review (gate).
2. Infrastructure: container, managed DB, Redis, TLS, custom domain via reverse proxy.
3. Identity: SSO or local accounts, 2FA policy.
4. Branding: theme, logo, component taxonomy.
5. Automation: API tokens, incident-creation hooks from monitoring and CI/CD, webhook fan-out.
6. Enable notifications to a pilot subscriber list.
7. Runbooks, then progressive cutover.

Alternative to keep on the table. If the real requirement is "show component health on our own site," a lightweight custom health endpoint plus a static page may beat operating a full Laravel app. If the requirement is "run a real status page with subscribers and incident history," Cachet is a defensible choice — but compare it against hosted options and against maintaining a fork before deciding.

Operational Impact

Maintenance. Budget ongoing ownership, not a one-time deploy. Expect monthly dependency review, quarterly upgrade rehearsals, and a documented process for cherry-picking upstream security fixes when the release cadence stalls. Because upstream is slow, assume you will occasionally patch ahead of the project. A realistic allocation is 0.25–0.5 FTE for a single small instance, higher if you fork for customization.

Support. Community only — GitHub issues and chat. There is no vendor SLA, no security contact with response commitments, and no commercial backstop. Escalation is "read the source," which is fine for a Laravel-fluent team and painful for anyone else. This should be stated plainly to stakeholders.

Scaling. A single web replica handles typical status page traffic comfortably; scale horizontally behind a load balancer with shared database and Redis for cache and sessions. The queue worker is the scaling knob that matters — email subscriber notifications are the burst workload during a major incident, and a single worker will back up. Metrics ingestion and subscriber tables are the database growth vectors; set retention policies for metric points. If you need many status pages, scale by deploying multiple isolated instances, each with its own database, and build a thin control plane for provisioning and theme sync.

Failure modes to design against.

• The status page is down during the incident it should report. This is the signature failure of self-hosted status pages. Host it in a separate failure domain from production, and stand up a static "we are investigating" fallback page served from a CDN that does not depend on Cachet, its database, or its queue.
• Silent notification failure. If the queue worker or scheduler dies, incidents publish to the page but subscribers never hear about it — with no error visible in the UI. Alert on queue depth and worker liveness; send a synthetic incident through the full pipeline weekly.
• Notification storm. A mass-incident update can fan out to the entire subscriber list at once. Enforce batching, rate limits at the email provider, and a hard cap per incident update.
• Scheduler not running. Scheduled maintenance windows silently never publish. Monitor cron.
• API token leakage. Tokens can create and resolve incidents — treat them as production secrets, scope them per integration, and rotate on personnel change.
• Database as single point of failure. Cache and session misconfiguration can turn a Redis blip into a login outage; decide deliberately what is allowed to degrade.

Ramp-up. A Laravel-fluent engineer reaches productive operation in roughly one to two weeks (deploy, theme, API integration, runbooks). A team without PHP experience should plan four to six weeks, and should assume they will need external help for the first security patch cycle. Either way, name an owner before the pilot starts — an unowned status page is worse than no status page, because it makes a promise of transparency that lapses silently during the first real outage.