Filament Browser Laravel Package

Technical Evaluation

PM framing. This is not a product feature; it is a privileged operator console shipped inside the admin panel. It mounts a file/folder/media browser over the server filesystem with in-place code and Markdown editing, upload, rename, delete, and inline previews (image, video, audio, PDF, Excel, Markdown). Every downstream decision — owner, environment scope, access model, audit — should follow from that framing. It is a replacement for SSH/FTP, and should be evaluated as such, not as a UI component.

Architecture fit

• Good fit for Laravel monoliths already on Filament v5 / Laravel 12–13. It registers in AdminPanelProvider via FilamentBrowserPlugin::make(), inherits panel auth/routing/Livewire, and introduces no new service, datastore, queue, or sidecar. Operationally that is close to zero new surface area to run.
• Acceptable fit for internal developer/ops tooling where the alternative today is SFTP, ad-hoc mv/nano, or remote SSH — one auditable-in-principle surface instead of many out-of-band ones (in principle, because the package ships no audit log; we must add it).
• Poor fit for API-only/headless services, S3-or-cloud-only storage models, multi-tenant SaaS needing per-tenant filesystem isolation, or any org whose policy forbids in-app filesystem writes.
• The decisive design question is blast radius, not code quality. The README's own example uses basePath(base_path()) — the entire application tree. A TPM's first job is to force the root down to a purpose-built directory (e.g. a content or imports directory, or a /storage/app/browser sandbox) before anything is installed in a shared environment.

Integration feasibility

• Mechanically trivial: composer require tomatophp/filament-browser, php artisan filament-browser:install, register the plugin with fluent config (basePath, hiddenFolders, hiddenFiles, hiddenExtensions, per-action allow* flags, authorize()). Config/views/lang/migrations are publishable but optional; core function needs no migrations, so the code-level blast radius is low and reversible.
• The cost is not engineering. Budget roughly: ~1 day install and configuration; ~1 week of hardening, threat-model, and access-policy design; 2–4 weeks of change management and pilot before write access is safe anywhere shared. Developers will estimate only the first line. Staff the latter two explicitly or they will silently not happen.
• Adoption signal is weak. 43 stars, 0 dependents, single-maintainer ecosystem (TomatoPHP/3x1io), score 20.6 with opportunity 17.1. There is no peer validation to borrow. Treat this as a build-vs-buy call in which "buy" means "adopt and be prepared to own."

Technical risk (ranked)

Key questions to resolve before commitment

1. Who is the named owner — a person, not a team — and have they accepted single-maintainer risk in writing?
2. What is the configured root, and can it be narrowed away from base_path()?
3. Do we need write access in production at all, or is production read-only with writes confined to staging/pre-prod?
4. What does authorize() check in our org — SSO group, environment, ticket reference, IP range, time window?
5. Where do file operations land in our audit/observability stack, given the package emits none?
6. Are we on Filament v5 / Laravel 12–13, or must we pin the v3 branch and staff a divergent, lower-support track?
7. Does anything internal call the removed legacy JSON route, and do published views depend on the removed JS bundle?
8. What is the fallback if upstream goes stale — fork, vendor, or revert to Forge/IDE remote-SSH? Who executes it, how fast?
9. What is the success metric (e.g. drop in SSH/FTP tickets, time-to-inspect a file) and what would make us reverse the decision?

Integration Approach

Stack fit

• Greenfield-compatible: no data model, no required migrations, no external services, no queue workers. Cost concentrates in configuration and policy — good for delivery predictability, dangerous because it creates the illusion that "install = done."
• Hard prerequisite: a working Filament panel. If the team has not standardised on Filament, this package is not a reason to adopt it. A convenience tool must not drive a framework decision.
• Ecosystem fit: registers under a Settings group and integrates with tomatophp/filament-plugins, so it lands in an existing plugin-management surface rather than as a bespoke carve-out — provided we already use that convention.
• Positioning guardrail: an alternative to SSH/FTP for inspection and light edits. It is not a deployment mechanism, not config management, and must never become the sanctioned path for changing application code in production.

Migration path There is no data migration; the migration is organisational — moving from out-of-band file operations (FTP/SFTP/SSH/CLI) to an in-panel workflow.

• Run both in parallel for the pilot window rather than cutting over. Revoke legacy channels only after the in-panel path has demonstrably covered the real use cases.
• Enumerate the current out-of-band file operations (who does what, where, how often) first — that inventory is both the business case and the pilot test script.
• Publish only the config file initially; defer views/lang overrides until a concrete need appears, to keep the upgrade path clean.
• If we are on Filament v3, the path is a branch pin (v3), not a version bump — accept explicitly that this is a lower-support, likely-to-divergе track and record the decision.

