Filament Panel Switcher Laravel Package

Product Decisions This Supports

• Multi-panel UX decisions: filament-panel-switcher adds a switcher UI so a single authenticated user can move between Filament panels (e.g. admin, vendor, customer, internal ops) without separate logins. This directly informs whether you consolidate multiple apps into one Laravel codebase with panel-scoped access, or keep them as separate deployments.
• Build vs. buy for navigation chrome: the switcher itself is low-value, easily reimplemented glue code. Adopting the package is a decision to spend ~zero engineering time on it and accept a small third-party dependency instead — reasonable only if the package's UX matches your panel topology.
• Roadmap signal — framework currency: v0.6.6 adds Laravel 13 support, meaning the package tracks current Laravel releases. If your platform roadmap includes upgrading to Laravel 13, this dependency will not become an upgrade blocker. Note it is the maintainer's first contribution, so the "tracks upstream" property is demonstrated once, not yet a pattern.
• Version/stability posture: still pre-1.0 (0.6.6) with no stated BC policy. Treat it as a UI convenience, not load-bearing infrastructure: pin the version, wrap it behind your own panel-registration config, and assume you may need to fork or replace it.
• Vendor/ops decisions: a single-maintainer package with one contributor on this release is a low-severity but real supply-chain consideration. It argues for keeping the integration surface tiny (no auth or authorization logic delegated to it) and for a documented fallback (custom switcher blade component) if maintenance lapses.

When to Consider This Package

Consider adopting when:

• You run two or more Filament panels in one Laravel application and users routinely need to cross between them; the package saves you writing and maintaining that navigation affordance.
• Your team is on or planning Laravel 12 → 13, and you want dependencies that will not block that upgrade — this release is specifically the compatibility patch.
• The switcher is cosmetic/navigational only: it is fine for convenience links, not for enforcing access control. Authorization must remain in panel access rules (canAccessPanel, policies, middleware).
• You are comfortable with pre-1.0 dependencies in the UI layer and will pin the version in composer.json.
• Your panel set is relatively static; if panels are created dynamically per tenant at scale, verify the switcher renders correctly under that load before committing.

Look elsewhere (or build in-house) when:

• You have a single panel — no value; the dependency is pure overhead.
• You need guaranteed BC, SLAs, or vendor support — this is a solo-maintainer, MIT-style package with no such commitments.
• You need the switcher to carry security semantics (e.g. impersonation, role elevation). Those belong in your own audited code, not a navigation plugin.
• You already have a custom top-bar/nav implementation or a design system that would need heavy overrides; the integration cost then exceeds writing the component yourself.
• Your stack is on an older Laravel/Filament pairing outside the supported matrix — this release only extends the upper bound; confirm the Filament major version compatibility explicitly rather than inferring it from the Laravel bump.

How to Pitch It (Stakeholders)

To executives (30 seconds): We're evaluating a small open-source add-on that lets a user jump between the different Filament admin panels we run in one application, instead of logging in separately to each. The latest release (v0.6.6) adds Laravel 13 support, so it won't hold back our planned framework upgrade. Cost is zero licence; the risk is low because it is a navigation-only component that we can replace in a day with in-house code if the single maintainer ever stops shipping. Recommendation: adopt behind a pinned version for the multi-panel UX, keep access control in our own code, and revisit if it stays pre-1.0 past our next major upgrade.

To engineering: Add henryonsoftware/filament-panel-switcher (pin to 0.6.6), register it in the panel provider, and verify it against our actual panel set and Filament version — the release notes confirm Laravel 13 compatibility but are silent on Filament major support, so test rather than assume. Keep the integration thin: no auth, impersonation, or policy logic routed through the package; canAccessPanel and middleware stay authoritative. Wrap its registration in our own config so a fork or a custom Blade switcher is a contained swap. Watch the repository for maintenance signals — v0.6.6 is the first contribution from this maintainer and the package remains pre-1.0 with no stated backward-compatibility policy.