Nova Filemanager Laravel Package

Product Decisions This Supports

Build vs. buy for admin file management. The decision that matters here is small and real: do we spend engineering days constructing a bespoke Nova file browser, or do we install a package that already gives editors upload, folder creation, rename, move, copy, delete, search, multi-select, and image preview? For a non-differentiating internal capability, the buy side of that ledger is clearly cheaper—if the Nova compatibility gate is passed.

Scoping a narrow, reversible content-operations roadmap item. This supports a contained commitment like "editors can manage blog/marketing images and PDFs from the admin panel." It explicitly does not support a strategic digital asset management initiative, a customer-facing document portal, or a library with retention/compliance requirements. If those appear on the roadmap, treat them as a separate initiative with a separate decision; don't let this package become the accidental foundation of one.

Reuse over rebuild for embedded asset pickers. Because the tool exposes nova-vendor/filemanager endpoints, it can back a CKEditor/TinyMCE file-browser button or an iframe dialog for legacy CMS content. Asset selection is a recurring editor workflow, and reusing this backend is a cheap product win—provided the route names are confirmed against the installed version, since they have moved between releases.

A version-gate decision that belongs to product, not just engineering. The last tagged release is 2.8.3 (2020-08-21) and targets the Nova 2/3 asset pipeline. On Nova 4/5 the tool may mount yet render a blank panel. "Which Nova version are we on, and will we fund manual asset publication or a frontend fork?" is a genuine roadmap/ownership question with a real (roughly one-day) cost attached.

Risk posture for a low-adoption dependency. 218 stars, zero listed dependents, and a single patch release in 2020 mean observable production adoption is unproven. Adopt as a time-boxed pilot or a fork candidate with a named owner—never as a default strategic component.

Multi-tenancy is a product boundary, not a config detail. Per-user and per-tenant scoping is not built in. In a multi-tenant product, the default behaviour exposes every tenant's files to every tenant. Scoping must be designed and implemented before the first customer is onboarded, not retrofitted.

Security decisions worth making explicitly. Extension allow-lists are the only upload guard, and the media disk must not be web-executable. A .php upload into a served directory is a remote shell. This shapes both the architecture and the review checklist.

Backup policy as an operational commitment. There is no trash and no versioning; deletion is permanent and immediate. Adopting the tool implies committing to a nightly backup of the media disk and a scheduled cleanup of abandoned temp uploads, on day one.

When to Consider This Package

Consider it when:

• The product already runs on Laravel Nova, and the requirement is internal-only file management—upload, browse, rename, organize, preview—for operators or a content team.
• You have proven in a scratch environment that the tool renders, uploads land on disk, and thumbnails resolve on your Nova version. Three checks, done before any production wiring.
• Engineering will point it at a dedicated disk rooted at a specific folder (e.g. storage/app/public/media), making path traversal a non-issue by construction rather than by validation.
• canSee() gating plus a policy provides the real authorization boundary, and someone has reviewed extension allow-lists and the web-executability of the disk.
• Versions can be pinned exactly (2.8.3, not a caret range) and the team accepts that upgrades are migrations.
• A nightly backup substitutes adequately for the missing trash can and versioning.
• The alternative is a small custom Nova tool, and speed genuinely matters more than long-term package maintenance.

Look elsewhere when:

• You need vendor support, an SLA, a release cadence, or confidence in current Nova/Laravel/PHP compatibility. One 2020 patch release does not imply a roadmap.
• The use case is customer-facing, multi-tenant, regulated, or needs audit logs, fine-grained permissions, virus scanning, or retention.
• File management is a product differentiator rather than an admin convenience.
• The team cannot house a fork with a named maintainer, or cannot accept a low-adoption dependency.
• You depend on S3 semantics you have not verified—uploads and listings generally work through Laravel's filesystem abstraction, but signed-URL generation for private buckets and rename() behaviour on non-local drivers need explicit testing.

Before adoption, get written answers to: which Nova, Laravel, and PHP versions are tested; which disks are in scope (local only, or S3-compatible/SFTP); who owns the fork if the package stalls; and what the fallback plan is on Nova 4+ if asset registration fails.

How to Pitch It (Stakeholders)

To executives: This is a small, reversible convenience purchase, not a platform bet. It embeds a file browser in our existing admin panel so content editors can upload and organise images and documents without us building that UI. It costs effectively nothing under MIT and saves days of internal tooling work on a capability that doesn't differentiate us. The trade-off is honest: the package has been quiet since 2020, so we're adopting it as a time-boxed pilot with a named internal owner, pinned to an exact version, and a nightly backup in place of the undelete feature the tool lacks. If it breaks, we fall back to a small custom tool—the sunk cost is days, not quarters.

To engineering: You get a Finder-style tool over any Laravel filesystem disk, plus REST endpoints at nova-vendor/filemanager that we can reuse for a CMS picker. Three things to prove on day one in a scratch environment: does the tool render on our Nova version, do uploads actually land, do thumbnails resolve. If any of those fail on Nova 4+, you're in fork-and-rebuild-the-frontend territory—budget a day and tell us before it's wired into anything. Point it at a dedicated disk rooted at the media folder, so path traversal is prevented by the filesystem driver rather than by our validation. Add canSee() for the UI and a policy for real enforcement. Lock down extension allow-lists and confirm the media disk isn't web-executable. Expect some sharp edges: config caching will make you think it's broken when it isn't, a missing storage:link explains most "uploads succeed but images 404" reports, and large-upload failures are usually one of the three separate size limits (PHP, Nginx, WAF) surfacing as a generic 500 rather than a friendly error. Store paths through a Media model, not raw strings on content tables, or a rename will silently break someone's article. We're pinning 2.8.3 and treating any bump as a migration.