Client Cli Laravel Package

Product Decisions This Supports

• Image delivery build-vs-buy: A concrete way to evaluate rokka.io (Swiss image-processing CDN) against Cloudinary, imgix, Gumlet, or a self-hosted stack (Intervention Image + Glide, spatie/laravel-medialibrary). The CLI lets you exercise real stack/rendition/alias workflows in a day rather than reading docs.
• Roadmap input for responsive/derivative imagery: Fast validation of on-the-fly transforms, DPR variants, WebP/AVIF output, and named "stacks" (rokka's rendition config) before committing sprint capacity to a custom pipeline.
• Ops automation, not application code: Bulk stack creation, alias retargeting, cache purge/warmup, and asset sync belong in CI or runbooks. This is the tool for "change the rendition config across 400 stacks" — a real, recurring cost center once you have a media library.
• Vendor migration feasibility: If you're leaving or entering rokka, the CLI supports inventorying and replicating image configurations — useful scoping data for a migration epic.
• Cost/latency experiments: Prove that offloading resizing to a CDN removes origin CPU and storage pressure. That result is a roadmap lever (freeing app servers, cutting S3 egress), and it's the number an exec will actually approve.
• Not a runtime dependency: It does not generate image URLs for your app. Feature work still depends on the rokka/client PHP SDK (or direct API calls). Treat this as require-dev / globally installed developer tooling — a distinction that directly shapes your dependency policy.

When to Consider This Package

Adopt when:

• You have already chosen, or are actively trialing, rokka.io. The CLI is worthless without an account and API key; it is vendor-maintained tooling, not an abstraction layer.
• You want scripted, repeatable ops — stack/rendition configuration, alias management, cache invalidation — inside CI or a deploy runbook.
• Your team is PHP-centric and comfortable shelling out from Composer scripts or a Makefile.
• You need auditability of image config changes (CLI commands review well in PRs versus clicking through a dashboard).
• Recent releases matter to you: last published 2025-08-14 signals the vendor is still maintaining it.

Look elsewhere when:

• You need in-app image URLs at request time. Use the rokka/client SDK, not this. Confusing the two is the most likely adoption mistake.
• You are not on rokka. Evaluate the vendor's actual image quality, price, and latency first; the CLI is not a differentiator.
• Maturity is a hard requirement. Six stars and zero dependents means no community safety net, no Stack Overflow corpus, no third-party tutorials. Support is a vendor ticket, and bus factor is effectively the vendor's release cadence. That is acceptable for ops tooling and unacceptable for anything load-bearing.
• You want portability. Every stack config you author is rokka-shaped. If vendor lock-in on the image layer is a strategic concern, self-hosted Glide/Intervention keeps the config in your repo.
• You need Windows-native or GUI tooling for content editors — this is a developer/ops CLI, not a CMS surface.

How to Pitch It (Stakeholders)

To executives: This is a zero-cost (MIT) evaluation and operations tool for image delivery. It lets us test whether a managed image CDN replaces custom resizing code — a build-vs-buy decision with real money attached: engineering weeks not spent on a pipeline, plus reduced origin compute and bandwidth. The risk is contained: it's a developer tool, never shipped to production, so the only exposure is evaluation time. Recommend a two-week spike with a hard go/no-go on cost per image and p95 transform latency.

To engineering: Deliberately not an application dependency. Install globally or as a require-dev; keep it out of composer.json runtime requirements so it can never leak into a request path. Runtime URL generation stays with the rokka/client SDK behind a small internal interface — that interface is what protects us if the vendor changes. Put every CLI invocation behind a committed script so stack and alias changes are reviewable and reproducible. Note the adoption reality: 6 stars, 0 dependents, single-vendor maintenance. Fine for ops, disqualifying for anything in the critical path.