User Bundle Laravel Package

Product Decisions This Supports

• Framing: this is not a Laravel package. enhavo/user-bundle is a read-only subtree split of the Enhavo CMS monorepo, built on Symfony full-stack. Any decision to "leverage" it is really a decision to adopt Enhavo CMS, not to pull in a discrete user/identity component.
• Build vs. buy for user/role management in a CMS context. If we are evaluating content-heavy platforms, Enhavo's user bundle is the piece that supplies users, groups, roles, and the admin-facing management UI. That is table stakes for an editorial product, so it belongs in the buy-side comparison rather than the build column.
• CMS/editorial roadmap fit. Relevant only where the roadmap is an admin-driven, complex-data-structure content platform — Enhavo's stated strength. It does not inform roadmaps for SaaS onboarding, consumer auth, or API-first products.
• Multi-role / multi-tenant admin requirements. Role and group primitives support decisions about editorial permissions, approval workflows, and back-office access segmentation.
• Not a signal of ecosystem quality. Zero stars, zero dependents, and "readme" maturity are artifacts of the subtree-split distribution model — consumers install the monorepo, so the split's metrics measure nothing. Do not treat them as a proxy for project health; check the main enhavo/enhavo repository instead.

When to Consider This Package

Consider it only as an indirect consequence of choosing Enhavo:

• The team has already standardized on Symfony full-stack and has selected (or is seriously shortlisting) Enhavo CMS for content management.
• The product needs an out-of-the-box admin user/group/role surface and we do not want to assemble one from Symfony Security plus custom CRUD.
• We are comfortable inheriting the monorepo's release cadence, since the split carries no independent versioning or support guarantee.

Look elsewhere when:

• The stack is Laravel. Use Laravel's first-party auth scaffolding (Breeze/Jetstream) or Filament paired with a permissions library such as Spatie's. Installing a Symfony bundle into Laravel is not a supported path and should be rejected in review.
• The stack is Symfony but not Enhavo. Use Symfony's native security component and user provider; this bundle's value is its integration with Enhavo's administrative layer, which you will not get standalone.
• We need a stable, independently versioned, standalone identity package. The read-only subtree split explicitly disclaims standalone ownership: "for further information check the main repository."
• We need SSO, MFA, social login, or modern identity features. Nothing in the README indicates these are in scope; a dedicated identity provider or a maintained auth library is the safer bet.
• Anything user-facing or high-assurance. A zero-dependency, zero-signal split is not a base for security-sensitive decisions without a full audit of the parent project.

How to Pitch It (Stakeholders)

To executives: This is not a package we adopt on its own — it is one module of an open-source Symfony CMS, published as a read-only artifact of that larger project. It is worth attention only if we decide to evaluate Enhavo as a content management platform. The apparent lack of traction (0 stars, 0 dependents) reflects how the project distributes its code, not its real maturity, so any go/no-go should be based on an assessment of the main Enhavo repository, its release activity, and its maintainers. My recommendation is not to treat this as a standalone dependency decision.

To engineering: Treat enhavo/user-bundle as a subtree split: never fork or patch it directly, and never depend on it outside an Enhavo install. If Enhavo is in scope, pull it in via the main project's dependency graph and pin to the parent's releases. If we are on Laravel, this is out of bounds and the answer is Laravel-native auth plus a permissions library. Either way, the diligence we owe is on the upstream repository — commit cadence, security posture, Symfony version support, and upgrade path — not on this split's metadata.