- How do I install tfd/statamic-cloudinary in a Laravel Statamic project?
- Install it with composer require tfd/statamic-cloudinary, then publish the config so it lands at config/statamic/cloudinary.php and add your Cloudinary credentials to the environment file. The addon registers itself through the standard Statamic addon service provider, so no manual provider registration is needed. There is no frontend build step required.
- Does this addon support Statamic 5 and Statamic 6?
- The package declares support for Statamic ^5.73.11 and ^6.4, but its test harness runs Testbench 10 on Laravel 12 and there is no CI matrix. That means Statamic 6 is likely the best-tested path, while Statamic 5 on Laravel 10 or 11 is claimed but not proven. Verify on a staging branch before upgrading.
- Do my assets need to already be in Cloudinary, or does the addon fetch them from my server?
- The documentation is not explicit about this, and it is the key feasibility question. The addon accepts Statamic asset IDs, asset URLs, and mapped external URLs, but it does not clearly state whether assets must already exist in Cloudinary or whether URLs are generated with Cloudinary's remote fetch delivery type against your Statamic origin. Confirm this before planning, because the answer decides whether the integration is a config change or a full asset synchronization project.
- How do I configure Cloudinary credentials for the Statamic addon?
- Publish the config file to config/statamic/cloudinary.php and supply your Cloudinary cloud name, API key, and API secret through environment variables. Keep secrets out of version control and use separate credentials per environment. Note that the repository lives under 21stdigital while the PHP namespace is TFD\Cloudinary, so confirm you are tracking the intended upstream before pinning a version.
- Should I use the cloudinary Antlers tag or the x-cloudinary-image Blade component?
- Both routes go through the same transformation layer, so the choice is mostly about templating context. Use the Antlers tag registered in src/Tags/Cloudinary.php inside your Antlers templates, and the aliased Blade component <x-cloudinary-image /> in Blade views. All transformation logic is centralized in TFD\Cloudinary\Converter\CloudinaryConverter either way.
- How does the addon convert Glide parameters into Cloudinary transformations?
- The converter translates Glide-style parameters into Cloudinary transformation syntax in a single place. The docs do not publish a complete mapping table, so check whether the parameters you rely on, such as fit, width, height, and format, are translated or silently dropped. Test your exact parameter set and see whether unsupported values pass through, are ignored, or throw an exception.
- What happens if Cloudinary is unreachable or an asset is missing?
- The established behavior is to catch ItemNotFoundException, log at error level, and fall back to Glide, so pages keep rendering. That is good for uptime but poor for observability, since a misconfigured Cloudinary setup can look like images that are just a bit slow rather than an outage. Monitor error logs and, if possible, alert on fallback frequency.
- Is tfd/statamic-cloudinary production ready and actively maintained?
- Treat it with caution: the repository has roughly 7 stars and no dependents, so there is little ecosystem evidence of production hardening. The single-package governance and the mismatch between the 21stdigital repository and TFD\Cloudinary namespace suggest a fork, transfer, or vendored addon whose upstream cadence should be confirmed. Verify release history on Packagist and tags directly, because the listed release date looks unreliable.
- Does the addon support signed URLs or private, authenticated assets?
- The overview does not state whether signed URLs or authenticated delivery are supported. If you serve private or protected imagery, verify this before enabling the addon, because default delivery may widen access to restricted assets. Test with a restricted asset in a staging environment first.
- Does it work with multi-site Statamic installs and long-TTL CDN caching?
- Multi-site behavior, localized assets, per-site transform sets, cache TTL stability, and purge or invalidation hooks are not documented, so plan to test them yourself. Generated URLs need to be stable enough to sit behind a long-TTL CDN. Also confirm that public_id derivation stays stable across asset renames, because a change there invalidates caches and breaks links.