Multi User Bundle Laravel Package

Product Decisions This Supports

• Account model architecture: Whether each persona gets its own user entity (separate tables/models for buyers vs. sellers, patients vs. clinicians, tenants vs. landlords) while sharing one login form — versus a single user table with roles. This bundle exists specifically to make the former viable, so it directly informs that schema and auth decision.
• Login UX roadmap: Whether the product ships one universal login screen across user types or separate branded entry points. A shared-form-with-discriminator approach reduces support burden and simplifies navigation, and this package is the reference implementation of that pattern.
• Build vs. buy on authentication plumbing: The "user discriminator" logic (detect which user type is attempting login, route to the correct provider, handle per-type registration forms) is deceptively fiddly. This package is the buy-side option — it packages that routing so the team doesn't hand-roll it.
• Use cases it maps to: Marketplaces, healthcare portals, education platforms (student/teacher/parent), multi-brand franchises, and B2B/B2C hybrids where one product serves distinct account types.
• Caveat for roadmap planning: It is a Symfony bundle, not a Laravel package. For a Laravel product, the equivalent decision is native guards/providers plus a multi-auth package — this repo is only useful as a reference design for how the discriminated-login pattern is structured.

When to Consider This Package

Consider it when:

• You maintain a legacy Symfony application (Symfony 3/4 era) already using Doctrine ORM/ODM and, typically, FOSUserBundle.
• You genuinely need distinct user entities per persona with a single shared login form — not just roles on one user model.
• The work is short-term or internal, with an accepted, documented exit plan.
• You want a pattern reference — reading its discriminator/provider structure is faster than designing multi-user auth from scratch.

Look elsewhere when:

• You are on Laravel. Use guards + providers, Fortify/Sanctum, or a maintained multi-auth package. This bundle will not install or apply.
• You are on Symfony 5+ / 6+. FOSUserBundle is itself deprecated; Symfony Security's ChainUserProvider, custom UserProvider, and modern authenticators cover this natively. Don't resurrect an archived bundle to solve a solved problem.
• Security posture matters — and it always does for authentication. Archived, 159 stars, 0 dependents, low opportunity score means no security patches, no maintainer response, and no community validation. Never let an archived package own your login path.
• You need SSO, OAuth2, MFA, or passkeys. Go to maintained Symfony Security integrations.
• You need a signal of ecosystem health. Zero dependents is a strong negative indicator: nobody has stress-tested this in production at scale.

How to Pitch It (Stakeholders)

Executives: This is a small, archived Symfony component that solves one narrow problem — letting several distinct account types share a single login screen. It is not a strategic asset and not a dependency we should adopt. Recommendation: do not take it on. Authentication is security-critical, and archived code receives no patches; the reputational and compliance exposure outweighs any time saved.

Engineering: Treat PUGXMultiUserBundle as a design reference, not a library. Its value is the discriminated-login pattern: one form, a discriminator service that identifies the user type, and per-type providers and registration forms. If we're on Laravel, we replicate that shape with native guards and providers in a few days — cleaner, testable, and supported. If we're on legacy Symfony with FOSUserBundle, it's a defensible stopgap with a dated removal ticket, never a permanent layer.

The one-line decision: Copy the pattern, not the package.