Weave Code
Laravel Imgix Laravel Package
astrotomic/laravel-imgix
Laravel package that generates Imgix URLs for your images, letting you apply Imgix transformation parameters like resizing, cropping, and format conversion directly from PHP. Integrates with Eloquent models and Blade to simplify responsive image handling.
Laravel bindings and facade to generate imgix URLs and support for multiple sources.
Frequently asked questions about Laravel Imgix
- How do I install astrotomic/laravel-imgix in a Laravel app?
- Install it with composer require astrotomic/laravel-imgix, then publish the package config using Laravel's vendor:publish command. The service provider is auto-discovered, so there is no manual registration step. After publishing, add your imgix source domain and signing key to your environment file and you can start building URLs through the facade.
- Does astrotomic/laravel-imgix support Laravel 12?
- Yes. Version 1.3.0 widened the framework constraint to include Laravel 12, and because the change widened rather than narrowed the constraint, Laravel 10 and 11 remain supported. It is a compatibility-only release with no API, config, or behaviour changes. Before rolling it out across a mixed-version fleet, confirm composer.json actually allows ^12.0 and that the CI job for Laravel 12 is green on the tagged commit.
- How do I configure multiple imgix sources with this package?
- The publishable config file lets you register more than one imgix source, each with its own domain and signing key. When generating a URL you choose which configured source it belongs to. This is handy when you split images across separate imgix sources, for example per environment, per brand, or per asset type.
- How do I generate signed imgix URLs for a secured source?
- Provide the imgix signing key for the source in the package config or your environment file, and the package will sign the URLs it generates for that source. Make sure the signing behaviour matches the security settings configured on the imgix source itself, otherwise imgix will reject the requests. Always smoke-test the signed path against a real source in staging before shipping.
- Can I use the package with Eloquent models and Blade templates?
- Yes, the package is built for that workflow: it ships a facade and integrates with Eloquent models and Blade so you can produce image URLs directly in templates and components instead of hand-writing query strings. That keeps responsive image markup readable. Just be aware that imgix-specific transformation parameters will end up living in your Blade files.
- How do I apply transformation parameters like width, crop, or auto=format?
- Pass imgix transformation parameters such as width, height, fit, crop, and auto=format when you generate the URL, and the package appends them to the resulting imgix URL. imgix does the actual resizing and format conversion at request time, so your stored originals stay untouched. Review any default parameters you set globally, since they can affect bandwidth spend.
- What is the difference between this package and the official imgix PHP SDK?
- The official imgix PHP SDK is framework-agnostic and covers the imgix API more broadly, while astrotomic/laravel-imgix is a thin Laravel adapter offering a facade, publishable config, multiple named sources, and Eloquent and Blade conveniences. If all you need is URL construction inside a Laravel app, the bindings remove boilerplate. If you need wider imgix API features, evaluate the official SDK or falling back to plain URL building first.
- Do I need to change config or code when upgrading from 1.2.0 to 1.3.0?
- No. Version 1.3.0 is a compatibility release that only widens the framework constraint to include Laravel 12, with no API changes, deprecations, or behaviour changes. Run composer update astrotomic/laravel-imgix right after your framework upgrade and no config republish or code edits should be needed. If anything goes wrong, rollback is a one-line constraint revert to ^1.2.
- Does this package add migrations, jobs, or other runtime overhead?
- No. There are no migrations, no background jobs, no queues, and no new runtime services; the package only builds and optionally signs image URLs at request time in the presentation layer. That keeps operational impact near zero and upgrades composer-level and reversible. It is a small, largely single-maintainer package, so pin it with a caret constraint and keep an eye on releases in case a future Laravel major lags.
- How hard is it to remove the package or switch to another image CDN later?
- Removing the package itself is low-effort because it is a thin wrapper, and the worst case is inlining URL construction in roughly a day. The harder part is that imgix transformation semantics such as width, fit, auto=format, and DPR leak into your templates, so moving to Cloudflare Images, Cloudinary, or another provider means rewriting those call sites. Centralising URL generation behind your own helper or Blade component makes that future migration much cheaper.
Weaver
How can I help you explore Laravel packages today?