daun/statamic-mux
A Statamic addon that integrates Mux video: upload and manage assets, generate playback IDs and thumbnails, and embed responsive Mux players in your content via a dedicated fieldtype and Antlers tags.
Architecture fit
daun/statamic-mux is a Statamic addon, which in practice means a Laravel package that registers a service provider, publishes config, and contributes at least one custom fieldtype plus a matching Antlers tag (and likely a Blade component) to render the embed. That shape is idiomatic for Statamic: video becomes a first-class content field rather than a URL pasted into a Bard block, editors pick an asset in the control panel, and templates resolve a playback ID at render time. The package does not store video in Laravel's filesystem or public/; it delegates encoding, storage, and delivery to Mux's ingest/CDN. For a TPM, that is the right boundary: the addon owns CMS-side metadata and rendering, Mux owns transcoding and delivery. The architectural coupling is therefore low at the infrastructure layer and moderate at the content-model layer — playback IDs and asset IDs get persisted as field data, so content portability depends on how cleanly those are represented.
Integration feasibility
Feasibility is high for a team already on Statamic. The work is mostly configuration: Mux API token ID and secret in .env, a published config file, fieldset wiring, and a webhook endpoint for asset-readiness events. The real integration risk sits in the upload path rather than the rendering path. Two designs are possible and they have very different operational profiles: browser-direct upload to Mux (signed upload URL issued by the server) versus proxying the file through PHP. The former is what you want at scale; the latter introduces PHP upload_max_filesize, post_max_size, execution-time, and memory constraints that will bite on anything above a few hundred megabytes. This must be verified from the source before committing, not assumed.
The webhook path also needs scrutiny. Without webhook handling, the field stores an asset that may still be preparing or may have failed, and templates render a broken or empty player with no editor feedback. Confirm whether the addon registers a route, verifies Mux's signature, and updates the stored asset state — and whether that state is visible in the control panel.
Technical risk
The dominant risk is not technical, it is supply-chain. Thirteen stars and a single maintainer (the daun namespace) on a package that would sit directly on the critical path of your public video rendering is a thin support surface. The 18/100 composite score corroborates that: low community signal. Bus factor is one. There is no vendor SLA, no paid tier, and no obvious second maintainer. The mitigating factor is that the package is thin — a service provider, a fieldtype, a tag, a webhook controller — and the underlying Mux PHP SDK is doing the heavy lifting. A competent Laravel developer can fork and maintain it; the question is whether you want to budget for that.
Secondary risks: Mux account structure (development vs production environments) must be configurable per environment, or staging uploads will pollute production analytics and billing. Playback security — signed playback IDs with short-lived JWTs — is essential if any content is gated, and is easy to leave off. Deletion semantics are a classic gap: deleting a CMS entry does not necessarily delete the Mux asset, so you accumulate billable stored assets. And Statamic major upgrades have historically broken addons that touch the fieldtype API; with one maintainer, upgrade lag is a real scheduling dependency.
Key questions
composer.json, and is there a test matrix against them?Stack fit
The package assumes a conventional Statamic stack: Laravel (matching the Statamic version), PHP 8.x, Antlers templates, and Composer-based dependency management. It slots in without touching hosting topology — no new servers, no FFmpeg on your boxes, no CDN configuration. That is the main appeal versus self-hosted video: you are adding a SaaS dependency and a Composer package, not an infrastructure tier. If the site is statically cached or fronted by a CDN, the embed markup is cacheable; only signed-playback token generation needs to be request-time, and that is worth confirming as a template-level concern.
Migration path
Treat this as a content-model migration, not a code change. Existing video is typically one of three things: YouTube/Vimeo iframes in Bard or HTML fields, self-hosted MP4s in the asset container, or legacy embedded players. The path is: inventory existing embeds, map them to a new video fieldtype in the relevant blueprints, upload source files to Mux (or re-point to Mux-hosted originals), backfill field values by asset ID, then update Antlers partials to branch on fieldtype presence. Run this behind a feature flag or in a parallel fieldset so old and new render paths coexist until parity is verified. Legacy assets in the Statamic container should not be deleted until the cutover is signed off — you want a rollback that does not require re-uploading source files.
Compatibility
Pin the package version and verify the declared Statamic/PHP constraints against your actual composer.lock before starting. Because the addon sits on the Mux SDK, a transitive SDK bump can change behaviour; lock it. Also verify Antlers vs Blade rendering if you run a hybrid template setup, and check whether the fieldtype behaves correctly inside Live Preview and inside Bard sets — fieldtypes that only work as top-level fields are a common source of rework.
Sequencing
Budget roughly one to two developer-weeks for a straightforward integration, more if signed playback and asset lifecycle management are in scope, plus content-ops time for backfill.
Maintenance
Two maintenance streams: the package and Mux itself. The package needs version bumps alongside Statamic upgrades; the effective question is whether you self-maintain a fork or accept upgrade lag. Given the bus factor, I would plan for the fork option in the risk register even if you never exercise it — the estimate is small (a few hundred lines of glue) and knowing that bounds the worst case. Mux requires no maintenance but does require credential rotation hygiene and periodic review of asset retention.
Support
Community-only, via GitHub issues. There is no escalation path if a rendering bug appears on a Friday. Your mitigation is internal: designate one developer as the owner of this integration, and keep the fork in a private VCS remote so a patch can ship without waiting upstream. Mux's own support covers the API and playback, which is where most production incidents will actually originate.
Scaling
Scaling characteristics are good and are the reason to accept the dependency. Encoding and delivery are entirely Mux's problem; your application serves a few hundred bytes of embed markup and, if signed, a short-lived token. Application load is essentially flat in video volume. The scaling concern moves to cost: Mux bills on storage and streaming minutes, so a viral page or an autoplay-on-mobile hero video can move the monthly bill materially. Set budget alerts on the Mux account before launch, not after. Webhook volume scales with uploads, which is human-paced and negligible.
Failure modes
Ramp-up
Developer ramp-up is low if the team knows Statamic and Antlers; the Mux concepts to learn are few (asset, playback ID, environment, signed playback). Half a day of reading plus the spike. Content-editor ramp-up is trivial — pick a video, wait for processing, publish — but requires the control panel to communicate processing state clearly, or editors will publish broken pages and lose trust in the tool. The non-obvious training item is lifecycle discipline: who deletes assets at Mux, and when. Assign that owner before launch.
How can I help you explore Laravel packages today?