Filament Keyable Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side key/token management. If your roadmap includes an "API keys" or "integration tokens" screen inside a Filament panel, this package is the candidate to buy: it replaces a custom Filament resource, secret-issuance/revocation actions, and the reveal-once UX that teams typically spend 1–3 engineering days rebuilding. The decision it informs is narrow and real: do we staff this screen, or adopt?
• Roadmap unlock for self-serve integrations. A shipped key-management UI is the last-inch dependency between "we have an API" and "customers/partners can turn it on themselves." The plugin provides the operator surface only — token model, scopes, rate limiting, and auth remain yours, which keeps the blast radius of adoption small.
• Localization as a go/no-go gate — this is what 1.2.0 changes. The release adds 16 locales (ar, az, de, fa, fr, hi, it, ja, nl, pl, pt, ru, tr, uk, uz, zh_CN), including RTL (Arabic, Farsi) and CJK. That converts "admin tooling available only in English" into a defensible option for non-English ops/support teams — a decision that previously would have required funding translation work in-house.
• Prioritization signal: don't fund this internally. The maintainer rolled the same i18n initiative out across his Filament plugin family, with the contributor credited as co-author. Language coverage is becoming table stakes in this ecosystem, so it is not a differentiator worth owning.
• What this release does not decide. No breaking changes, no new capabilities, no deprecations: dependency bumps, CI/changelog housekeeping, and funding links alongside the translation PR. Treat 1.2.0 as patch-equivalent risk. It should not reopen any prior architecture decision.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Filament and want a key/token admin surface without building a resource.
• The scope is genuinely CRUD-plus-revoke for keys attached to Eloquent models — an internal or operator-facing screen, not a customer-facing security product.
• You can tolerate a single-maintainer, community-governed dependency with a small issue/PR history.
• Your localization needs are covered by the newly shipped locales and you accept community-contributed strings.

Look elsewhere (build in-house, or use a dedicated service) when:

• You need compliance artifacts: audit trails per key use, rotation policy enforcement, vault/HSM-backed secret storage, SOC 2 evidence. The plugin is a UI layer and will not supply these.
• You need fine-grained scopes, expiry workflows, or usage metering enforced server-side — you will be writing that regardless, at which point the UI savings shrink.
• Your admin surface isn't Filament, or you run a Filament major the plugin hasn't pinned support for.
• You require an SLA, multiple maintainers, or a security review cadence the project doesn't publish.
• Due diligence before committing: confirm the keyable model/trait contract and secret-handling behavior against your own auth layer during a spike, and spot-check translation completeness and RTL rendering in your Filament version — contributed locale files are often partial, and shipping a half-translated admin screen is worse than an English one.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship the API-key management screen on our roadmap by adopting a free, MIT-licensed Filament plugin instead of building it, avoiding roughly 1–3 engineering days plus permanent maintenance on a screen that differentiates us in no way. The new 1.2.0 release is additive only — 16 new interface languages (including Arabic, Farsi, and Chinese) and routine dependency maintenance, with no breaking changes — so upgrading is low-risk. The real exposure is governance, not code: the package is maintained by one person. We mitigate by pinning the version, keeping token issuance logic in our own service so the plugin stays a replaceable UI shell, and accepting that we may vendor or fork it if it goes stale.

For engineering: additive dependency, no API changes in 1.2.0. Integrate behind our own token service so the plugin never owns secret storage or policy. Pin to ^1.2, vendor or fork on abandonment, and treat translation files as upstream-owned so we don't absorb i18n maintenance for the admin surface. Verify the keyable trait contract and RTL rendering in a short spike before committing to the roadmap date.