Laravel Documentable Laravel Package

Product Decisions This Supports

• Build vs. buy for document attachment. This package covers the "attach many documents to any Eloquent model" problem — polymorphic file attachments, storage abstraction, and S3-style direct uploads — so the team does not have to build and maintain that plumbing in-house. That is a scoping decision worth making explicitly before it gets rebuilt ad hoc in three different features.
• Storage architecture and cost model. It supports large-file uploads via multipart presigned URLs, which pushes upload bandwidth off our application servers and onto object storage. That is a real infrastructure cost/performance lever, not just a convenience.
• Access-control and expiry policy. v2.1.2 is a focused fix: multipart part-upload presigned URLs now respect the temporary_url configuration. Practically, this means the link-expiry policy we configure is now applied consistently across upload paths instead of being silently bypassed for multipart uploads. That is a security-hygiene and compliance-relevant behavior, and it removes a class of "why do some upload links behave differently?" support tickets.
• Roadmap de-risking. If document handling is on the roadmap (contracts, invoices, KYC/identity documents, customer-uploaded evidence, media libraries), adopting this narrows the backlog to product-level concerns — who can see a document, retention, review workflows — instead of file-mechanics work.
• Upgrade posture. This is a patch release with no API changes, no migrations, and no deprecations. It should not consume roadmap capacity, and it should not trigger a re-evaluation of the buy decision.

When to Consider This Package

Consider it when:

• The application is Laravel and documents need to hang off multiple models (users, orders, projects, claims) rather than a single entity.
• Users upload large files where direct-to-storage multipart uploads materially improve reliability and reduce server load.
• We need time-limited, signed access URLs rather than public file links — and we want one configurable expiry policy honoured everywhere (the gap v2.1.2 closes).
• The team is small and file-handling infrastructure is not where we want to spend engineering time.
• We can accept a community-maintained dependency and pin it to a minor version (2.1.x) with a scheduled review.

Look elsewhere when:

• We need a full document management system: versioning, OCR/text extraction, virus scanning, thumbnails and transcoding, approval workflows, per-document audit trails, or fine-grained per-document permissions. This package attaches and serves files; it is not a DMS.
• Multi-tenant isolation is a hard requirement — validate tenant scoping in our own layer rather than assuming it.
• Requirements are trivial (one avatar or logo per record), where a single filesystem column and Laravel's built-in storage are simpler and cheaper than a dependency.
• Single-maintainer risk is unacceptable for the data class involved. Assess release cadence, test coverage, and supported Laravel/PHP versions before committing regulated content to it.

How to Pitch It (Stakeholders)

Executives: We are evaluating a small, focused Laravel package to handle document attachments instead of building that layer ourselves — a build-vs-buy call that saves engineering time on a non-differentiating capability. The latest release, v2.1.2, is routine maintenance: it makes large-file upload links correctly honour our configured link-expiry setting. No breaking changes, no migration work, no action required. Recommendation is to stay on the 2.1.x line and take patch updates in the normal maintenance window.

Engineering: v2.1.2 is a one-line-class fix — presigned URLs generated for multipart part uploads now respect the temporary_url configuration, bringing them in line with the single-part upload path. There are no public API, schema, or configuration changes. Two asks: confirm the temporary_url value in each environment reflects the expiry we actually intend (this release makes that setting authoritative for large uploads too), and add an integration test asserting expiry on a multipart upload so a regression here surfaces in CI rather than in a customer report. Keep the dependency pinned and re-review on the next minor.