Phumbor Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on image delivery. Thumbor is the self-hosted "buy-ish" option: you run the service, but you get smart cropping, format negotiation, and URL-based transforms without paying per-transform SaaS fees. This bundle is the cheap decision-enabler — it turns "should we stand up Thumbor?" into a config block instead of a custom integration project, so you can prototype the URL scheme and signing story before committing infrastructure.
• Roadmap sequencing for media features. If your backlog has "user avatars," "listing thumbnails," "responsive srcset," or "OG image generation," the transform URL contract is the thing you want locked early. Wiring phumbor in behind a small service lets you ship UI against thumbor/{width}x{height}/smart/{url} semantics before the service even exists in every environment.
• Where image logic lives. URL-based transforms keep resize/crop policy out of your application code and CDN config. That's a product decision as much as an architecture one: it means marketing can change a hero crop by changing a URL, not a deploy.
• Architectural signal worth flagging: this is a Symfony bundle, not a Laravel package — it ships a DI extension and configuration tree. For a Laravel codebase it is a reference implementation, not a dependency. The underlying 99designs/phumbor client is the actual reusable asset; in Laravel you'd bind it in a service provider in ~20 lines.
• Upgrade tax is now a real line item. As of 4.0.0 the bundle tracks Symfony 8 and has dropped unsupported Symfony versions — a hard major bump with no feature content. That reinforces the "thin bridge" thesis (a major version is only a compat statement), but it also means: if we standardize on an older Symfony line, we pin 3.x and own the divergence; if we adopt, adopt at 4.x. Note the decision is cheaper on Laravel, where we never inherit the bundle's version constraints at all.
• Explicitly not a decision it supports: it does nothing for upload, storage, or moderation. Don't let it get scoped into a media-pipeline epic — it is strictly the URL-signing and URL-building layer.

When to Consider This Package

Adopt when all of these hold:

• You are on Symfony (or willing to consume only 99designs/phumbor directly), and you already have, or are about to have, a Thumbor instance.
• Version fit: on Symfony 8, use 4.0.0. On Symfony 6/7, you must pin the 3.x line — 4.0.0 dropped older Symfony support as its entire change set, so there is no functional reason to force the bump and no functional gain if you can't.
• You need signed URLs (security key + HMAC) — this is phumbor's real value; unsigned Thumbor is trivially abusable as a free image-resizer.
• Your transform surface is small and stable: resize, fit-in, smart crop, filters.
• You value a thin, MIT-licensed, replaceable dependency over a heavy abstraction.

Look elsewhere when:

• You're on Laravel. Use 99designs/phumbor directly; a bundle's config tree is dead weight, and you also avoid inheriting Symfony-major churn like 4.0.0. Vendor the ~30 lines of service wiring yourself and own it.
• You want managed image delivery. Imgix, Cloudinary, or even a plain CDN with pre-generated derivatives removes an operational service (Thumbor needs its own compute, storage, and a security key you must rotate). Running Thumbor well is a real ops cost, not a footnote.
• You need uploads, storage, moderation, or DAM. None of that is here.
• You need ecosystem support. ~26 stars and zero dependents means no Stack Overflow corpus. Budget for reading the source — fortunately it's small.
• You need a supported vendor SLA. One maintainer, still shipping (4.0.0 confirms the project is alive and tracking current Symfony), but a single point of failure. A compat-only major is a good maintenance signal and simultaneously a reminder that there's no team behind it.

Risk read for the record: the dependency is low-risk despite low adoption precisely because it's a thin bridge over a stable client. Worst case, inline it. 4.0.0 strengthens that read rather than weakening it — a release whose whole content is "support Symfony 8, delete unsupported versions" is what a well-behaved thin package looks like. Say so explicitly so nobody pattern-matches "26 stars" or "major version bump" to "too risky" without nuance.

How to Pitch It (Stakeholders)

One line: A small, MIT-licensed Symfony bundle that connects our app to Thumbor, the self-hosted image-resizing service — so image crops and sizes become a URL, not a code change.

To executives: It's the glue, not the product. It lets us evaluate self-hosted image delivery cheaply — no per-transform SaaS bill — and defer any vendor commitment until we know our volume. Cost is near-zero to try; the real decision it informs is "run Thumbor vs. pay Imgix/Cloudinary," and it makes that decision reversible. The 4.0.0 release is a Symfony 8 compatibility bump with no new features — the project is current and maintained, but by one person; mitigated by the fact that it's ~1 file of config and can be inlined in an afternoon.

To engineering: Symfony-only; the reusable core is 99designs/phumbor. It gives us DI-configured, HMAC-signed transform URLs, which is the piece we'd otherwise hand-roll badly. 4.0.0 adds Symfony 8 support and drops older Symfony versions — pin 4.x on Symfony 8, pin 3.x otherwise, and note that on Laravel the version question disappears entirely because we'd vendor the wiring ourselves. Recommend we adopt it (or its 20-line Laravel equivalent) only behind our own ImageUrlService interface — no bundle types leaking into domain code, so swapping to a managed provider later is a one-class change. Treat Thumbor's security key as a secret with rotation, and confirm we have capacity to run and monitor the service before this becomes load-bearing.