Weave Code
Nova Cloudinary Field Laravel Package
bbs-lab/nova-cloudinary-field
bbs-lab/nova-cloudinary-field provides a Laravel Nova field for seamless Cloudinary integration, letting you upload, preview, and manage images and media directly within Nova resources using Cloudinary's cloud storage and transformation capabilities.
A Cloudinary Media Library field for Laravel Nova.
Frequently asked questions about Nova Cloudinary Field
- How do I install bbs-lab/nova-cloudinary-field in a Laravel Nova app?
- Install it with Composer (composer require bbs-lab/nova-cloudinary-field), then register the field class inside the Nova resource where you want media management. You will also need to publish the package assets and supply your Cloudinary cloud name, API key, and API secret through config or environment variables. In a typical single-resource spike this is an hours-not-days integration, but confirm your Nova major version is compatible before you start.
- Which Laravel and Nova versions does this package support?
- Version 2.2.0 added Laravel 13 support, which is an additive change to the framework constraint in composer.json and is safe for existing pinned installs. Laravel support does not imply Nova major support, because Nova is a separate commercial product with its own versioning. Check the declared constraints for both the Laravel framework and the Nova field API, and confirm compatibility with the exact Nova major you run before upgrading.
- How do I configure Cloudinary credentials for the Nova field?
- Credentials are supplied through package config backed by environment variables, so keep secrets out of your Nova resource classes and out of version control. Use separate Cloudinary accounts or at least separate upload presets per environment so staging uploads never touch production assets. If you run multiple tenants, namespace uploads by folder or preset rather than relying on a single shared account.
- What exactly does the field store on my Eloquent model?
- The field persists a Cloudinary identifier for the uploaded asset, which may be a public ID, a derived URL, or a structured value depending on the field configuration. That distinction matters because a public ID is not interchangeable with a URL string. Decide the storage contract early, since it leaks into API serializers, front-end templates, and any downstream consumer of the column.
- Does deleting a model row delete the image from Cloudinary?
- Not automatically. Deleting an Eloquent record does not guarantee the remote Cloudinary asset is destroyed, so orphaned media can accumulate and keep incurring storage and delivery costs. If deletion semantics matter to you, handle remote cleanup explicitly in a model observer, a queued job, or your own service layer. Treat deletion policy and data retention as your responsibility rather than the package's.
- Can I restrict allowed formats, file sizes, or apply transformations?
- Yes, but the policy lives in the Cloudinary upload widget configuration and your Cloudinary account settings rather than in the Nova field itself. You can constrain allowed formats, enforce size caps, and apply named transformations or delivery URLs when rendering assets. Define these rules per resource so a public marketing image field and a restricted document field do not share the same upload policy.
- Is this package a general-purpose Laravel media library?
- No. It is a thin Nova field adapter that connects the Nova admin form to Cloudinary's upload widget and persists the returned identifier on your model. It presumes you have already committed to Nova and to a Cloudinary account, and it is intentionally not a filesystem storage abstraction. Anything that assumes local or S3 semantics, such as backups, seeding, queue-based image processing, or access control, needs a deliberate answer of its own.
- How do I test a Nova resource that uses a Cloudinary field?
- Because the field is a thin adapter, most of your testing value is on the backend: assert that the expected identifier is persisted when the field is submitted and that your serializers expose it correctly. Avoid hitting the real Cloudinary API in automated tests; fake or stub the upload response instead. Also verify asset publishing and rendering against your actual Nova version, since pre-compiled JS assets can silently degrade when Nova's asset pipeline changes.
- Is the package actively maintained, and what are the risks of adopting it?
- It is a single-maintainer project with a small release cadence, though framework-support pull requests such as the Laravel 13 addition have been merged promptly. There is no evident institutional backstop if the maintainer steps away, and Nova field packages are small enough to fork and vendor as a mitigation. The bigger operational risk is upgrade coupling: your Laravel major, your Nova major, and this package must move together, and any one lagging stalls the other two.
- What else should I evaluate before choosing this over alternatives?
- First confirm your Nova major is supported, since Laravel 13 support alone does not guarantee it, and remember Nova licensing is paid and per-site, which gates multi-tenant or multi-environment rollouts. Then decide whether you need asset deletion, transformation, or access-controlled delivery in scope, because those belong in your own service layer rather than the field. Finally, review Cloudinary's commercial tier, data residency, and egress billing, since assets are hosted and served from Cloudinary's CDN rather than your storage layer.
Weaver
How can I help you explore Laravel packages today?