- Is survos/imgproxy-bundle a Laravel package?
- No. Despite being installable with Composer, survos/imgproxy-bundle is a Symfony bundle, so it ships a Symfony bundle class, DI service definitions and Twig helpers rather than a Laravel service provider or facade. Laravel applications will not get auto-discovery or Blade helpers from it. If you are building a Laravel app, treat it as reference material for imgproxy URL signing or use a Laravel-specific imgproxy wrapper instead.
- How do I install survos/imgproxy-bundle with Composer?
- Install it with composer require survos/imgproxy-bundle, then enable the bundle in your Symfony kernel or bundles.php as you would any other bundle. You will need to publish or create configuration for the imgproxy base URL plus the signing key and salt that match your imgproxy instance. Since the package is Symfony-oriented, there is no Laravel package:discover step that will register anything for you.
- How does the bundle generate signed imgproxy URLs?
- It exposes services and Twig helpers that take a source image URL plus processing options such as resize, and return a complete imgproxy URL. When a key and salt are configured, the URL is signed with an HMAC so imgproxy will accept it under its secure URL scheme. That URL-building and signing step is the reusable core if you want to call imgproxy from a Laravel app.
- Can I use the Twig helpers in Laravel Blade templates?
- No, Twig extensions do not carry over to Blade. In Laravel you would instead wrap the same signing logic in a helper function, a Blade directive or a small service class bound in the container. The underlying algorithm is straightforward HMAC signing over the path, so porting it is usually a few dozen lines of PHP.
- What configuration does it need to talk to an imgproxy server?
- At minimum you need the base URL of your imgproxy endpoint, and if the server runs in secure mode you also need the hex-encoded key and salt used for signing. Those values must match what imgproxy was started with, so keep them in environment variables rather than committing them. Any source allowlist or S3/local storage setup is configured on the imgproxy side, not in this bundle.
- Does it help with responsive images and thumbnails?
- Yes, that is the main use case: generating resized thumbnail and variant URLs on the fly so originals stay untouched. The helpers let you emit several sizes for a srcset rather than pre-generating files at build time. You still write the img and picture markup yourself; the bundle focuses on producing correct URLs.
- Which Laravel versions does this package support?
- Laravel version support does not apply here because the package is a Symfony bundle with no Laravel service provider. It will not appear in Laravel's package discovery and is not tested against Laravel releases. Check the composer.json constraints for the supported Symfony and PHP versions instead.
- How do I test imgproxy URL generation without running an imgproxy server?
- Unit test the URL builder by asserting the exact path and signature it produces for a known image URL and option set, since signing is deterministic. You can mock or stub any HTTP client the bundle uses so tests never hit a real imgproxy instance. That keeps the test suite fast and makes regressions in the signing format immediately visible.
- What are the alternatives for handling imgproxy in a Laravel application?
- You can sign URLs yourself with a short HMAC helper, use League Glide for a similar on-the-fly processing workflow, or pick one of the community imgproxy packages that ship a Laravel service provider and facade. Packages such as intervention/image or spatie/laravel-image-optimizer solve the neighbouring problem of processing and optimising files directly in PHP. Choose imgproxy-style URL signing when you want the heavy lifting offloaded to a separate service.
- Is survos/imgproxy-bundle actively maintained and safe for production?
- It is a small, single-maintainer package, so check the GitHub repository and Packagist release history for recent commits and compatible version tags before adopting it. Pin an explicit version in composer.json and read the URL-signing code, since that behaviour is the part you depend on. For production, pair it with an imgproxy deployment that has a strict source allowlist and secure URL mode enabled.