Metabase Bundle Laravel Package

Product Decisions This Supports

• Embedded analytics build-vs-buy: If the roadmap includes dashboards inside your product (internal ops tooling or customer-facing reporting), Metabase + signed embedding is one of the cheapest credible paths. This package only addresses the glue layer — generating signed embed URLs and wiring config — so the decision it informs is "do we adopt Metabase as our BI engine and hand-roll the embed plumbing, or pay for a purpose-built embedded analytics vendor?"
• Time-to-market for an internal reporting surface: For an admin/back-office panel where stakeholders want charts next sprint, this reduces the embed work to configuration plus a route. That is a scoping decision — it can move "reporting v1" from a multi-week ticket to a spike-sized one.
• Customer-facing vs internal-only scoping: Signed embedding is a supported Metabase pattern, but the security boundary (who signs, what the token grants, tenant isolation) is a product decision, not a library one. This package does not make that decision for you; it just makes the URL generation ergonomic.
• Buy-in risk assessment: Stars 0, zero dependents, single release in 2024, no visible maintenance cadence. That is a dependency-risk input to the roadmap: adopting it means owning a fork or accepting that you will replace it with ~50 lines of your own code when it breaks against a future Metabase or framework version.
• Not a differentiator: Nothing here changes what users can do. It is pure infrastructure — treat it as an accelerator for an experiment, not as an architectural commitment.

When to Consider This Package

Adopt only under a narrow set of conditions:

• You have already committed to Metabase as the BI backend, and signed embedding (not the interactive dashboard iframe or the full-app embed) is the pattern you need.
• You are on Symfony, not Laravel. The name and packaging ("bundle") strongly suggest a Symfony bundle with DI configuration. Despite being filed under Laravel/PHP, verify the composer.json type and service-provider/bundle registration before anyone plans around it. If you are on Laravel, this is likely the wrong artifact entirely — you would be writing a service provider wrapper around it, which erases the value.
• The embed surface is internal or low-stakes. Prototype, internal ops console, a POC for a customer-facing dashboard. Not a path for anything with SLAs, multi-tenant data isolation requirements, or an audit obligation.
• You are comfortable reading and patching the source. With zero dependents and no community, you are the maintainer. Budget for that explicitly rather than pretending it's a normal dependency.

Look elsewhere — or just write it yourself — when:

• You need production-grade support. The Metabase JWT signing flow is genuinely small: sign a payload with your embed secret, put it in the iframe URL. That is a few dozen lines and a config value. For a 0-star dependency, the build-vs-buy math usually favors "build" purely on the maintenance and audit surface.
• You need multi-tenant scoping, row-level permissions, or parameter locking. Those are Metabase configuration concerns; a thin bundle won't model them, and getting them wrong is a data-leak class of bug.
• You are on Laravel and want idiomatic packages. Look for a maintained Laravel package or a first-party SDK path instead.
• You need to support multiple BI backends or swap vendors later. A vendor-specific bundle in your dependency graph is a soft lock-in; an internal adapter is not.

How to Pitch It (Stakeholders)

To executives: This is a tiny convenience library for embedding Metabase dashboards into our app. It could shave days off a reporting prototype, but it is unmaintained in practice — no stars, no downstream users, one release — so it is a prototype accelerant, not a platform bet. Recommendation: use it to demo embedded analytics quickly if we're already leaning Metabase; do not let it become a dependency in anything customer-facing without a plan to replace it with in-house code, which is small.

To engineering: It handles signed embed URL generation and configuration for Metabase. Verify the framework fit first — the "bundle" naming points at Symfony, so confirm it isn't a mismatch for our Laravel codebase. Assume we own it: no community, no issue triage. Given the JWT signing is ~50 lines, the honest options are (a) spike with it this week to validate the UX, then (b) either vendor the useful bits or reimplement behind our own interface so the vendor choice stays swappable. Treat the security boundary — signing secret handling, tenant scoping — as ours regardless of what the package does.