Laravel Better Temporary Urls Laravel Package

Product Decisions This Supports

• Expiring, gated access to private assets — signed/temporary URLs are the standard mechanism for time-boxed downloads (reports, invoices, exports, media) without exposing storage paths or requiring a full auth stack on the asset host.
• Build vs. buy for URL signing — Laravel ships URL::temporarySignedRoute() and URL::signedRoute() in core. This package only earns a dependency slot if it solves something core does not (e.g. invalidation/revocation, storage-driver-agnostic handling, custom expiry semantics, richer payload binding). The 2.0.0 notes don't add capability, so the buy case is unchanged and remains narrow.
• Roadmap timing for framework upgrades — the only change here is Laravel 9 support. That makes this release an input to your platform upgrade plan, not your product roadmap: it unblocks Laravel 9 adoption for any team already depending on the package, and it's a hard blocker for teams still on Laravel 8.
• Feature scoping for share/invite flows — if "shareable link with expiry" is on the roadmap (public dashboards, client deliverables, one-time invite links), decide early whether that's signed-URL plumbing or a first-class product feature with revocation, audit, and access logging. Signed URLs alone rarely satisfy enterprise security review.
• Not a differentiator — nothing here changes user-facing capability. Treat it as infrastructure hygiene, not a product bet.

When to Consider This Package

Adopt when:

• You are on Laravel 9 (this release is what makes that possible) and need temporary URL generation beyond a thin wrapper around core helpers.
• You need behaviour core doesn't provide — most commonly revocability or single-use semantics — and you've confirmed this package implements it rather than just sugar-coating temporarySignedRoute.
• You want the signing logic isolated from your application code so the storage backend can change without touching controllers.
• Your usage is bounded: a handful of download/export endpoints where a bug is contained.

Look elsewhere (or just use core) when:

• You only need URL::temporarySignedRoute(). Adding a third-party dependency for a one-line wrapper is negative value.
• You need enterprise-grade link governance: per-link revocation lists, access auditing, IP/UA binding, download limits. None of that is evidenced here — build it or buy a mature product.
• Maintenance risk is a blocker. Evidence in this release: a 0.x → 2.0.0 jump with a single change, one first-time contributor, no deprecation notes, no migration guide, no security or bug fixes. That is a very thin signal of active stewardship. If this package sits in a security-adjacent path (it signs URLs), require a documented upgrade guide, a supported-version policy, and a security contact before committing.
• You are on Laravel 8 or below. 2.0.0 is almost certainly a breaking bump that drops older framework/PHP support (Laravel 9 requires PHP 8.0+). Do not assume 0.5.0 behaviour carries over — pin explicitly and read the diff before upgrading.
• You need a stable API contract across a long release cycle. A package that skips from 0.5 to 2.0 with no interim releases has not demonstrated semver discipline.

How to Pitch It (Stakeholders)

For executives (one line): A small open-source library for generating expiring links to private files now supports Laravel 9 — this is an infrastructure compatibility release that unblocks our framework upgrade; it adds no new product capability, and it carries a maintenance-risk caveat worth noting.

For engineering leads:

• This is a breaking major version (0.5.0 → 2.0.0) whose only stated change is Laravel 9 support. The major bump implies dropped support for earlier Laravel/PHP versions. Treat as a migration, not a patch: review the diff, run the full suite, verify signed-URL formats haven't changed, and confirm behaviour for links already issued and in flight (existing signed URLs must not silently start 403ing).
• Before upgrading, answer three questions: (1) Does it still support the Laravel version we run today, or does this force a coordinated framework upgrade? (2) Is there a documented upgrade path, or are we reverse-engineering it from a one-line changelog? (3) Is the package on a security-sensitive path, and if so, who is our escalation contact?
• Evaluate the dependency itself. With one contributor, no deprecation notes, and no migration guide, the honest alternative is to vendor the ~small amount of signing logic in-house and own it. That trade is usually worth it for code this size on a security-adjacent path.
• If we adopt: pin the exact version, add a signed-URL round-trip test (generate → follow → assert expiry rejection) so a future silent bump fails CI rather than production, and track the package in our dependency-risk register with a re-review date.
• Recommendation: proceed only if we already depend on it or have a concrete need core helpers don't meet; otherwise use URL::temporarySignedRoute() and revisit.