Filament Pwa Laravel Package

Technical Evaluation

Architecture fit. For a team already standardized on FilamentPHP, this is close to the ideal shape: it is a declarative plugin, not a framework. It hooks into panel bootstrapping through a single FilamentPWAPlugin::make() registration, exposes the entire configuration surface — app name, icons, manifest, theme, offline behavior — through a Filament settings page, and offers an @filamentPWA Blade directive so non-panel surfaces (login, public marketing pages) get installability too. That last detail is the real differentiator versus Filament-only PWA plugins: the install prompt and manifest are usually forgotten exactly where unauthenticated users first arrive. The product consequence is that post-launch branding and rollout changes become operable by non-engineers — no deploy, no ticket, no engineering time. Draw the scope boundary explicitly in any brief: this delivers installability plus basic asset caching for authenticated admin panels. It is not a PWA platform. No background sync, no push notifications, no write queue, no multi-tenant manifest scoping.

Integration feasibility. Mechanically simple, transitively non-trivial. The path is composer require, publish the Spatie settings migrations, filament-settings-hub:install, filament-pwa:install, then one line in AdminPanelProvider. The real cost is dependency surface: spatie/laravel-settings, the TomatoPHP settings hub, a new settings table, a publishable config, and a filesystem-disk decision for manifest and icon assets (added in v5). Budget a half-day spike producing a working "Add to Home Screen" proof on a real device, plus explicit time for what the package does not solve: service-worker debugging in DevTools, CDN and cache-header sanity, and an HTTPS-terminated staging origin. One engineer-day for a single panel is a defensible estimate; more if multi-panel scoping or custom asset storage is in scope. If we already run our own settings mechanism, this introduces a parallel one — the honest alternative is a thin hand-rolled service worker, and that buy-vs-build call should be made consciously rather than by default.

Technical risk. Four items belong in the go/no-go review:

1. Vendor concentration and version coupling. 98 stars, zero dependents, MIT, single-maintainer family (TomatoPHP / 3x1io). The release history is a sequence of breaking ports tied to Filament majors — v4.0.0 for Filament v4, v5.0.0 for Filament v5 / Laravel 12–13 / PHP 8.2+ — and the README explicitly tells v4 users to stay on the v4 branch. This dependency moves when Filament moves. That is a calendar entry, not a surprise.
2. Service worker versus authenticated content — the risk that actually matters. A service worker caching Filament responses can serve stale or previously authenticated pages after logout, or across users on a shared device. Release notes mention configurable disks and cache behavior; the README documents nothing about auth-aware cache exclusion. Verify experimentally before this touches any panel holding PII. The test is specific and non-negotiable: log in, browse, log out, go offline, attempt to reach a cached page.
3. Settings-hub coupling and multi-panel scoping. allowPWASettings(false) is per-panel, and v5 fixed both duplicate settings-hub registration and per-panel settings bleed. Multi-panel and multi-tenant installs are precisely where that class of bug recurs — re-verify on our topology rather than trusting the changelog.
4. Metadata hygiene. The listed last release date (2026-09-15) is ahead of the present, and the description references capabilities the README does not document. Confirm tags, branches, and installable versions on Packagist and in a scratch environment before quoting a version in a plan.

Key questions.

• Which Filament major are we on today? That single fact routes us to the v5 line (Laravel 12/13, PHP 8.2+) or pins us to the v4 branch. It is the biggest gate in this evaluation.
• Does the service worker exclude authenticated panel routes, non-GET responses, and logout transitions? Is that configurable, publishable, or a patch we would own?
• What is the cache-invalidation story on a new asset build — does the service worker version bump automatically, or is there a manual release step?
• Where do manifest icons live, and is that disk publicly readable in our environment (local, S3, CDN)?
• Do we have an HTTPS-terminated, installable origin in staging so installability can be tested at all?
• Which user cohorts actually have intermittent connectivity, and is offline read sufficient — or does the workflow need queued writes, which this package does not provide?
• Who owns this after the pilot: platform team as a pinned dependency, or a vendored fork if upstream stalls?

Integration Approach

