Filament Banhammer Laravel Package

Product Decisions This Supports

• Feature scope: user moderation / trust & safety. This package provides the admin-facing surface for banning and unbanning models (typically users) inside a Filament panel — and, as of v2.0.0, also for authorization gating plus IP and country blocking. That expands it from "a ban toggle" to "a first-pass enforcement toolkit," which changes the decision from do we build a button to do we adopt an enforcement layer.
• Build vs. buy for admin tooling. The real decision is not "ban or don't ban" but "do we spend engineering days building Filament actions, table columns, filters, policies, and confirmation dialogs, or adopt a small MIT package?" With v2.0.0 the scope now also includes authorization wiring and network-level blocking, so the comparable in-house estimate should be re-run — it is a larger build than the v1 package replaced, but also a larger surface to own.
• Roadmap sequencing. Useful for deciding whether enforcement lands in the current cycle or later. If moderation is table-stakes for launch (marketplace, community, UGC, SaaS with public signups), this de-risks shipping it on time. New sequencing constraint: v2.0.0 requires Filament ^5.7 (up from ^3.2), so this feature is now gated on your panel's Filament major version. If you are on Filament v3, adoption means a framework upgrade first.
• Policy product decisions the package forces into the open: who can ban (now partly answered — authorization support was added in v2.0.0), whether bans are reversible, whether a reason/note is captured, whether the banned user is notified, and whether an audit trail exists. The package answers more of these than v1 did, but the remainder is still a product decision, not an engineering one.
• New policy surface introduced by IP/country blocking — these are product decisions, not just features: do we block by IP at all given CGNAT/shared IPs and false positives? Do we block by country, and can we defend that to a customer or regulator? How long do we retain IP data, and is that in our privacy notice? Who is authorized to add a country block, and how fast can we reverse one? Adoption of v2.0.0 pulls these onto the roadmap whether or not you intend to use them.
• Support-ops enablement. Lets non-engineers (trust & safety, support leads) act on abuse reports from the admin panel instead of filing engineering tickets. With IP/country blocking, that delegation now extends to controls with much wider blast radius than a single-user ban — a wrong country rule can lock out a whole market. Staffing and SLA assumptions should account for who holds that permission.
• Not a strategy. It remains an operator's console, not a trust-and-safety program. It does not replace decisions about graduated enforcement, appeals, evasion detection by determined actors (VPN/proxy defeats IP and country blocks), or data retention.

When to Consider This Package

Consider it when:

• You are already running Filament v5 (^5.7) + Laravel and the moderation workflow lives in that admin panel. This is now a hard prerequisite, not a preference.
• Your ban semantics are simple: a boolean/soft ban with an unban path and no complex lifecycle — and you optionally want coarse IP/country blocking alongside it.
• The audience is internal staff, not end users — low blast radius, easy to swap out later.
• You need it now and can absorb the cost of forking if the maintainer goes away.
• You want to validate the moderation workflow before investing in a bespoke build.

Look elsewhere or build in-house when:

• You are on Filament v3 or v4. v2.0.0 is a breaking major bump requiring ^5.7; do not adopt on the assumption of an easy downgrade path.
• You need a full suspension lifecycle: temporary/time-boxed bans, graduated escalation, appeals, notifications, ban reasons surfaced to users, and immutable audit logs. That is a domain model, not a UI package.
• Ban state must propagate beyond a database flag — session invalidation, API token revocation, queued-job guards, billing suspension. Verify explicitly whether v2.0.0 enforces at authentication/middleware level or only records a flag; a flag that isn't enforced is a security-theater risk. The addition of IP/country blocking suggests an enforcement layer now exists, but its scope and bypass behavior must be confirmed, not assumed.
• IP or country blocking would be customer-visible in a regulated or high-false-positive context. Shared IPs, corporate NAT, mobile carriers, and VPN users make IP blocks imprecise; country blocks raise lawful-access, sanctions, and app-store policy questions. If you cannot tolerate collateral lockouts, use this only for the manual single-user ban path.
• Multi-tenant or scoped moderation is required (an admin banning only within their org). Authorization support helps, but verify whether it is per-resource policy or per-tenant scoping.
• You have compliance obligations (GDPR erasure, retention windows, right-to-appeal) that need to be modeled deliberately — IP capture and retention in particular now needs an explicit position.
• Supply-chain sensitivity: still a small, single-maintainer package with no meaningful downstream validation or community security review. The v2.0.0 jump to Filament v5 and the broadened enforcement scope mean more privileged code in the admin surface, not less. Treat it as unpinned third-party code in a privileged path.

Minimum due diligence before adoption (updated for v2.0.0): confirm Filament v5 / Laravel version support and the upgrade path from v1; review the published migration and schema, including any new IP/country storage columns and their indexes; confirm what happens to active sessions on ban; confirm unban is truly idempotent; establish whether IP/country rules are enforced at middleware level or advisory only; check for allowlists/escape hatches so a mistaken block is reversible without engineering; confirm where IP data is stored, for how long, and whether it flows into logs or exports; and check license and issue tracker activity.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that gives our admin console working ban/unban controls for abusive accounts without a custom build, and the new major version adds authorization plus IP and country blocking on top. It converts a multi-day engineering task into a short evaluation, and it's reversible — worst case we remove it. Two caveats worth knowing up front: v2.0.0 requires Filament v5, so there may be a framework upgrade in front of us, and IP/country blocking raises policy questions (false positives, data retention, who can pull that lever) that we should decide rather than default. It does not constitute our trust-and-safety strategy; we still own policy, appeals, and audit.

To engineering: The v2.0.0 bump is breaking — filament/filament moves from ^3.2 to ^5.7 — so scope it as "adopt package + validate panel on Filament v5," not a composer update. Budget roughly two to four days including review of the migration, the new IP/country schema, and the enforcement path. Recommended integration pattern is unchanged: treat it strictly as a UI and enforcement adapter layer, keep ban domain logic and the bans schema under our ownership, and wrap calls behind our own service so we aren't locked into the package's API. Add tests around enforcement — session invalidation, token revocation, IP/country matching against allowlisted and shared-IP cases, and admin authorization — because the package's value is cosmetic unless the ban actually blocks access. Pin the exact version and isolate usage to a single resource so a fork or replacement stays cheap.

To product/design: This unblocks the moderation workflow screens, not the moderation policy. Before adoption we need decisions on: who can ban, whether bans are temporary, whether reasons are captured and shown to users, whether users are notified, and what the appeal path is. v2.0.0 has added a second decision set we did not have before — whether we use IP blocking, whether we use country blocking, how we handle false positives for shared IPs, how long we retain IP data, and who is authorized to apply a network-level block. Anything on either list the package doesn't cover becomes our backlog, so scope it now rather than discovering it in the admin panel later.

Headline risk to flag once: small maintainer footprint, no meaningful dependent base, single maintainer. A major-version jump to Filament v5 signals active maintenance — which is good — but also that we should expect breaking changes on the package's own cadence. Assume we may inherit maintenance. That is acceptable for an internal admin convenience; it is not acceptable as a load-bearing security control, and that caution now applies more strongly to the IP/country blocking features than to the original ban toggle.