Filum Laravel Package

Technical Evaluation

Architecture fit. Filum is a Filament panel plugin, not a standalone chat service. It registers a page, a slide-over Livewire component on every panel page, and a set of migrations into the host application's database. That is a good architectural shape for internal admin tooling: no new service to deploy or operate, no external data processor, no second identity system — it reuses the panel's guard and user model. For a back office where the audience is already authenticated staff, this is close to an ideal integration boundary. The cost of that shape is that chat becomes a schema dependency inside your application: filum_* tables, foreign keys derived from your user model, and a Livewire surface mounted on every page in the panel. You are not adding a widget; you are adding a subsystem whose failure blast radius is the whole panel (a misconfigured user model surfaces as an error on every page, not just on chat).

Integration feasibility. Feasible, with a narrow and unforgiving prerequisite band. PHP 8.3+, Laravel 12 or 13, Filament 4.11.5+ or 5.6.5+. If the estate sits on Laravel 10/11 or Filament 3, this package is not a candidate today and the real project is a framework upgrade. The Filament floor is documented as a security minimum rather than a preference, so the panel must be patched to that level regardless — Filum is simply not resolvable below it. Installation is a three-command path (composer require, filum:install, migrate) plus one line in the panel provider, which is genuinely low-friction. The configuration surface is broad but declarative and env-driven: transport, notifications, groups, attachments, reactions, presence, user model, auth gate. Everything is optional-with-a-default, and the defaults are sane (polling, notifications on, private local disk).

Technical risk. The dominant risks are maturity and deploy discipline, not design.

• Maturity. 7 stars, 0 dependents, README + changelog as the maturity signal, effectively unproven in production anywhere you can point to. The README is unusually candid and detailed — a positive signal about the author's engineering temperament — but candor is not a support contract. Assume single-maintainer bus factor and plan a fork contingency.
• Upgrade footgun, self-documented. Publishing the aggregate filum-migrations tag on an existing install duplicates create_filum_tables under a fresh timestamp; migrate then aborts before reaching the new migration, leaving new code on an old schema. The package's own statement is that this is a hard outage: opening a direct conversation writes kind, state, joined_at, and every membership check reads state. That means migration and code must ship in the same release step, and someone on the team must own that rule permanently.
• Transport degradation mode. Configure a broadcaster without building Echo into the panel assets and Filum silently falls back to a 30-second reconciliation poll — slower than the 5-second poll you get with no broadcaster at all. A half-finished Reverb rollout is a regression, not a no-op.
• Auth breadth. Default authorization is "anyone the panel has authenticated." If the panel admits contractors, read-only support accounts, or shared logins, chat is exposed to all of them until Filum::auth() is registered.
• Attachments. The private-disk requirement is explicit, MIME sniffing reads file bytes, and files are served through a membership-checking route that 404s rather than 403s. Good controls. Still no mention of antivirus scanning or per-file retention.
• Data lifecycle. Not documented: what happens to a departed user's messages, whether the data is subject to export/erasure requests, and whether there is any search or audit export.

Key questions.

1. Which Filament major and Laravel version are we actually on, and is the upgrade to the minimums already funded?
2. Who is the panel population — employees only, or contractors and read-only roles that the default gate would expose?
3. Does chat content fall under our retention, subject-access and erasure obligations, and who signs off on the answer?
4. Do we already run Reverb or another broadcaster, and can we guarantee Echo ships in the asset build if we do?
5. Is "as-is OSS with GitHub-issue support" acceptable for this class of tooling, and who owns the fork if the maintainer stops?
6. Do we need search, audit export or moderation on admin conversations for compliance?
7. Which panels get it — all of them, or only the staff-facing one?

Integration Approach

Stack fit. Strong, conditional on the version matrix being satisfied. Filum deliberately assumes nothing about the user schema — configurable model, optional guard override, configurable name and avatar columns, working with integer, UUID and ULID keys. It reads config/broadcasting.php and adapts, and the notification path reuses Filament's own bell and the application's existing notifications table. There is no new dependency in require that drags in a hosted vendor.

Migration path. Additive on the way in — no existing data is transformed, only new tables created. On the way out, the data is yours: conversations, participants, messages, reactions and attachment metadata live in tables whose migrations you have published, so an exit is a SQL export plus a bespoke UI, not a vendor negotiation. That is a materially better lock-in position than any SaaS chat. Treat the schema as owned by your team from day one: publish migrations, review them, and include them in your own migration-linting checks.

