Filament Image Library Laravel Package

Product Decisions This Supports

• Build vs. buy for media handling. The package targets a narrow, common CMS gap: editors re-upload the same hero/banner/logo image onto every record because the form field is record-scoped. A shared "upload once, pick many" library removes that duplication. That is a build-vs-buy decision worth pricing explicitly — a first-party version is typically 3–8 dev days plus ongoing maintenance, so a MIT package is a credible "buy" (adopt) even at low maturity.
• Editorial workflow and content-ops roadmap. Supports decisions like: do we need a lightweight DAM (digital asset management) layer, or just a picker? If your roadmap is "fewer steps for content editors, consistent imagery across pages, one place to update a shared asset," this is scoped correctly. If the roadmap says "rights management, renditions, per-channel approvals," it is not that product and shouldn't be stretched into one.
• Feature sequencing for an admin panel. Fits naturally into a phase where you're closing gaps in a Filament admin (content models, SEO fields, alt text) rather than rebuilding the CMS. Useful as a cheap enabler for later features: alt-text discipline, image reuse analytics, "where is this image used?" cleanup.
• Storage and cost hygiene. Duplicate uploads inflate object storage and CDN bills and make brand updates a per-record chore. A shared library converts a recurring operational cost into a one-time integration cost — a defensible line item.
• Reuse/governance policy. Forces a product answer to "who may add to the library, who may delete, and what happens to the 40 records pointing at a deleted image?" That policy decision matters more than the package itself.
• Exit and dependency strategy. 24 stars, 0 dependents, single-vendor maintenance: the PM decision is not only "adopt or not" but "adopt behind an internal abstraction (our own form field / model) so we can swap it in a sprint, not a quarter."

When to Consider This Package

Consider it when most of the following hold:

• You run a Filament admin panel and the pain is concrete: editors upload the same assets repeatedly, or brand-wide image swaps require touching many records.
• Your asset scope is images only — hero shots, thumbnails, logos, editorial photos. No video, no PDFs, no per-market renditions.
• The team is small and internal (a handful of editors); a full DAM (Bynder, Cloudinary DAM, Brandfolder) is overkill on price and process.
• You need a picker UI in a form, not an asset-lifecycle product, and you can accept the package's model for storage, thumbnails, and deletion.
• You're willing to pin the version, read the source, and own the fork if upstream goes quiet. MIT makes that legally and practically fine.
• You can verify before committing: Filament major-version compatibility, storage disk/visibility config, multi-tenancy and policy hooks, whether deleting a library image is blocked or warned when in use, alt-text/localization fields, and whether it plays nicely with an existing media package (e.g., Spatie Media Library) or duplicates it.

Look elsewhere (or build) when any of these are true:

• You need usage tracking and safe deletion out of the box — shared assets without reference counting are a production incident waiting to happen.
• You need video, documents, or rich metadata (rights, expiry, credits, per-locale alt text, focal-point/crop per usage).
• You need multi-tenant isolation, granular roles, or approval workflows on the library itself.
• Asset delivery is a performance concern — you want on-the-fly transformations and a CDN pipeline (Cloudinary/imgix/Glide) rather than stored thumbnails.
• You're on a Filament version or PHP/Laravel combination the package doesn't declare support for, or you require vendor SLAs / long-term support — 24 stars and zero dependents means no ecosystem safety net.
• Your image needs are trivial (one image per record) — you'd be adding a dependency and a data model for no benefit.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed add-on for our admin panel that lets editors upload an image once and reuse it everywhere, instead of re-uploading the same file per page. Expected value is operational: less editor time, fewer duplicate assets in storage, and one place to swap a shared brand image. Cost is low and reversible — the license is free and the integration is days, not weeks. The trade-off is maturity: it's a young, single-maintainer project with almost no public adoption, so we treat it as a component we own, not a vendor we depend on. Recommendation: pilot it on one content type, wrap it behind our own field so we can replace it, and revisit in a quarter.

For engineering: Adopt it as a thin, replaceable layer. Pin the version, read the migration and deletion behavior first, and confirm Filament version support before writing any UI against it. Two must-haves in review: (1) deletion of a library image must be blocked or explicitly confirmed when referenced, and (2) the picker must sit behind our own form-field/model wrapper so an upstream stall costs us a swap, not a rewrite. If usage tracking, multi-tenancy, or non-image assets are on the near roadmap, flag it now — that's the point where we stop treating this as a picker and start scoping a real media layer.