Imagekit Laravel Package

Product Decisions This Supports

The core decision this package informs is not "should we use this library" but "should we buy ImageKit as our image pipeline" — and it's a useful artifact for the second question.

• Build vs. buy for image delivery. aerni/imagekit is a thin URL-builder: it wraps ImageKit.io's transformation query parameters (width, height, crop, format, quality, DPR) so they can be expressed from Antlers templates. That tells you exactly how much proprietary logic sits in the "buy" half of the decision — almost none. The real investment is the vendor contract, the origin/storage configuration, and the migration of existing asset URLs.
• Feature bets it makes cheap to test: responsive srcset/sizes generation, on-the-fly format negotiation (WebP/AVIF), crop/focal-point transforms, and CDN caching — all as URL parameters rather than build steps. If your roadmap has "stop shipping 3 MB hero images" or "support retina without a second asset pipeline," this is a two-day spike, not a quarter.
• Use cases where the pattern fits: marketing and content sites on Statamic with large, editor-uploaded media libraries; multi-locale sites where one asset must serve several crops; e-commerce catalogs where merchandisers change imagery without a deploy.
• Roadmap signal to capture — now with a first-class kill switch. v2.2.0 adds an option to bypass ImageKit and serve images from the regular path, primarily for local development. Read past the dev-ergonomics framing: this is a vendor opt-out flag. That makes two product decisions cheaper — (a) a phased rollout where production uses the CDN while staging/local serves origin, avoiding "works on my machine" divergence in image URLs; and (b) a rollback plan if the vendor's latency, pricing, or cache-hit rates disappoint, you flip a flag instead of reverting a release. Adopt the interface as vendor-neutral (asset + named transform set → URL) so ImageKit, Cloudinary, imgix, or self-hosted Glide/imgproxy remain interchangeable — and make the rollout/rollback posture an explicit, documented decision.
• What it does not support: no indication of DAM/editorial workflows, signed-URL access control, or analytics integration. Do not let it stand in as evidence that ImageKit "integrates with Statamic" in a procurement comparison — the integration is URL string concatenation.

When to Consider This Package

Adopt the pattern, not the package — but the "abandoned" objection is now weaker and must be re-verified, not repeated.

v2.2.0 is the first release in roughly five years. That is a data point, not a trend: one release does not establish a maintenance cadence, and the release notes do not state Statamic version support. Treat this as "someone still has the keys," not "actively maintained."

Consider it when:

• You are already on Statamic and already have an ImageKit account, and you want a worked example of how transformation parameters map to Antlers syntax.
• You need a one-to-two-day proof of concept to validate image quality, transform latency, and cache-hit behavior before signing a vendor contract. Read the source; a composer require into production is now marginally more defensible than it was, but still not the recommendation.
• You want a spec for the internal tag you're about to write. A single custom Statamic tag plus a fieldtype is roughly the same surface area as this package — and v2.2.0's bypass flag is now part of that spec.
• Local development currently depends on network access to the CDN, or you are running a dual-path dev/prod image setup. The bypass option is a real, if small, DX win.

Look elsewhere when:

• You need Statamic 4/5 support. v2.2.0 does not advertise compatibility. Verify against your version before it appears in any estimate — unmaintained or sporadically maintained addons remain the most common source of upgrade blockers in Statamic.
• You need signed URLs, private assets, or per-user access control. URL builders of this era typically emit public, unsigned URLs; retrofitting signing means forking.
• You need responsive-image logic (srcset breakpoints, <picture> art direction, LQIP placeholders). That's the actual hard part and is usually out of scope for a URL helper. Note the bypass flag is all-or-nothing per environment; it is not a per-asset fallback if the CDN 404s.
• Your security posture forbids unmaintained transitive dependencies. Still low dependents, still a supply-chain question — the release reduces but does not eliminate it.
• You are not on Statamic at all. The value here is the Statamic glue; the ImageKit URL grammar is documented and trivially reimplemented in any framework.

How to Pitch It (Stakeholders)

For executives (one paragraph): We re-reviewed a small open-source addon for connecting our Statamic site to ImageKit, a commercial image CDN. A new release added a switch to serve images directly from our own servers instead of the CDN — useful for local development, and more importantly a built-in rollback lever for a vendor decision. The addon itself remains negligible in scale (tiny user base, first update in five years), but it still clarifies the real decision, which is a vendor one: image resizing, format conversion, and caching are configurable entirely through URLs, so we can offload them without touching application code or the build pipeline. The recommendation is unchanged — treat the addon as a free prototype, run a short paid pilot against our real asset library, and budget a small internal implementation (roughly 1–2 engineer-days) rather than adopting the library. The upside is measurable page-weight and Core Web Vitals improvement; the vendor lock-in risk is now cheaper to hedge because we can switch image delivery back to origin without a redeploy.

For engineering (the ask): Re-check Statamic version compatibility first — the release notes say nothing about it, and that is the gating question. Then read the repository as a specification rather than a dependency and reimplement as a project-local tag; the surface is small enough that a fork costs less than the upgrade risk of a sporadically maintained addon. Design the tag to take a Statamic asset plus a named transform set and return a URL, so ImageKit-specific parameter mapping stays in one file and can be swapped for Cloudinary, imgix, or self-hosted Glide without touching templates. Include the new bypass behavior in your spec — environment-driven, defaulting to CDN in production and origin locally — and confirm it fails safe (no silent hotlinking to origin in production under load). Keep srcset/sizes generation and format negotiation in scope from day one; those are the features that justify the pilot, and the package still does not provide them.

Bottom line: Green-light a scoped pilot, not an adoption. Score the vendor on transform quality, cache behavior, and pricing at our actual bandwidth; score the integration as "we'll build it" — now with a documented rollback path.