Filament Plausible Laravel Package

Technical Evaluation

Architecture fit. This is a thin Filament panel plugin, not an analytics platform. It contributes three things to a Laravel/Filament application: (1) a settings page for a Plausible site ID and API token, (2) a set of native Filament widgets that read the Plausible Stats API, and (3) optional tracking-script injection. Functionally it is a read-mostly presentation adapter sitting between Filament's widget/page layer and an external SaaS API. For a TPM, that framing matters: the package is an accelerator for an admin-surface feature, not a system of record, and it should be treated as replaceable.

Integration feasibility. High on the happy path, low on assurance. Installation is standard Composer + plugin registration in a PanelProvider; configuration is published via Laravel config; no bespoke front end. The 3.4.0 release adds Plugin::make()->navigationGroup(string|Closure), a one-line, opt-in, backwards-compatible change that lets the settings page sit under an existing panel navigation group instead of the plugin's translated default. That is the correct shape for a minor release. The feasibility caveat is evidence, not engineering: 4 stars, 0 dependents, and a single-maintainer footprint mean there is essentially no ecosystem validation, no visible production usage, and no support commitment. Assume you are the first real adopter and price the integration accordingly.

Technical risk. Low-to-moderate, concentrated in dependency and ownership rather than code complexity:

• Sibling-package coupling. The headline 3.4.0 feature requires filament-analytics-core 3.1+. This package's minor release effectively raises the floor of another package; environments pinned below 3.1 either lose the feature or, if the guard is soft, fail at runtime with a BadMethodCallException during panel boot — which takes down the whole panel, not one page.
• Maintainer and lifecycle risk. One maintainer, negligible adoption, and a release timestamp (2026-10-09) that should be verified against the actual repository history. Plan for the realistic outcome that you own the fork.
• Credential handling. A Plausible API token is a live read credential for your analytics account. The critical unknown is whether it is encrypted at rest and gated by Filament policies. The plugin ships a settings page; it does not ship an authorization model for you.
• Framework upgrade exposure. Filament majors have historically moved page/widget/navigation APIs. A four-star plugin will not be upgraded on your schedule. Any Filament v4 migration should assume this package is a work item, not a given.
• External API dependency. Widgets are only as good as Plausible's Stats API availability, quota, and response shape. Caching reduces request volume but adds a staleness/consistency question the package does not resolve for you.
• Closure semantics (3.4.0). A navigationGroup(Closure) resolver is evaluated during panel/navigation assembly, so a throwing or expensive closure degrades every page in that panel. Small blast-radius increase for a trivial-looking API.

Key questions.

1. Is filament-analytics-core 3.1 a hard Composer constraint or a soft, runtime-discovered requirement?
2. Where are the site ID and API token persisted, and are they encrypted at rest and masked in the UI?
3. Which Filament authorization primitive gates the settings page and widgets — policy, canView, or nothing? Can a non-admin role reach the token?
4. What is the tested compatibility matrix (Filament v3/v4, Laravel 10/11/12, PHP 8.1/8.2/8.3), and is there CI proving it?
5. What is the cache TTL, which cache store is used, and are keys namespaced per site/tenant?
6. Does the package inject the Plausible tracking script as well as read stats, and can those be enabled independently?
7. How do widgets behave when the token is invalid, the API is down, or the quota is exhausted — graceful empty state or unhandled exception?
8. Is there any migration or settings table, and how is it rolled back?
9. For 3.4.0 specifically: does an unregistered group name create an implicit group or inherit default ordering, and is an empty/null closure result a fallback or an ungrouped page?
10. What is the maintainer's stated support posture (issues SLA, security disclosure, release cadence)?

Integration Approach

Stack fit. Native fit for Laravel + Filament v3 admin panels. Registration is a composer require, a plugin entry in the relevant PanelProvider, and optional config publishing. It composes with existing panel conventions — navigation groups, clustering, tenancy, sorting — and does not touch routes, middleware, or your domain code. It is the right shape for internal ops dashboards, SaaS admin panels, and client portals where "analytics next to the admin" is the desired UX and a separate BI tool is overkill.

Migration path. There is no data migration; this is additive. The pragmatic path is a staged spike rather than a big-bang install:

1. Spike in a non-production panel (or a throwaway panel provider) with a dedicated Plausible site and a scoped API token. Confirm the widget set, caching behavior, and failure states against real data before it touches a shared environment.
2. Security review gate. Verify token storage and authorization before any shared or client-facing panel. If the settings page is world-visible to panel users, that is a blocker, not a backlog item.
3. Land dependencies together. If adopting 3.4.0, bump filament-analytics-core to ^3.1 and this package to ^3.4 in a single PR so there is no window where the package is present but the core floor is not. Deploy unchanged first — the default translated group is preserved — then opt into ->navigationGroup(...) per panel in a follow-up.
4. Migrate from GA/other tooling via dual-run, not cutover. Keep the incumbent dashboard available for one reporting cycle, validate that the Filament widgets answer the questions stakeholders actually ask (visitors, pageviews, sources, date ranges), then decommission.
5. Opt in panel by panel, lowest-traffic first, if you run multiple panels.

