Nova Field Cloudinary Laravel Package

Technical Evaluation

Architecture fit: The package is a thin Laravel Nova field set plus a Flysystem adapter for Cloudinary. It persists a Cloudinary public ID (or URL) on an Eloquent model and resolves delivery/transformation URLs at render time, so it slots into back-office admin surfaces without touching the app's own filesystem. The TPM should treat it as an admin media accelerator, not a media platform: it fits only where Laravel Nova and Cloudinary are already strategic. v1.3.0 broadens the surface to mixed media (CloudinaryVideo, better raw/video support), reduces Nova thumbnail size for faster index views, and fixes Audio/File deletion so remote assets are actually destroyed — the last of these is a behavioral contract change, not a cosmetic patch.

Integration feasibility: Mechanically low-friction: Composer install, publish config, set Cloudinary credentials, swap standard Nova image/file fields for Cloudinary-backed ones on selected resources. The real feasibility question is asset ownership, not wiring. The field must own only what it uploaded; shared, evergreen, or cross-record assets need separate lifecycle control. Feasibility is therefore high for one low-risk resource and materially lower for sprawling media estates with reused assets.

Technical risk: High, dominated by maintenance risk rather than code risk. Last release 2019-11-19, 27 stars, 0 dependents, and no verified compatibility with modern PHP, Laravel, Nova 4/5, or current Cloudinary SDK behavior. Secondary risks: destructive delete semantics (the v1.3.0 fix converts silent remote orphans into irreversible remote destroys), dual vendor lock-in to Nova and Cloudinary, transformation/video quota cost, credential scoping, and dependency on a small upstream project for a critical admin path. Frame it internally as "useful pattern, stale artifact" and force an explicit adopt-vs-pin-vs-fork-vs-reimplement decision.

Key questions:

• Which PHP, Laravel, Nova, and Cloudinary SDK versions are actually supported, and do they match what we run today and in the next two upgrade cycles?
• Adopt as-is, pin, fork the field/config classes, or reimplement the ~thin pattern in-house with a named owner?
• Does remote delete fire on field clear, model delete, cascading delete, and bulk actions — and is it idempotent and recoverable via Cloudinary backup/retention?
• Are image, video, audio, file, and raw upload/transform/destroy paths covered by tests we can run in CI?
• How are credentials scoped per environment/tenant, rotated, and protected from config:cache drift? Do we need upload presets, folders, private/signed delivery?
• What is the rollback if a delete misfires or a Nova upgrade breaks the field mid-sprint?

Integration Approach

Stack fit: Target Laravel + Nova + Cloudinary exclusively, and adopt per model and per asset type to keep blast radius small — images and files first, then audio/video/raw once deletion and transformation behavior is proven. Define ownership up front: field-owned assets versus shared assets addressed by plain public-ID columns with lifecycle handled by jobs or observers. Do not mix local/S3 disks and Cloudinary on the same model; deletion semantics diverge and orphans become invisible.

Migration path: Inventory current media storage, Cloudinary account structure, presets/folders, and — critically — current delete behavior, because upgrading silently activates remote destruction. Stand up a dedicated staging Cloudinary cloud so pilots never touch production assets. Run a time-boxed compatibility spike on a throwaway branch against our real Nova/PHP versions; if it fails, fork the base field and config rather than absorbing open-ended breakage. Pilot one low-risk model (image + file), backfill via Cloudinary API or public-ID mapping, retain legacy identifiers until URL parity is verified, then exercise replace/clear/delete against disposable assets.

Compatibility: Pin PHP, Laravel, Nova, and Cloudinary SDK versions we actually test. Validate the smaller Nova thumbnails are intentional, not regressions, and regression-test any local field overrides that extend package classes. Audit queue workers, filesystem disks, and config caching — php artisan config:cache is the classic cause of "missing credentials" in staging vs production. Treat the delete fix as breaking: update deletion tests, admin guidance, and any retention/soft-delete policy that assumed assets survived record deletion.

Sequencing: Dependency + license + security review → compatibility spike → adopt/fork/reimplement decision with a named internal owner → staging implementation with centralized transformation presets → deletion-safety review signed off by data/compliance → production pilot on one model → rollout by asset type with monitoring and a documented rollback. Hard gate: if we cannot name a maintainer for the dependency or its fork, it does not go on a critical admin path.

Operational Impact

Maintenance: The dominant cost. With a 2019 release and no dependent ecosystem there is effectively no upstream support — Nova upgrades, PHP upgrades, and Cloudinary API changes land on us. Budget a nominated owner, a vendored fork or thin in-house replacement of the base field class, and quarterly compatibility checks pinned to Nova/PHP release notes. Keep cloud name, API keys, presets, folders, and transformation names in environment/config management, never in code.

Support: Ship runbooks for credential rotation, failed/timed-out uploads, transformation errors, missing assets, quota exhaustion, and accidental remote deletion. Train editors on video/raw fields and poster/thumbnail expectations so index views don't probe video unnecessarily, and pre-announce the intentionally smaller Nova previews so they aren't escalated as defects. Escalation routes to Cloudinary support plus the internal owner — never to the package maintainer.

Scaling: Cloudinary absorbs storage, transformation, and CDN delivery; Nova and the database scale with admin concurrency and public-ID rows, which is cheap. Watch transformation and video/raw spend, API rate limits, thumbnail generation, and multi-tenant folder/preset design. Centralize transformation presets so variant growth doesn't become per-model configuration sprawl.

Failure modes: Missing credentials after config caching, upload timeouts, transformation failures, destructive delete misfires, orphans inherited from pre-v1.3.0 behavior, Nova upgrade incompatibility, quota exhaustion, null/missing public IDs, and deletion of shared assets still referenced elsewhere. Require explicit acceptance tests for upload, preview, replace, clear, delete, and rollback using disposable assets before sign-off.

Ramp-up: Engineering ramp-up is low for anyone who has written a Nova field — it behaves like a standard field. Operational ramp-up is moderate: editors and support need Cloudinary, retention, and deletion-policy literacy, and someone must own the deletion policy as a product decision. TPM deliverables before broad rollout: named owner, pilot plan, acceptance criteria, deletion-policy sign-off, editor runbook, cost-monitoring check, and rollback plan.