Nova Video Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side video handling. This is a ready-made Laravel Nova field: upload, replace, inline preview, cover-image management, and FFmpeg-backed conversion inside the admin panel the team already uses. The buy-side alternative is roughly 1–3 sprints of undifferentiated work — chunked uploads, progress UI, poster extraction, cleanup on delete, validation — for a component that will never be a differentiator. At Apache-2.0 with zero license cost, the build-vs-buy call is easy; the real decision is whether you accept the maturity tradeoff below.

• Roadmap framing: is video a format your team manages, or a product surface you deliver? If the backlog item is "let marketing/ops upload product, course, or onboarding videos from the admin," this closes the tooling question cheaply and completely. It does not decide whether video belongs on the roadmap at all — hosting cost, moderation, retention, and support burden remain strategy calls. Keeping those two questions separate in the plan is the highest-leverage thing a PM does here, because "and then it streams to customers" is the default scope-drift path.

• Transcoding architecture: self-hosted FFmpeg vs. managed service. This package is a thin Nova presentation layer over mostafaznv/laravel-video, which requires an FFmpeg binary, queue workers, a dedicated worker pool, and a storage disk. Adopting it is an implicit, hard-to-reverse commitment to keeping transcoding in-house rather than offloading to Mux, Cloudflare Stream, or MediaConvert. Put that consequence in the decision record now — it is far cheaper to decide than to retrofit once assets and editor workflows accumulate.

• Who gets to manage video. A native Nova field means content editors and ops can upload and swap videos without a deploy or a ticket. That changes the support model and gives you a testable acceptance criterion — "an editor can publish a video without engineering involvement" — instead of a vague capability statement. It also shrinks the queue of small media requests that quietly consume engineering time.

• Storage, egress, and compute budgeting. A video field is where infrastructure cost arrives quietly and stays. Adoption commits you to storage growth, egress bandwidth, queue capacity (FFmpeg pins a core per concurrent job), and the operational overhead of a media reconciliation job. Model those line items before the feature ships, not after the first invoice.

• Risk acceptance, explicitly. 22 stars, zero known dependents, a single maintainer, and a hard dependency on Nova's frontend asset pipeline. This is a low-adoption, single-maintainer dependency for an admin-critical surface. That is an acceptable risk for internal tooling and an unacceptable one for a revenue path. Say which one you're choosing in the ADR, and pair adoption with the mitigations below.

When to Consider This Package

Adopt it when most of these are true:

• Laravel Nova is already your admin stack and the team is comfortable owning Nova upgrades (field packages break across Nova majors, and there is no upstream obligation to support your version).
• Video is internal-facing or lightly public — product pages, course lessons, onboarding, internal training — not a streaming product with DRM, adaptive bitrate, per-viewer analytics, or aggressive latency goals.
• You have, or will fund, the operational prerequisites: PHP 8.1+ with fileinfo/gd/imagick, FFmpeg + ffprobe on the PATH of PHP-FPM and the worker user, a real queue backend with a dedicated media worker pool and tuned timeouts, and a persistent disk (local + storage:link in dev, S3/CDN in prod).
• Volume is modest and predictable. A handful of uploads per week is a very different operating model than thousands per day.
• You will wrap it. A thin MediaService/VideoPresenter between your domain and larupload is the single highest-value line of architecture here — an afternoon of work that turns a future move to a managed platform into one contained change instead of a grep-and-pray migration.
• You will pin the exact package and Nova versions in the lockfile and record the pin, and add a CI smoke test that the field actually renders after any Nova upgrade (a silent failure here looks like a blank form, not an exception).

Look elsewhere when any of these are true:

• The video is customer-facing at scale, or needs ABR/HLS, DRM, captions pipelines, or playback analytics. Go managed (Mux, Cloudflare Stream, MediaConvert) and skip the in-house transcode farm entirely.
• Nobody on the team owns PHP/Laravel infrastructure — no queue workers, no Supervisor/systemd, no appetite for diagnosing "FFmpeg not found as www-data."
• You're not on Nova, or you're on a Nova version you don't control the upgrade cadence for. The field is a UI over larupload config; if you don't own the admin framework, you don't own this.
• The feature is speculative. If video is a "maybe next year," the honest answer is a URL field today and this package when the demand is real.
• You need multi-tenant isolation, rights management, or moderation workflows out of the box. None of that is in scope here, and bolting it on erases the build-vs-buy savings.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source component that lets content editors upload and manage videos directly in the admin panel we already run, instead of filing engineering tickets for every media change. It replaces an estimated 1–3 sprints of custom work with roughly a day of integration plus modest ongoing infrastructure cost. The strategic question it forces — and this is the value — is whether we're storing video for internal use (cheap, appropriate, this package fits) or delivering video as a customer product (expensive, needs a managed streaming vendor, this package is not the answer). We should answer that before we commit, because the tooling choice is hard to reverse. Risk is manageable: the package is permissively licensed and isolated behind a thin internal wrapper, so a future swap to a managed provider is a contained change rather than a rewrite.

For engineering: A Nova form field over mostafaznv/larupload and mostafaznv/laravel-video. The field itself is presentation only; all storage paths, naming, conversions, and cover generation live in model/config so non-Nova upload paths behave identically. Three things must be true before we merge: FFmpeg is baked into the runtime image and verified as the www-data and worker users; transcodes run on a dedicated media queue with timeouts and retry_after set correctly and --tries=1; upload limits are aligned across php.ini, nginx, and any load balancer. We own cleanup, a weekly media:reconcile command for orphaned files, cover regeneration on replace, and S3 CORS/visibility policy. Pin the package and Nova versions, add a render smoke test to CI, and keep the swap surface to one adapter class.