Filament Attachment Library Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side asset management. This package answers a recurring question — "do we build a media/attachment manager for our Filament panel, or adopt one?" — with a low-cost "buy" (MIT, Composer install, one install command). It shifts engineering effort from file handling, upload UI, and browsing to product-specific concerns like collections, permissions, and content workflows.
• Scope decision: a media library vs. a media field. The package does attachment upload/browse plus a form field, not a full Digital Asset Management system. That framing is the product decision: adopt it as the picker/uploader embedded in domain forms (product gallery, featured image, document sets), and keep tagging, search, and cross-team asset governance out of scope for v1.
• Roadmap de-risking for image presentation. Features already shipped — focal point picker, Glide-based scaling, a Blade image component, and collection filtering via attachmentCollection() — cover a meaningful slice of "image quality on the storefront/CMS" work without bespoke implementation. Focal point in particular removes a common backlog item (hero/card cropping looks wrong).
• Data-model choice surfaced as a product question. The field can store attachments in a single model column or via the HasAttachments trait with named collections (gallery, product_gallery). That is a decision with downstream consequences for content reuse, migrations, and reporting — worth making explicitly rather than letting it default.
• Editor UX investment. Move/replace attachment, directory browsing with loading states, and multi-file drag-and-drop are the "does the CMS feel finished?" features that drive internal adoption and reduce tickets to engineering.

When to Consider This Package

Consider it when:

• You are already on Filament (panel admin UI) and need attachment/image upload, browsing, and reuse inside forms — not a standalone DAM.
• You can accept a custom Filament theme requirement. The package's Blade views are TailwindCSS-based, so you must generate a theme (make:filament-theme), add an @source line pointing at the vendor path, and register the theme (with a Vite-specific variant). That's real, recurring build coupling: forget the @source line or rebuild the theme after an upgrade and you get unstyled UI.
• You can dedicate an isolated storage disk (ATTACHMENTS_DISK). The docs explicitly advise a disk with no other files — a clean but non-negotiable operational constraint.
• Your attachment needs are generic (images, documents, collections) and you benefit from Glide-based resizing rather than maintaining your own transform pipeline.

Look elsewhere / delay when:

• You need enterprise-grade asset management: taxonomy, full-text search across assets, versioning, rights/licensing, per-asset audit trails, or cross-tenant isolation. This is not that product.
• Ecosystem maturity and bus factor matter more than speed. 11 stars, zero dependents, and a single-vendor (Van Ons, an agency) maintainer profile mean limited community validation. There is active maintenance — security-hygiene fixes, MIME enforcement on dropped files, Filament version compatibility docs, and both a v1 and v2 line receiving backports — which is reassuring, but you are effectively an early adopter.
• Accessibility, alt-text authoring, and virus scanning are hard requirements; they aren't evidenced in the docs, so assume you own them.
• Your stack isn't Filament, or you're pinned to a Filament major the compatibility matrix doesn't cover.
• You need private/signed-URL asset delivery as a first-class feature; disk config alone suggests you'd be building that layer.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed Filament add-on that gives our admin panel turnkey file and image handling — upload, browse, reuse across records, image resizing, and focal-point cropping — for roughly the cost of an install command instead of a sprint of engineering. It removes a category of "we need a media manager" work from the roadmap and lets us spend that capacity on customer-facing features. The trade-off is concentration risk: it's a small, single-vendor open-source project with a modest user base, so we should treat it as a leveraged dependency rather than a foundation, and budget a modest maintenance allowance.

To engineering: Install via Composer (^2.0), run the install command for migrations/assets, and treat the custom Tailwind theme as a first-class build artifact — @source the vendor Blade path, register the theme (or ->viteTheme(...) under Vite), and add a rebuild step to the upgrade checklist. Point ATTACHMENTS_DISK at a dedicated disk. Choose deliberately between column storage and the HasAttachments relationship plus named collections, and add convenience relation methods (attachmentCollection('gallery')) so collection filtering stays readable. Track the Filament compatibility matrix when planning upgrades, and note that the JS bundle republishes via Filament's filament:upgrade hook — apps without it must run filament:assets manually, which is a silent-breakage vector. Pin the version, read the changelog on each bump, and wrap the field in our own thin form component so a future swap stays contained.