Metabase Laravel Package

Product Decisions This Supports

• Embedded analytics without building a BI stack. This package wires a Laravel app to Metabase's signed-embedding flow, so the decision it unblocks is "ship customer-facing dashboards this quarter" versus "spend two quarters building charting, query, and permissions infrastructure."
• Build vs. buy for reporting. Metabase is the buy; this package is the glue that keeps the buy cheap. It reduces the integration from a bespoke JWT-signing module your team maintains forever to a thin, upgradeable dependency.
• Multi-tenant dashboard access. Signed embedding with per-request claims is the mechanism for "customer A sees only customer A's data." That makes it the technical enabler for tiered plans (self-serve analytics as a paid add-on) and for enterprise deals that require white-labeled reporting.
• Roadmap sequencing. Adopting this pushes "analytics" off the core engineering roadmap and onto a configuration task, freeing capacity for differentiators. Conversely, if the roadmap already includes a first-class reporting surface, this becomes a stopgap with a known migration cost.
• Internal vs. external audiences. The same integration typically serves both (ops dashboards internally, embedded reports externally), which changes the compliance and UX bar. Decide which one you are solving for before committing.
• Vendor concentration risk. Choosing Metabase plus a community-maintained Laravel bridge means a two-layer dependency. That is a deliberate, defensible trade for most teams, but it belongs in the risk register rather than in a sprint ticket.

When to Consider This Package

Adopt when most of the following hold:

• You are on a supported Laravel/PHP version and are comfortable adding a third-party bridge to your dependency tree.
• Metabase is already, or is about to become, your BI layer — this package is not useful standalone.
• You need signed embedding (per-user, per-tenant filtering via JWT claims) rather than public links or iframe-anything, which need no such package.
• Your team has, or can acquire, the operational basics: a Metabase instance, a shared signing secret, and a secrets-management story.
• You want the JWT/signing surface to be someone else's code to own. Version 0.4.2 swaps lcobucci/jwt for firebase/php-jwt, which is a healthy signal in one narrow sense — the maintainer is actively reducing dependency weight and standardizing on the most widely deployed PHP JWT implementation — and a caution in another: the token-signing path changed in a patch release, so validate your embedding flow end to end after upgrading.

Look elsewhere, or budget for a fork, when:

• You need vendor-backed SLAs. This is a community package on a 0.x version line. There is no support contract, and minor/patch releases can change internals.
• Your security posture forbids community-maintained auth-adjacent code. Signing tokens is security-relevant; some organizations will require an internal implementation (it is roughly a few dozen lines against firebase/php-jwt) or a first-party Metabase SDK.
• You need features beyond signed embedding — granular row-level permissions managed in-app, audit logging per view, or write-back — which this package does not attempt.
• You are not on Laravel. The value here is framework integration (config, service provider, facades); without that it is a thin wrapper you can replace.
• You are pre-product-market-fit. Standing up Metabase plus an embedding integration is real work; a hosted embedded-analytics vendor may be the cheaper path until the reporting requirements stabilize.

How to Pitch It (Stakeholders)

For executives: We can ship customer-facing analytics as an integration rather than a product build. Metabase provides the dashboards and query engine; this package connects it to our Laravel application so each user sees only their own data, authenticated by signed tokens. The decision it buys is time: roughly a quarter of engineering capacity redirected from charting plumbing to the core product. The cost is a small, community-maintained dependency in a security-adjacent path, which we mitigate by pinning versions, testing the token flow on every upgrade, and keeping a documented fallback to an in-house signer of similar size.

For engineering: This is a thin, idiomatic Laravel wrapper around Metabase's JWT signed-embedding contract — config publishing, a service provider, and token generation with claims you control. It is on a 0.x line, actively maintained, and the most recent release (0.4.2) is a refactor replacing lcobucci/jwt with firebase/php-jwt. That is a net positive for dependency footprint and library ubiquity, but it touches the signing path in a patch version, so treat the upgrade as behavior-affecting: verify claim payloads, token expiry, and per-tenant filtering in staging before release, and pin the exact version in composer.json. Expect to own the integration surface — secret rotation, claim schema, and error handling — regardless of what the package covers. If the signing logic is small enough that maintaining it is cheaper than tracking a 0.x dependency, write it yourself; the package's real value is convention and speed to first working embed, not irreplaceable logic.