- How do I install axn/laravel-glide in a Laravel application?
- Run composer require axn/laravel-glide, then publish the configuration with php artisan vendor:publish --tag="glide-config" and generate a signing key using php artisan glide:key-generate. After that you define your source and cache disks in the published config and you can start generating image URLs. Make sure the PHP GD or Imagick extension is installed in every runtime, including queue workers and CI, because Glide needs an image driver to process anything.
- Which Laravel and PHP versions does axn/laravel-glide support?
- Version 3.x requires PHP 8.4 or newer and Laravel 12 or newer, and release 3.1.0 adds support for Laravel 13. If you are on Laravel 10 or 11 you must stay on v2.2.1, which is the last branch supporting those framework versions and no longer receives features. Teams on Laravel 11 should expect to pin the package or maintain a fork rather than tracking the latest release.
- How does the Glide signing key work and where should I store it?
- The package generates a GLIDE_SIGN_KEY via php artisan glide:key-generate, and each server definition can expose its own sign_key. Signed URLs let you serve resized images without exposing the source path to tampering or hotlinking, and you can scope signing per server so only user-generated or proprietary assets require a signature. Store the key as a long random secret (128 or more characters) in your environment or secrets manager, never in version control.
- Can I define multiple image servers or storage disks with laravel-glide?
- Yes, multiple servers are the package's core feature. Each named server in the config defines its own source disk, cache disk, watermarks disk, driver, base_url, defaults, and presets, and you select one at call time with Glide::server('avatars')->url(...). This makes per-tenant or per-domain image pipelines straightforward from a single Laravel application, as long as the cache disk is shared across all application instances rather than being local to each pod.
- What are Glide presets and why should I use them?
- Presets are named transformation bundles defined per server, so instead of repeating width, height, fit, and quality arguments everywhere you pass a short alias such as ['p' => 'small']. They are the part of the wrapper that most reduces duplication in product code and keeps image sizing consistent across web, email, and API surfaces. Defining presets in config also gives designers and backend developers a single place to agree on canonical image sizes.
- How do I return a processed image from a Laravel controller?
- Call Glide::imageResponse() (or the equivalent server-scoped method) instead of handling PSR-7 responses yourself. The included LaravelResponseFactory converts Glide's output into a proper Laravel Response, and it also supports Base64 output when you need to embed an image inline. In Blade views you typically just emit Glide::url() for the src attribute and let the route or controller return the response.
- Why is my app still serving the old image after I replaced the source file?
- Glide builds its cache key from the source path plus the transformation parameters, so overwriting an image at the same path keeps returning the previously derived file until that cache entry is removed. The package does not document a purge command or automatic invalidation, which means you must clear the derived file from the cache disk manually or change the source path or filename. For frequently updated assets, consider versioning the filename or query string in your URL generation.
- How do I rotate the Glide signing key without breaking existing image URLs?
- There is no documented rotation window in the config: a server has a single sign_key, and changing it immediately invalidates every URL already issued and embedded in emails, PDFs, cached HTML, or CDN edges. Plan rotation as a coordinated release, re-rendering or re-sending anything that stores signed URLs, and keep the previous key available only as long as the old URLs must remain valid. Because signing is configured per server, you can rotate high-risk servers independently of public ones.
- What alternatives exist to axn/laravel-glide?
- You can use league/glide directly and write your own service provider, controller, and signing logic, which is about three to five engineer days of work at parity because Glide already does the resizing, cropping, caching, and signature generation. Intervention Image is another option if you want a more Laravel-oriented image manipulation API rather than URL-driven HTTP transformations. For many teams the deciding factor is that this wrapper is small and therefore genuinely replaceable in-house.
- Is axn/laravel-glide actively maintained and safe for production?
- The package is maintained by a single agency, AXN Informatique, and has a small adoption footprint with roughly 10 stars and no dependents, so third-party production validation is minimal. The mitigating factor is scope: the substantive engine is league/glide, which is mature and widely used, and the wrapper only adds server management, signed URLs, presets, and Laravel response handling. Its documentation lives in a docs/ directory written in French and requires PHP 8.4 with Laravel 12 or newer, so budget for a deliberate version pin rather than blindly pulling the latest release.