davidpiesse/nova-audio
A Laravel Nova field for working with audio files. It provides an easy way to upload, store, and preview audio in Nova resources, with a built-in player for listening to uploaded tracks directly from the admin panel. Ideal for podcasts, music, voice notes, and other audio content.
Framing the real build-vs-buy question. For an admin-panel audio upload with inline preview, the choice is not "add a dependency vs. write infrastructure." It is "fork ~200 lines of reference implementation vs. spend 2–5 engineer-days designing the same thing." This package is a presentation-layer field on top of Nova — a paid, closed-source admin panel we already license — so it carries no strategic weight. The PM decision is to treat it as a reference implementation and a scoping instrument, not a dependency to adopt on faith.
Sizing "audio in the admin MVP" honestly. Stakeholders hear "audio" and assume media pipeline. This package demonstrates that "operator can upload a file and hit play before publishing" is hours-to-days of work, not a sprint. That lets you include the feature in a small release instead of letting it inflate the roadmap or get deferred by default.
Forcing the storage and delivery ADR early. Wiring this field forces four decisions that outlive the field itself: which disk, which path layout, which validation rules, and — critically — public URL vs. signed URL. Audio is typically the dominant storage and egress line item in any app that has it. That is a billing and infrastructure decision that should be written down once and inherited by every subsequent image and video field. Do not let it get made implicitly in a pull request.
Testing a concrete requirement bar. Use cases that fit: podcast/episode management, e-learning lesson audio, IVR and voice-prompt libraries, call-recording review queues, voice-note ingestion for transcription, sound-effect catalogues — anywhere a human must confirm the correct asset landed. The bar is precise: one file per record, preview inline, internal audience. Features that disqualify it immediately: multi-file, ordering, waveforms, duration display, transcoding, transcript association.
Calibrating vendor-risk posture for internal tooling. This is a clean, low-stakes precedent case for how the team treats abandoned micro-dependencies in non-customer-facing surfaces. Make the standard explicit: internal admin tools can tolerate more vendor risk than customer-facing code — but "internal" stops being a defence the moment a client sees the screen or the audio is regulated.
Budgeting stewardship explicitly. One maintainer, zero dependents, no release since April 2020. Adoption means a named internal owner, roughly one day per Nova major upgrade, and a CI job that boots Nova with the field registered so upgrades fail loudly. Put that on the roadmap as a line item, or don't adopt.
Scoping accessibility and compliance before it becomes retrofit. A thin wrapper around <audio> ships no captions, no transcript association, and no controls beyond the browser default. If the audio is health, education, or call-recording data, those obligations land on us. Better to price them now.
Consider it — as a fork to vendor, not as a floating Composer dependency — only when all of the following hold:
nova-components/ or an internal namespace, pin the commit, and own the tests.Look elsewhere, or build in-house, when:
Default recommendation: conditional reject of the package as a dependency; adopt its approach as an in-house field. Two to three engineer-days with nova:field scaffolding removes the third-party surface entirely, and the functionality is far too small to justify carrying an unmaintained dependency into a commercial admin panel we already pay for.
To executives. This is a small, free, open-source component that adds audio upload and inline playback to our internal admin panel — roughly one to two developer-days of custom UI work we would otherwise spend. No licence cost, no customer exposure, no strategic dependency, and it blocks nothing on the roadmap. The caveat is stewardship: the project was last updated in 2020 and has a single maintainer, so we would copy the approach into our own codebase rather than depend on it — which costs about the same as adopting it and leaves us owning something we understand. Recommendation: use it as a reference, ship our own version, and treat the storage/egress policy for audio as a separate decision with a real budget attached.
To engineering. It's a Nova File field with an <audio> tag glued on — under a few hundred lines. Its actual contract is "upload to a disk, write the path into a string column," so it composes with everything else normally. The costs are all in the edges, and they are ours: Nova 4/5 compatibility, MIME allowlisting via ->rules(), upload ceiling alignment across PHP and Nginx (413s fail opaquely and users lose uploads), signed URLs if the disk isn't public, and orphan cleanup on record delete. Vendor it, pin it, wrap it in a project-default field class, and add a CI job that boots Nova with it registered so a Nova upgrade breaks in CI instead of silently in production.
How can I help you explore Laravel packages today?