Filament Cookie Consent Laravel Package

Product Decisions This Supports

• Compliance roadmap sequencing. Turns "GDPR/CCPA compliance" from an open-ended legal ask into a scoped, shippable increment: the package ships the banner, consent storage, and a config surface. Useful when legal has flagged cookie consent as a launch gate and you need a defensible v1 rather than a bespoke build.
• Build vs. buy for a non-differentiating feature. Cookie consent is table stakes, not product surface. This is roughly a day of integration work (composer require, two migrations, plugin registration) versus designing consent UX, persistence, and i18n in-house. Default recommendation: buy, unless the consent flow itself is a differentiator (e.g., you sell consent management to other companies).
• Self-serve operations for Legal/Marketing. The Filament settings page makes banner copy, privacy-policy URL, colors, position, and theme editable by non-engineers. That's a recurring decision you can de-couple from the release train — legal copy changes stop consuming sprint capacity.
• Go-to-market expansion decisions. 19-language support plus a compliance-type selector (info / opt-in / opt-out) means you can ship into a new market without re-platforming. When evaluating "can we launch in DE/BR/CA this quarter," this materially lowers the answer's cost.
• Measurement and ad-spend decisions. The Google Consent Mode v2 toggle is the interesting one: it lets you gate analytics and ad tags on consent without tearing down filament-gtm/filament-gtag. If you're spending on paid acquisition in a consent-regulated market, this is the difference between compliant attribution and blind optimization — a real revenue-adjacent call, not a checkbox.
• Deployment topology decision (admin-facing vs. customer-facing). Important scoping note: this plugin injects the banner into a Filament panel via render hooks. That fits internal admin apps, back-office tools, and gated B2B portals. It does not solve consent for your public marketing site or customer-facing Laravel app unless that surface is itself a Filament panel. Roadmap implication: you may be buying two solutions, not one.
• Vendor and dependency risk register. Single maintainer, 9 stars, 0 dependents, and minor-version bumps that raise the minimum Filament version (3.2.1 required filament/filament ^5.3 due to an upstream Page::routes() change). This is a "budget for ownership" decision: you're adopting source you'll likely maintain, not a product with support.
• Architecture decision: coupling consent to the Filament version cadence. Because 1.x/2.x/3.x track Filament 3/4/5, adopting this hard-links your consent implementation — and its upgrade timing — to your admin panel upgrade. Worth an explicit ADR if you plan to stay on Filament 4 for a while.

When to Consider This Package

Reasonable fit when:

• Your consent-relevant surface is a Filament panel (internal admin, ops tooling, partner portal) and you need a compliant banner quickly.
• You're on Filament 5.x with Laravel 11+ and PHP 8.2+ — i.e., the current 3.x line, which is where maintenance is happening.
• You want consent copy and styling owned by Legal/Marketing, not engineering.
• You need multi-market language coverage without commissioning translations of banner strings.
• You're already comfortable with spatie/laravel-settings — the package assumes a published settings migration and a DB-backed config table, and it inherits that library's model.
• You're gating Google tags and want Consent Mode v2 wiring handled for you.

Look elsewhere when:

• The surface is public-facing. Use jeffersongoncalves/laravel-cookie-consent directly, or a dedicated CMP, for the marketing site. Two implementations of consent = two places to be wrong.
• You need a real consent management platform. A settings-backed banner with a fixed third-party JS asset does not give you granular per-vendor consent records, consent receipts, audit trails, or category-level toggles. If your compliance posture requires demonstrable per-purpose logging, this is a starting point, not a solution.
• You're on an older Filament major. Support exists (1.x/2.x) but lags; pinning to a legacy branch of a 9-star package shifts maintenance onto you.
• You need vendor SLAs, security review artifacts, or named support. There's no commercial backing here — MIT, one author, no dependents.
• Version churn is a constraint. Consecutive breaking changes on the Filament minimum and repeated refactors onto a filament-plugin-core base mean you should expect upgrade work, and you should pin exact versions with a lockfile.
• You're uncomfortable with third-party client-side assets. Assets are configured as CSS/JS URLs — you'll want to self-host and pin them rather than hotlink, and review them before they touch a page with auth tokens.
• You have no Filament panel at all. Then this is the wrong package, full stop.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a compliance requirement — cookie consent under GDPR/CCPA — that is mandatory, undifferentiated, and currently blocking launches in regulated markets. Instead of building it, we can adopt an MIT-licensed plugin for our admin panel: integration is roughly a day, it gives Legal a self-serve settings screen so copy changes don't consume engineering sprints, and it supports 19 languages plus a Google Consent Mode v2 toggle so our analytics and paid-media measurement stay both compliant and accurate. Cost is effectively zero in licensing, low in engineering time, and the main risk is maintenance: it's a small single-maintainer project, so we should plan to own it rather than depend on it. Recommended decision: adopt for the admin panel, and make a separate, explicit call on the public site.

To engineering (pitch): This is a thin Filament wrapper over jeffersongoncalves/laravel-cookie-consent — it registers render hooks into <head> and end-of-<body>, so there are no Blade templates to touch, plus a settings page backed by spatie/laravel-settings. Setup is composer require, publish the Spatie settings migration, publish and run the cookie-consent migration, then register CookieConsentPlugin::make() in the panel provider. You can disable the settings page with ->settingsPage(false) if you'd rather keep configuration in code.

Things to explicitly own on the engineering side:

• Pin the version. Breaking changes have landed on minor bumps (minimum Filament raised in 3.2.1; a refactor onto a plugin-core base in 3.3.0). Use exact constraints and commit the lockfile.
• Self-host the assets. The CSS/JS are configurable URLs — vendor and pin them rather than hotlinking, and confirm the consent script renders before GTM/gtag (the package authors have accounted for this; verify in your own stack).
• Verify the claim, don't inherit it. "GDPR & CCPA compliant" is the maintainer's framing. Have legal or a DPO confirm the banner behavior and consent persistence meet our actual obligations, and treat info vs opt-in vs opt-out as a legal decision, not a default.
• Scope honestly. This covers the Filament panel only. Public-site consent is a separate line item.
• Plan for abandonment. Zero dependents and one maintainer means a real fork path. Budget a small standing allocation for tracking upstream changes on Filament majors, and keep a branch point where we can vendor the code if needed.

Bottom line: Low-cost, high-convenience solution to a mandatory non-differentiating problem, scoped to the admin panel — adopt with eyes open on maintenance ownership and with compliance sign-off confirmed independently.