Filament Media Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for the admin-side asset library. If your roadmap includes "let admins upload, find, and reuse files without bothering engineering," this package is a candidate to buy (MIT, Composer-installable) rather than build. It ships the undifferentiated heavy lifting: hierarchical folders via filament-select-tree, tagging, search/filter/sort, bulk actions, move dialogs, previews, and a media picker modal.
• Feature scoping for a v1 media capability. The feature set maps cleanly to a backlog epic: folder organization, tag-based retrieval, multi-disk configuration, single vs. multiple attachments, table columns, infolist entries, and rich-editor insertion. That's enough to define a release slice without inventing requirements.
• Data model commitment. Adoption means accepting media_files, media_attachments, and tags tables plus a InteractsWithMediaFiles trait on host models, with *_id foreign keys for single-file relations and the package's pivot table for polymorphic collections. This is a schema-level decision that shapes future migrations, API resources, and export/import tooling — decide it before you have thousands of records, not after.
• Storage architecture and security posture. Per-field and global disk support plus public/private URL handling (signed temporary URLs, conversions_disk respect, renderRichContent() for expiring-link resolution) lets you choose between CDN-friendly public buckets and private tenant assets. That's a genuine product decision about content sensitivity, not just a config toggle.
• Multi-tenancy as a launch gate. ->tenantAware() is opt-in and requires an extra migration plus backfilling existing records. If you're building a B2B SaaS with Filament's tenant scoping, this determines whether the media manager is usable at all in a multi-tenant panel — plan the backfill and disk-per-tenant story up front, and note the documented caveat that public disk URLs remain publicly reachable even when records are tenant-scoped.
• Rich text / CMS-adjacent use cases. MediaManagerRichContentPlugin on RichEditor plus HasRichContent on models supports marketing pages, knowledge bases, and product descriptions where non-technical editors embed images — a common "we need a CMS" request you can satisfy inside the existing admin panel instead of buying a separate CMS.
• UX trade-off sign-off. The click-to-select / check-icon-or-long-press-for-multi-select behavior is explicitly "under review" upstream (issue #18). If bulk selection is a core workflow for your power users, treat this as an unresolved design decision you may need to override or accept.

When to Consider This Package

Consider it when all of the following hold:

• Your admin panel is on Filament v4 or v5 and you're already committed to that ecosystem — this is a native plugin, not a bolted-on SPA.
• You need structured file management (folders, tags, search) rather than a single FileUpload field on one form. Filament's built-in uploads already cover the simple case; this package earns its place when editors must reuse assets across records.
• You're comfortable taking a dependency on Spatie MediaLibrary plus filament-select-tree — you'll be running their migrations and inheriting their upgrade cadence.
• You have a plan for private assets and, if applicable, tenancy before go-live, including assigning pre-existing records to a tenant.
• You accept vendor risk: 21 GitHub stars, zero dependents, a single-maintainer-looking project, and a very recent release date. Budget for the possibility of forking or absorbing maintenance.

Look elsewhere or build in-house when:

• You need a mature, battle-tested DAM with audit trails, rights management, versioning, and workflow approvals — this is a folder browser with tags, not a governance system.
• You're not on Filament, or you're on an older Filament version with no upgrade path.
• You need guaranteed API stability or a support contract. There's no commercial backing evident; changelog and releases exist but the community surface is thin.
• You need video transcoding pipelines. Video thumbnails require FFMPEG on the host, and transcoding/adaptive streaming is out of scope.
• You need cross-tenant or public asset sharing with per-asset ACLs. Tenant scoping is record-level; the package docs themselves warn that public disk URLs bypass it.
• Your team is unwilling to own a fork. Zero dependents means you're among the first production users — expect to debug edge cases the README doesn't cover.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed plugin that gives our Filament admin panel a full media library — folders, tags, search, bulk actions, and a picker we can drop into any form — in days instead of the several weeks a custom build would take. It slots into our existing stack (Filament + Spatie MediaLibrary) with no new infrastructure, supports both public CDN assets and private signed-URL assets, and can be scoped per tenant for our B2B customers. The trade-off is maturity: it's a young, small-community package, so we should treat it as a fast first version with a plausible fork-and-own path, not as a decade-long vendor commitment. Recommend a timeboxed spike plus a documented exit plan.

For engineering: Native Filament v4/v5 integration — MediaManagerPlugin registration, MediaPicker form field, MediaColumn, MediaImageEntry/MediaFileEntry infolists, and a RichEditor plugin with renderRichContent() to solve expired signed URLs at render time. Adoption requires publishing the package and Spatie migrations, adding the InteractsWithMediaFiles trait and foreign keys for single-file relations, and a custom theme import plus @source directive if we use a custom Filament theme. Multi-tenancy is opt-in via an extra migration and ->tenantAware(), with a pluggable tenant resolver and column name. Known watch items: multi-select UX is under upstream review (#18), video thumbnails need FFMPEG, and the project has one apparent maintainer with zero dependent packages — so pin versions, keep the config published in-repo, and avoid patching vendor code so we can fork cleanly if upstream stalls.