Stack fit. Laravel + Filament, PHP 8.2+, Spatie settings, standard asset pipeline. It fits cleanly if we already run, or are willing to adopt, the TomatoPHP settings hub; otherwise we are adding a second settings system for one feature. Publish config, views, and translations on day one so we own the override surface instead of depending on upstream defaults — this is also what makes an eventual fork viable. Register the plugin behind a feature flag and a per-panel guard from the start, using v5's allowPWASettings(false) as designed rather than bolting it on after a problem appears.

Migration path. Additive and reversible, which is the strongest thing about it. It creates a settings table and public assets; it touches no existing schema, routes, or models. The rollback story is "disable the plugin and drop the settings table." For a pilot inside a system of record, that matters more than feature depth — a failed experiment costs a day, not a quarter.

Compatibility. Pin explicitly (^5.0 on Filament v5, v4 branch otherwise) and record the exact Filament / Laravel / PHP combination in the pilot document. Run the compatibility check as a named task against our real deployment, not against the README — with a changelog made of breaking ports, a minor-version surprise is a realistic scenario, not a tail risk. Confirm the asset disk behaves with our storage and CDN configuration before committing to icons-from-the-panel as an operator workflow.

Sequencing.

1. Spike (half day): install on a scratch panel, get "Add to Home Screen" working on a real device over HTTPS, capture the actual command sequence and file changes as a runbook draft.
2. Security verification (one day): offline access after logout, shared-device behavior, non-GET handling. This gates everything else. If the service worker cannot be configured to exclude authenticated routes, stop and re-scope to public pages only, or to a hand-rolled implementation.
3. Pilot (one panel, one cohort): behind a flag, with success metrics defined before launch — install rate, session length on degraded connections, reduction in "couldn't load the app" tickets.
4. Operationalize or exit: on measured signal, either promote to other panels with a pinned version and a documented release-checklist step, or remove the plugin and keep the findings.

Operational Impact

Maintenance. Low steady-state effort with one predictable, non-optional tax: this package tracks Filament majors, so every Filament upgrade is a paired upgrade here. Budget one to two engineer-days per Filament major for re-validation, and carry the pinned version in the upgrade backlog rather than treating it as set-and-forget. The compensating win is real: settings-driven branding, icons, and prompts move day-to-day changes off the engineering queue entirely. Because it is MIT with a single maintainer, keep the published config and views in our repo so a fork stays a realistic fallback rather than a rewrite.

Support. No SLA, no contract, no support channel — GitHub issues and a small contributor pool. Acceptable for an internal admin capability adopted as a tactical pilot; not acceptable as a stated dependency for a system of record. Say exactly that to stakeholders, and name an internal owner (platform team) so "who fixes the service worker?" has an answer before launch. Community translations exist (e.g., pt_BR) but coverage is uneven — verify our locales render rather than assuming.

Scaling. Scales well along one axis and poorly along another. More users, more panels, larger icon sets are all fine; the artifacts are static and cacheable. What does not scale is scope: no per-tenant manifest scoping, no advanced offline patterns, no push. If the roadmap later requires tenant-branded manifests, background sync, or notifications, those are new builds, not configuration changes. Document that limit in the pilot brief — discovering it mid-sprint is the expensive path.

Failure modes. Ranked by what actually bites:

• Stale or leaked authenticated content served from cache after logout or on a shared device. Highest severity; test first and re-test after every Filament upgrade.
• Cache staleness on deploy. Installed PWAs keep serving a previous asset build; without a reliable service-worker version bump, "we shipped it and they don't see it" tickets appear. Mitigation: a cache-busting step in the release checklist, owned by name.
• Settings sprawl. Panel-based configuration means a non-engineer can change branding, manifest, or offline behavior in production with no code review. That is the feature and the hazard: gate the settings page behind the existing permission, and add an audit trail or change-log expectation before handing it to operations.
• Storage/asset drift. Icons and manifest served from a disk that later changes permissions or CDN policy can silently break installability. Add a smoke check to the deploy pipeline that fetches the manifest and a referenced icon.

Ramp-up. Fast for anyone who has registered a Filament plugin — hours, not days. Operators need a short written guide (where the settings live, what each field does to the installed app, how to force an update on a device). Engineering needs the runbook plus the security test procedure, because the security test is the artifact that keeps this safe across future Filament upgrades.