# thephpleague/glide: On-Demand Image Manipulation Behind an HTTP API

> Glide is a PHP library that turns query strings into image operations, backed by Intervention Image and Flysystem. It suits teams that already run PHP and want self-hosted image resizing without a cloud vendor.

**thephpleague/glide** — Wonderfully easy on-demand image manipulation library with an HTTP based API.

- Repository: https://github.com/thephpleague/glide
- Website: http://glide.thephpleague.com
- Stars: 2,633 · Forks: 205
- Language: PHP
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/thephpleague-glide

## The problem Glide solves for PHP applications

Most PHP applications store one original image and then need many sizes of it: a thumbnail in a listing, a cropped hero, a width-constrained version for a mobile breakpoint. Generating every variant at upload time means guessing the sizes in advance and storing all of them. Glide takes the other route. The original stays put, and the variant is produced when the URL is first requested, then cached. The API is the URL itself, which the README describes as similar to cloud image processing services like Imgix and Cloudinary. The difference is that Glide runs inside your own PHP process or as your own small server, so the images never leave your storage. It is aimed at PHP developers who are comfortable wiring a library into an existing application and who want the resize parameters to be part of the request rather than part of a build step.

## How the HTTP API, Intervention Image and Flysystem fit together

Three layers are visible from the README and the repository layout. The outermost layer is HTTP: a request arrives with query parameters that describe the manipulation. The middle layer is Intervention Image, which the README calls the image handling and manipulation library that powers Glide, and which does the actual pixel work. The innermost layer is Flysystem, which abstracts where the source and cached files live, so the same code can read from a local directory or another adapter. The README lists GD, the Imagick PHP extension and the libvips PHP extension as supported backends, which means the pixel work is delegated to whichever of those is installed. Responses can be returned in several forms, including PSR-7 and HttpFoundation, so Glide can sit inside a framework or stand alone. The README also states that manipulated images are cached automatically and served with far-future expires headers, which is what makes the on-demand model workable: the first request pays the cost, later requests do not.

## Installing Glide with Composer and serving a first resized image

The README gives one installation step, and it is Composer. Run it from your project root and Composer will resolve league/glide and its dependencies.

```bash
$ composer require league/glide
```

After that, the README points to the full documentation at glide.thephpleague.com for usage. The README itself does not include a server bootstrap example, so the concrete wiring of a request handler, a Flysystem filesystem and a cache path is something you will read there rather than here. What the README does show is the shape of the public URL. The image at the top of the README is served with a width parameter appended to the path.

```
/docs/images/kayaks-w-1000.jpg?w=1000
```

The parameter name w and the value 1000 are taken directly from that example. In a running Glide server, requesting a URL of that form should return the image resized to that width, and a second request for the same URL should be served from the cache rather than reprocessed. If you want to run the library's own checks before integrating it, the README documents a PHPUnit suite and says to run phpunit from the project folder. The repository also ships a docker-compose.yml with tests, analysis and cs services, each building from the Dockerfile and running composer install first; those are the maintainers' own workflows, and the Dockerfile installs the zip, gd, imagick, exif and xdebug extensions on php:8.3-cli.

## Where Glide is the wrong tool

Glide assumes you have a PHP runtime and at least one of GD, Imagick or libvips available. That is a real constraint, not a formality. The repository Dockerfile installs gd and imagick explicitly, which tells you the library does not carry its own image codec; if your hosting environment cannot load those extensions, Glide has nothing to manipulate images with. Second, the on-demand model depends on caching being configured and writable. The README states that caching is automatic, but it does not document what happens when the cache directory is missing or read-only, and it does not document cache invalidation. If you replace an original image and expect every derived size to change, that behaviour is not described in the README, and you should confirm it against the documentation before relying on it. Third, if your team is not on PHP, the HTTP API alone is not enough: the manipulation runs in a PHP process, so a Node or Go service would have to call out to a separate Glide deployment. Finally, if you need a hosted service with a CDN and no server to operate, Glide is the opposite of that trade.

## Glide compared with a hosted image CDN

The closest comparison in the README is Imgix and Cloudinary, both of which expose a URL-driven manipulation API. The difference is where the work happens and who owns it. With a hosted service, you point a URL at the vendor, the vendor fetches or stores the original, and the vendor operates the caching and the image processing fleet. With Glide, you own the PHP process, the Flysystem adapter that holds the originals, and the cache. The payoff is that the images stay on your infrastructure and there is no per-image billing tied to a vendor, and you can read the entire manipulation path because the library is MIT licensed and the source is in the repository. The cost is that you operate it: capacity, cache storage and the security of the URLs are your responsibility. Glide does address that last point with HTTP signatures, which the README lists as a way to secure image URLs, though the README does not show the signing code. If your images are public and unauthenticated, that feature matters less; if they are not, you need to read the documentation before exposing the endpoint.

## Maintenance status, licence and upgrade cost

The repository is not archived, and the last push was on 2026-07-16. The most recent release, 4.1.0, carries the same date, and 4.0.0 came out on 2026-05-30 after a 4.0.0-beta2 on 2026-04-07. That release cadence, with a major version followed within weeks by a minor, is worth noting when you plan an upgrade: a 4.x line that recently shipped a major means breaking changes are close to the surface, and the CHANGELOG.md at the repository root is the file to read before moving between majors. The licence is MIT, which permits commercial use and modification and requires that the licence text be preserved; that is a summary of the licence identifier the repository states, not legal advice, and you should read the LICENSE file for the actual terms. Operationally, the upgrade cost is mostly Composer's: the library is framework-agnostic and Composer ready, so pulling a new version is a dependency update, but the image backend underneath is a separate concern. If a future release changes which Intervention Image version it depends on, your installed GD or Imagick extensions may need to match.

## Conclusion

Adopt Glide if your stack is PHP, your images live on a Flysystem-backed filesystem and you want resize and effect parameters driven by URL query strings with automatic caching. Do not adopt it if you need a standalone service in another language, or if you cannot run GD, Imagick or libvips on the host. Before committing, verify which of the three image backends your environment provides, and read the documentation at glide.thephpleague.com on HTTP signatures, because the README only names the feature and does not show the signing setup.

## FAQ

### What is Glide, the PHP image manipulation library?

Glide is an on-demand image manipulation library written in PHP whose API is exposed over HTTP, similar to cloud image processing services. It is powered by Intervention Image for manipulation and Flysystem for file system abstraction, and it caches manipulated images automatically.

### How do I install Glide?

The README gives one installation step: run composer require league/glide. Full usage documentation is at glide.thephpleague.com rather than in the README.

### Is Glide free to use?

The repository states that Glide is released under the MIT License, which permits commercial use and modification with the licence text preserved. Read the LICENSE file for the exact terms.

## Sources

- [License: MIT](https://github.com/thephpleague/glide/blob/master/LICENSE)
- [Project website](http://glide.thephpleague.com)
- [README](https://github.com/thephpleague/glide/blob/master/README.md)
- [Releases](https://github.com/thephpleague/glide/releases)
- [thephpleague/glide on GitHub](https://github.com/thephpleague/glide)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thephpleague-glide