Compatibility. Three constraints to pin explicitly: the filament-analytics-core floor (3.1+), the Filament major version, and the PHP version implied by string|Closure union typing (8.0+, realistically higher given current Filament). Register intended navigation groups on the panel (->navigationGroups([...])) so placement is deterministic rather than incidental. Multi-tenant deployments should be validated per tenant, since site IDs and cache keys may collide if the package does not namespace them.

Sequencing (TPM view). Security review → dependency bump → install-and-observe in staging → enable widgets for a pilot group → opt into navigation grouping → document and hand to support. Front-load the security and dependency steps: they are the only two that can force a revert, and both are cheap to do first. Keep the whole thing behind a feature flag or a non-default panel so removal is a config change, not a code change.

Build-vs-buy note. Given the adoption signals, treat this as buy-then-own: adopt to save the two-to-five days of writing widgets against the Plausible API, but assume you will vendor or fork within a Filament major. Budget a half-day to read the source — it is small — and write down where the seam is (settings page, widget classes, API client) so a fork is a contained exercise.

Operational Impact

Maintenance. Runtime maintenance is near zero: no jobs, no queues, no storage beyond settings and cache. The real obligation is dependency hygiene and fork readiness. You are adding a package that is not on anyone else's upgrade path, so put it on your own watchlist: track Filament majors, track filament-analytics-core releases, and re-evaluate at each. Capture it in the dependency-update runbook alongside the core package so they are never bumped independently.

Support. Expect a short tail of low-severity tickets: "the analytics page moved", "I can't see the analytics menu", "the numbers don't match Google Analytics", "the dashboard is blank". Most are configuration or expectation issues, not defects. Two docs artifacts absorb nearly all of them: a page covering site ID/token setup, caching TTL, and data-source caveats (Plausible and GA will not agree; do not promise they will), and a note that the settings page is permission-gated with the exact role required. Support staff should know that removing the plugin line or the navigationGroup() call restores prior behavior — that is a safe first-line remedy.

Scaling. Negligible compute: widget rendering plus cached API reads. The scaling risks are organizational and quota-shaped, not CPU-shaped:

• Request amplification. Each widget on each dashboard load is a potential API call. With caching this is fine; without it, a popular admin panel can burn Plausible API quota and produce rate-limit errors that look like outages. Confirm the TTL and consider a single shared fetch if you render many widgets.
• Tenancy. Multi-tenant or multi-brand deployments need per-tenant site IDs and namespaced cache keys. The 3.4.0 Closure navigation form makes per-tenant placement easy, but it runs on panel boot — do not put a database lookup for tenant metadata inside it, or you pay that query on every panel page.
• Panel-wide coupling. Because the settings page and nav grouping are assembled with the panel, a failure here is a panel-wide failure. That is the main reason to keep the integration reversible.

Failure modes (ranked by severity).

1. Credential exposure — API token readable by a broader audience than intended. Highest severity; mitigate with encryption at rest, a policy, and a scoped read-only token.
2. Panel boot failure — missing core version, incompatible Filament release, or a throwing navigation closure takes down navigation for every page. Mitigate with a hard Composer constraint, a defensive total closure, and a staging smoke test of the panel.
3. Silent staleness — invalid token or API change renders empty/zero widgets that look like "no traffic". Mitigate with an explicit error state and an alert on repeated API failures; do not let a zero look like a fact.
4. Quota exhaustion / rate limiting — intermittent blank widgets during peak admin usage. Mitigate with caching and a documented TTL.
5. Cosmetic navigation regressions — unregistered group names, duplicate headings, unexpected ordering. Low severity, high ticket volume; mitigate with ->navigationGroups() registration and a naming convention.
6. Abandonment — the package stops receiving updates at a Filament major. Mitigate by owning the fork decision in advance and keeping the integration isolated to panel configuration.

Ramp-up. Low for anyone who has configured a Filament panel: roughly half a day end-to-end including the security check, and about fifteen minutes for the 3.4.0 navigation change alone. The genuine learning edge is not this package but Filament navigation-group registration and ordering, plus the operational semantics of Plausible's API (what the metrics mean, why they differ from GA, how caching affects freshness). Enablement package: one worked PanelProvider example including ->navigationGroup(), a note on the filament-analytics-core floor, a caution against expensive or non-deterministic closures, and a one-paragraph "what to do when the widgets are blank" runbook.