Weave Code
Flysystem Cloudflare Bundle Laravel Package
softavis/flysystem-cloudflare-bundle
A Symfony bundle that integrates Flysystem with Cloudflare R2 object storage, making it easy to configure R2 as a filesystem for uploads, downloads, and file management through familiar Flysystem APIs.
Softavis Flysystem Cloudflare Bundle connects Cloudflare R2 object storage to Symfony through Flysystem, giving you a configurable filesystem service for uploads, downloads, and file operations. Configure your bucket and credentials in Symfony, then inject the filesystem wherever needed—no manual adapter wiring.
- Simple Symfony bundle setup
- Flysystem-powered Cloudflare R2 storage
- Environment-variable-friendly configuration
- Clean dependency-injection integration
- Reusable filesystem service for uploads and downloads
Frequently asked questions about Flysystem Cloudflare Bundle
- Can I use softavis/flysystem-cloudflare-bundle in a Laravel application?
- Only partially, and with caveats. The package is a Symfony bundle, so its DI extension, service definitions, and config tree are dead weight in Laravel and will not be auto-wired by Laravel's package discovery. The genuinely reusable piece is the underlying Flysystem adapter class, which you can register manually as a custom Laravel disk driver. Treat the bundle wrapper as packaging to be discarded, not a feature.
- How do I install softavis/flysystem-cloudflare-bundle with Composer?
- The composer name as published is softavis/flysystem-cloudflare-bundle, and at 0.1.x you should pin an exact version rather than use a caret range. A command like composer require softavis/flysystem-cloudflare-bundle:0.1.2 avoids semver surprises, since pre-1.0 releases permit breaking changes in patch bumps. After install, inspect the dependency tree for a duplicate Flysystem major or a conflicting Symfony HTTP client before writing any code. If you only want the adapter in Laravel, avoid pulling the Symfony bundle into the app at all.
- Does this package work with Cloudflare R2 specifically?
- The package overview states it integrates Cloudflare R2 with Flysystem, so R2 is the primary target. What the release notes do not confirm is whether Cloudflare Images or Stream are also covered, or whether the adapter adds anything R2-specific beyond endpoint configuration. Verify the target product against the source before you commit, because an Images-focused adapter behaves very differently from an R2 object store one.
- Which Flysystem version does this adapter require, v2 or v3?
- This is unconfirmed from the published material and is one of the first things to check in composer.json. It matters because Laravel 9 and later ship Flysystem v3, and an adapter built against v2 will not slot into a modern Storage disk without extra work. Pulling in a second Flysystem major alongside Laravel's own is a common way to break the filesystem layer.
- What PHP and Laravel versions are supported?
- There is no published support matrix, so assume nothing about Laravel 10, 11, or 12 or about a PHP 8.1+ floor. Verify the constraints in composer.json and test against your actual PHP and Laravel versions in a throwaway branch before committing. Because the package is Symfony-oriented, its declared framework requirements may not align with your Laravel install at all.
- How do I configure a Cloudflare disk in Laravel using this adapter?
- Add a disk entry in config/filesystems.php that returns your configured adapter instance, or register a small custom driver in an App service provider that builds the Flysystem adapter and hands it to Storage::extend. Keep the Symfony bundle's configuration tree out of the app so your third-party surface stays at one class. Domain code should only ever call Storage::disk('assets'), which keeps any later swap to a first-party adapter a config-level change rather than a refactor.
- Does the adapter support presigned or temporary URLs for private buckets?
- Temporary URL support is not documented in the supplied material, and it is exactly the kind of ergonomic gap that decides whether a third-party wrapper is worth using. If your application serves private objects, confirm temporaryUrl behavior and public bucket or custom domain URL generation explicitly. Test it against a scratch bucket before designing around it, since a missing or broken signed URL implementation is a hard blocker.
- How should I test a Cloudflare R2 disk backed by this adapter?
- Stand up a scratch R2 bucket and exercise put, get, temporaryUrl, exists, and delete through the Storage facade in a throwaway branch. Compare the results against a known-good disk built on league/flysystem-aws-s3-v3 pointed at the same endpoint, and note any behavioral differences. Only after that baseline passes should you consider using the adapter on a path that matters.
- Is a 0.1.x release safe for production, and how do I keep it stable?
- Treat it as not production-ready for critical paths. At 0.1.x, semver allows breaking changes in patch releases, release hygiene is weak with recent versions documented only by a compare URL, and there is no evidence of a security policy or CI coverage. Pin the exact version, wrap the adapter behind your own driver registration, and keep a working AWS S3 adapter configuration as a permanent fallback.
- How does this compare to league/flysystem-aws-s3-v3 for Cloudflare R2?
- R2 is S3-compatible, so the first-party AWS S3 v3 adapter reaches R2 with roughly ten lines of endpoint and region auto configuration, and it is maintained by the Flysystem team. A third-party wrapper only earns its place if it adds presigned URL ergonomics, multipart tuning, public bucket or custom domain URLs, or Images transform helpers the generic adapter lacks. Start from the AWS adapter as your reference implementation, then measure this package against it on those specific gaps.
Weaver
How can I help you explore Laravel packages today?