Tenant Aware Bundle Laravel Package

Product Decisions This Supports

• Multi-tenancy architecture choice: Informs the build-vs-buy call on the tenant configuration resolution layer — whether to ship a single codebase with per-tenant config overrides versus separate deployments or per-tenant forks. This package is a narrow, opinionated implementation of the former.
• White-labeling and plan-tier roadmap: Directly supports decisions about per-tenant branding, limits, feature flags, and third-party credentials (mail, payments, queues, storage). If your roadmap has an "Enterprise" or "Agency" tier with tenant-specific behavior, this is the class of component that unblocks it.
• Feature scoping: Helps the team decide how much of the tenant model is configuration (resolved at boot/runtime from a bundle) versus data (resolved per-request from models/scopes). This package only solves the former — valuable for scoping, because it forces the question early.
• Buy-vs-build triage: At 27 stars and zero dependents, the realistic decision is "use as reference implementation" rather than "adopt as dependency." Reading its config-resolution approach is a legitimate input to an internal design doc even if you never install it.

When to Consider This Package

Consider it when all of the following hold:

• Your stack is Symfony — this is a Symfony bundle, not a Laravel package. It will not drop into a Laravel app; Laravel's service provider/config repository model is different. For Laravel, the comparable choices are stancl/tenancy or spatie/laravel-multitenancy.
• You need configuration isolation only — per-tenant settings, not per-tenant database schemas, model scoping, or queue/job tenancy.
• Your tenant config surface is small and declarative (keys, values, credentials) rather than complex domain logic.
• You can vendor or fork the code and accept ownership of it.

Look elsewhere when:

• You are on Laravel, or your app spans multiple frameworks.
• You need database-per-tenant, tenant-aware ORM models, or cross-tenant admin tooling.
• You require active maintenance, security patch cadence, or a community to escalate to. Zero dependents and 27 stars is a strong signal of single-maintainer, low-bus-factor code — treat it as a starting point, not a foundation.
• Your config needs are dynamic/computed per request; a bundle-level config layer may become a bottleneck.

How to Pitch It (Stakeholders)

For executives: There's an open-source component that addresses a real cost in our multi-tenant roadmap — per-tenant configuration (branding, limits, credentials) without forking the codebase. It's small, focused, and free. However, it's a Symfony bundle with minimal adoption and no downstream dependents, so it is not something we'd take as a production dependency without owning it. Recommendation: budget a short spike to evaluate its approach (1–2 engineer-days) as design input, and plan to implement the resolution layer in-house against our framework. This de-risks the roadmap item without introducing a supply-chain or maintenance liability.

For engineering: The package implements tenant-scoped configuration resolution as a Symfony bundle. It is conceptually useful and directly relevant if any of our services are Symfony-based; it is inapplicable to our Laravel services as-is. Low adoption means we should read the source, not composer require it — unless we are prepared to fork, pin, and maintain. Key evaluation questions: how does it resolve the active tenant (request, host, header, context)? Does it compose with Symfony's config cache? What happens on cache warmup with N tenants? Answer those, and we have our own spec.