Compatibility. Narrow. Filament 4.11.5+ and 5.6.5+ means the package maintains two UI paths against a framework that behaves differently in exactly the place Filum operates (a Livewire component inside a drawer — the reason group management uses plain fields rather than modals). Pin the package version, test on the exact Laravel/Filament pair you run, and do not let minor framework bumps ride through without a smoke test of the slide-over.

Sequencing.

1. Framework prerequisite workstream: PHP 8.3, Laravel 12/13, Filament to the security floor, Echo build pipeline if a broadcaster is in scope.
2. Set FILUM_USER_MODEL in every environment's .env — unquoted, and before the first migrate. Not a local-only step.
3. Install on a branch/staging panel first; run filum:install and migrate; add the plugin to one panel provider only.
4. Register Filum::auth() explicitly. Do not ship on the default gate.
5. Start on polling transport. It requires zero infrastructure and is the correct default for a pilot.
6. Only then evaluate Reverb — and if adopted, reverb:install (which installs Echo and sets BROADCAST_CONNECTION), npm run build, and an explicit browser check that window.Echo exists on a panel page. Without that check you are in the 30-second orphan state.
7. Confirm the attachments disk is private in every environment; add a retention/cleanup job before wide rollout.
8. Pilot with a small admin group for one sprint, then widen. Keep the migration-tag rule in the release checklist permanently.

Operational Impact

Maintenance. The recurring cost is not code, it is vigilance. Three standing obligations: publish only per-release migration tags and never the aggregate tag on an existing install; ship schema and code in the same release; re-validate the slide-over and group UI whenever Filament moves. Add a CI check that fails if a second *_create_filum_tables.php appears in the migrations directory — that single guard neutralises the worst documented failure. Budget a named owner and a pinning policy; assume a fork review at each Filament major.

Support. No vendor, no SLA, no paid tier. Escalation is a GitHub issue on a 7-star repository. For internal admin tooling that is defensible; for anything touching regulated communications it is not, unless the fork option is real and staffed. The Notifier contract is a useful escape hatch — chat notifications can be redirected to mail, Slack or a pager without touching the package.

Scaling. The realistic population is staff, i.e. tens to low hundreds, and the package is sized for that. Load characteristics to model: 5-second polling per active client with no broadcaster; 30-second reconciliation polling per client with one; a 60-second presence heartbeat writing last_seen_at; and Filament's own bell polling. Attachment bytes belong on object storage, not the database. messages growth is linear and slow for an internal chat, but a retention policy keeps indexes honest. Reverb, if adopted, becomes a supervised daemon with its own port, TLS and restart policy — a real, if small, operational addition.

Failure modes to pre-write runbooks for.

• Duplicate create_filum_tables migration → migrate aborts → new code queries missing columns → all chat fails, including 1:1. Recovery: delete the newer duplicate, migrate.
• Code deployed ahead of schema → same class of hard outage on the first direct-conversation open.
• Broadcaster configured, Echo absent → silent degradation to slower-than-default polling; looks like "the chat is laggy," wastes a debugging cycle.
• Wrong or unresolvable FILUM_USER_MODEL → error on every page in the panel, since the current user is resolved while building navigation. Highest blast radius of any misconfiguration here.
• Public attachment disk → every sent document readable by anyone who guesses a path; the membership-checking route only protects links the package generates.
• Presence ttl at the 180-second default → a colleague who closed their laptop is still "here," gets no bell, and the coupling is deliberate and documented. Tune ttl if that lag matters more than a twitchier presence indicator.
• Maintainer abandonment → no support for the next Filament major, eventually a hard upgrade block.

Ramp-up. Admins: near zero — click a colleague in the sidebar, type, done; the slide-over is available on every page, which is the right affordance for a back office. Developers: moderate — the config surface is wide but well documented, and the real learning is deploy discipline rather than API. Ops: minimal on polling; Reverb converts that into a supervised service. Overall, this is a small-team tool with a disproportionately sharp upgrade edge, and the assessment should reflect that: adopt it as a pinned, piloted, single-panel dependency with an explicit gate and a fork contingency — or defer until the framework prerequisites are already paid for.