Laravel Tus Upload Laravel Package

Product Decisions This Supports

• Build vs. buy for upload infrastructure. This package implements the TUS resumable upload protocol server-side inside a Laravel app, so "how do we handle large file uploads?" becomes a package adoption decision rather than a multi-sprint protocol build. Relevant whenever uploads are a meaningful part of the product (media libraries, video ingestion, document/asset management, data imports).
• Reliability and support-cost reduction. Resumable, chunked uploads directly reduce failed-upload tickets, abandoned onboarding flows, and re-upload complaints on flaky mobile networks — a measurable metric you can attach to the roadmap item.
• Platform baseline / upgrade planning. v0.11.0 adds Laravel 9 support and drops PHP ≤ 7.4. This is a hard compatibility signal: adopting it now commits your upload surface to PHP 8.0+ and Laravel 9. If any part of your fleet is still on PHP 7.4, this release either forces a platform upgrade or rules the package out for now.
• Self-hosted vs. managed trade-off. Because the protocol terminates in your app, you own the storage backend, auth, validation, and cleanup. That is attractive if you must keep files in your own infrastructure (data residency, compliance), and less attractive if you already have presigned/multipart object storage flows.
• Version risk on the roadmap. At 0.11.0 this is still pre-1.0 with a single primary maintainer; a release that changes supported PHP/Laravel versions in a minor bump is a signal to budget for upgrade work each time you move your framework version.

When to Consider This Package

Adopt when:

• You are on (or moving to) Laravel 9 and PHP 8.0+ and want spec-compliant resumable uploads without writing the protocol yourself.
• Large or long-running uploads are core to the UX (video, audio, CAD/design files, big CSVs) and failure/retry handling is currently ad hoc.
• You need uploads to land in your own storage/app with your own auth, middleware, and validation rules.
• Your team is small enough that maintaining a bespoke chunking implementation is a worse use of time than integrating a package.

Look elsewhere when:

• You are pinned to PHP 7.4 or Laravel ≤ 8 — v0.11.0 no longer supports you; stay on 0.10.x with a documented migration deadline, or pick another route.
• You need edge/CDN-terminated uploads or very high concurrency — a dedicated tusd deployment or a managed service (cloud storage multipart/presigned, a media platform) will scale better than in-app PHP request handling.
• You already have a working presigned-S3 multipart flow; the marginal gain may not justify a new dependency and a second upload path.
• You require API stability guarantees and long-term support commitments; 0.x versioning plus framework-version churn in minor releases means pinning versions and reviewing changelogs on every upgrade.
• Your stack isn't PHP/Laravel.

How to Pitch It (Stakeholders)

To executives: This gives us resumable, chunked file uploads — the thing that stops users losing a 2GB upload when their connection drops. It's open source, self-hosted, and removes a build effort from the roadmap, so the cost is integration time plus ongoing version upkeep, not licensing. The current release is a compatibility milestone: it aligns us with Laravel 9 and requires PHP 8.0+, so it should be sequenced with (or after) the platform upgrade, not before.

To engineering: TUS-compliant endpoint for Laravel, MIT-licensed. v0.11.0 adds Laravel 9 support and drops PHP ≤ 7.4 — treat that as a breaking platform constraint; pin the version, verify our PHP baseline first, and review the storage/middleware configuration and file-cleanup behavior before rollout. It's pre-1.0 and lightly maintained, so plan for periodic upgrade reviews rather than assuming drop-in stability; if scale or edge termination becomes a requirement, the exit path is a standalone tusd or managed storage multipart.