Filament Browser Laravel Package

Product Decisions This Supports

• Build vs buy for internal operator tooling. This is not a customer-facing capability — it is a privileged operator console rendered inside the admin panel. The decision it replaces is either "build a bespoke file-management screen" or "keep doing it over SSH/FTP." MIT and zero licence cost means the "buy" option is really adopt-and-own, and it should be evaluated as such.
• A feature/scope decision about who gets filesystem power, and where. The product questions this forces are concrete: what is the configured root, which environments allow writes, and who passes the gate. Those are roadmap-shaping answers, not implementation details.
• Roadmap sequencing and staffing. Realistic shape is ~1 day install, ~1 week hardening plus access-model design, and 2–4 weeks of pilot and change management. Frame it as a small internal-tooling epic; a developer's estimate will only cover the first line item.
• A cost-of-ownership decision that needs a budget line, not just an approval. Single maintainer, 43 stars, 0 dependents — the PM decision is whether to fund an internal owner, a fork/vendored copy, and a quarterly upgrade review.
• Success metrics worth committing to up front: reduction in SSH/FTP/ops tickets, time-to-inspect-a-file, and the share of file operations happening in-panel versus out-of-band. These also define what would make us reverse the decision.
• What it should not drive: adopting Filament. If the team hasn't standardised on Filament, a convenience tool is not a reason to change frameworks.

Use cases it credibly supports today: a super-admin checking a log or config-adjacent file, dropping in a media asset, light Markdown/content edits, and previewing images/video/audio/PDF/Excel without leaving the panel. It is not a deployment mechanism, config-management system, or sanctioned path for editing application code in production.

When to Consider This Package

Adopt when all of these hold:

• You already run Filament v5 on Laravel 12/13 with a real admin panel. If you'd have to pin the v3 branch, you're signing up for a divergent, lower-support track — look elsewhere.
• There is a genuine super-admin inspect-and-lightly-edit need that today leaks into SSH/SFTP/CLI.
• You can narrow basePath() to a designated sandbox (e.g. storage/app/browser or a content directory) rather than base_path().
• You will keep production read-only by default, with writes confined to staging/pre-prod.
• You will implement authorize() (SSO group + environment tag + time window). The shared DEVELOPER_GATE_PASSWORD in .env is defence-in-depth only, never the primary control.
• You will add external audit logging and snapshot/backup coverage of the root before enabling delete or overwrite — the package ships neither, nor any undo/recycle bin.
• A named individual accepts the single-maintainer dependency in writing, with a documented exit path (fork, vendor, or replace with Forge / IDE remote-SSH).

Look elsewhere when:

• The service is headless/API-only, S3- or cloud-only, or multi-tenant with per-tenant filesystem isolation requirements.
• Policy categorically prohibits in-app filesystem writes.
• You need compliance-grade audit, versioning, or undo out of the box — that's a DAM, Forge, or remote-SSH workflow, not this.
• The requirement is actually customer-facing media management (use a dedicated media/DAM library).
• The organisation needs a vendor SLA. Zero dependents and 43 stars means no peer validation to borrow; if procurement demands support, this isn't it.

How to Pitch It (Stakeholders)

One-line summary: A free, MIT-licensed plugin that adds a file browser with a built-in code/Markdown editor and media previews to our existing Filament admin panel — replacing ad-hoc SSH/FTP with one in-panel surface for super-admins, provided we invest in the controls it doesn't ship with.

For executives: The install is cheap (~1 day) and legally frictionless. The real spend is governance, not engineering: named owner, environment scope, and access model. Adoption signal is thin — one maintainer, zero dependents — so the honest framing is "adopt and own," with a funded exit path. The payoff we'd measure is fewer ops tickets and faster file inspection, not a new revenue capability.

For engineering: Mechanically trivial — composer require, one install command, register the plugin with fluent config. The work is hardening. v5.0.0 already confines every operation to the configured root (realpath checks, rejection of .., absolute paths, null bytes, symlink escapes) and re-validates the allow* flags server-side. But there is no audit trail, no undo, and the gate defaults to a shared env password, so authorize() must carry the real access control and we must wire logging ourselves. Also gate the upgrade: v5 removed the legacy JSON route/controller/JS bundle, swapped in Filament's native CodeEditor, and hides .env by default — grep for the removed route and audit any published view overrides before bumping.

The ask: Approve a scoped pilot — narrow sandbox root, staging-write / production-read-only, authorize() implemented against SSO, external audit logging in place, a named owner, and a written fallback. If any of those five can't be committed, the recommendation is to defer and keep the current out-of-band workflow.