Compatibility

• Version coupling is tight and should be treated as a hard gate: Filament v5 + Laravel 12/13 for the current line; v3 branch for older stacks. Filament's built-in CodeEditor replaced creagia/filament-code-field at v5 — any local customisation built on the old field will break.
• .env is hidden by default at v5; any team that needs it visible is creating a security exception, not a config toggle.
• Previews are now embedded rather than copied to public storage — verify that large PDF/Excel/video previews still behave acceptably under our PHP memory and timeout limits, since that path changed.
• Check php.ini realities: upload_max_filesize, post_max_size, max_execution_time, and available disk headroom all become user-facing constraints once uploads are exposed through the UI.

Sequencing (recommended, ~6–8 weeks elapsed)

1. Week 0 — Decision & ownership. Assign named owner; confirm Filament/Laravel versions; write the ADR including the exit path. Gate: no install without an owner.
2. Week 1 — Sandbox install. Non-production only. Narrow basePath, all hidden* lists populated, all allow* writes off. Verify read-only browse and previews.
3. Week 1–2 — Access model. Implement authorize() (SSO group + environment + optional time/IP), retire reliance on DEVELOPER_GATE_PASSWORD, and confirm the gate is re-checked on every Livewire request.
4. Week 2 — Security review. Threat model against R1–R3; confirm realpath/symlink confinement behaviour empirically (attempt traversal); get written sign-off. Gate: sign-off required before any write flag is enabled.
5. Week 3–4 — Audit & backup. Ship the file-operation audit log and confirm the configured root is within snapshot coverage. Gate: no delete/overwrite without audit + restorable backup.
6. Week 4–5 — Enable writes in staging. Turn on allowEditFile/allowCreateNewFile/allowCreateFolder/allowRenameFile/allowDeleteFile in staging only; run the pilot use cases from the inventory.
7. Week 6–8 — Pilot with 2–5 super-admins, measure the success metric, then decide on production — likely read-only in production, read-write in staging/pre-prod.
8. Post-pilot — pin the version, register the override list, schedule quarterly dependency review.

Operational Impact

Maintenance

• Low runtime maintenance (no services, no schema, no cron), moderate governance maintenance: version pinning, quarterly release review, override register, and periodic re-validation of the hidden*/allow* matrix as directories are added.
• The real ongoing cost is ownership of a single-maintainer dependency. Someone must be able to read the source, patch it, and fork it. That is a named-person commitment, not a team aspiration.
• Upgrade discipline is mandatory: security fixes have arrived reactively (v1.0.1, v2.0.3, v5.0.0), so falling behind is a security position, not just a hygiene issue.

Support

• No vendor support, no SLA, no commercial backing. Internal support model only: owner + on-call escalation to the application team.
• Support burden is heavily policy shaped: most incidents will be "someone edited the wrong file" or "the panel can't see directory X" (a hiddenFolders/basePath/permissions issue), not package defects.
• Document, in the runbook: the configured root, the exact enabled allow* flags per environment, how authorize() evaluates, the shared-password rotation procedure, and where the audit log lives.

Scaling

• Scales fine with number of users (it is just a panel page) and poorly with file count and directory depth — no pagination or indexing is described, so pointing it at a large tree (vendor/, node_modules/, or an unbounded uploads directory) will degrade the UX and possibly the request. Cap the root's size by design.
• Concurrency is unmanaged: two super-admins editing the same file is last-write-wins with no locking or conflict detection. Keep the authorised user set small and prefer read-only mode for most of them.
• Throughput/limits are PHP-bound: upload size, memory for previews, and request timeouts. Treat large media/Excel previews as a capacity item, not a UI detail.

Failure modes

Ramp-up

• Developers: hours. Install is a composer command plus plugin registration; the config surface is fluent and self-documenting.
• Super-admins / operators: under a day of training — but training must cover policy (what may be edited where), not just clicks. Pair it with the retirement of legacy FTP/SSH habits, or both channels persist and the audit story fails.
• The owning engineer: 1–2 days to read the v5 security model (realpath confinement, server-side allow* re-validation, authorize() on each Livewire request) well enough to defend it in a review. This is non-negotiable and should be scheduled, not assumed.
• Onboarding artefact: a one-page runbook (root, flags per environment, authorize() semantics, audit location, restore procedure, exit path) plus the ADR. If those two documents don't exist, the adoption isn't finished regardless of whether the plugin renders.