Hyn Nova Laravel Package

Technical Evaluation

Architecture fit. This is thin glue between two opinionated, version-locked frameworks: Laravel Nova (a commercial admin panel) and hyn/multi-tenant (a tenant orchestration layer). It does not introduce tenancy or admin capability — it surfaces an existing tenancy model inside Nova via resources for tenants/domains. Fit is strong only if your baseline is already "hyn for tenancy, Nova for admin." For any other architecture it is a pattern reference, not a dependency.

Integration feasibility. Low-to-moderate on modern stacks. hyn/multi-tenant is effectively end-of-life (releases target the Laravel 5.5–6.x / PHP 7.x era). Nova is commercial and tightly versioned to Laravel majors. This package sits at the intersection of two version-locked, partly abandoned upstreams, so a drop-in install on Laravel 10/11 is unlikely without a fork.

Technical risk. High, from three compounding sources: (1) abandoned upstream tenancy package with stale transitive dependencies and CVE exposure; (2) Nova licensing, upgrade cadence, and resource-API churn; (3) tenant-context handling inside Nova requests — the Nova central app runs without a tenant, so every resource query must be explicit about central vs. tenant connection. Context-switch bugs here manifest as silent cross-tenant data exposure rather than visible errors.

Key questions.

• Which exact Laravel / Nova / hyn / PHP versions are targeted today, and is that matrix supported?
• Is hyn/multi-tenant maintained internally or forked, and who owns it?
• What is the isolation model — single DB with tenant_id, or DB-per-tenant — and does the toolkit handle it explicitly?
• Does the package resolve central vs. tenant connections per resource, or does it rely on ambient middleware state?
• Who owns Nova licenses, and what is the upgrade contract?
• Is this a stopgap or a strategic, load-bearing dependency?

Integration Approach

Stack fit. Assumes Laravel + Nova + hyn/multi-tenant on PHP 7.x. On Laravel 10+/PHP 8.2+, treat this as a reference implementation: extract resource definitions and tenant/domain bindings rather than installing the package.

Migration path. Two clean options. (a) Already on hyn: pin versions, wrap the package, and freeze the stack. (b) On modern Laravel: reimplement the Nova resources against a maintained tenancy layer (stancl/tenancy or spatie/laravel-multitenancy), reusing this package's shape. Avoid straddling both — partial adoption is where context bugs live.

Compatibility. Lock Laravel, Nova, hyn, and PHP as a single tested set. Nova major versions break resource classes; hyn's service-provider boot order matters for tenant bootstrapping. Treat the matrix as a contract, not a guideline.

Sequencing.

1. Confirm version matrix and Nova license posture.
2. Spike: stand up Nova + hyn in a sandbox; validate tenant/domain CRUD and context switching end-to-end.
3. Define isolation guarantees explicitly and write tests that attempt to violate them.
4. Only then wire into production admin flows.
5. Document a fork/exit plan before it becomes load-bearing.

Operational Impact

Maintenance. Effectively self-maintained. Budget a named owner and expect to fork for PHP/Laravel bumps; upstream activity is minimal.

Support. Community-only at 12 stars — no vendor, low issue/PR throughput. Nova support will not cover third-party tenancy glue, and hyn maintainers are unlikely to respond. Escalation path is "we fix it."

Scaling. Admin-surface load is modest (Nova is CRUD); the real scaling concern is query patterns across tenant connections — N+1 across tenants, and central dashboards that enumerate every tenant. Multi-DB tenancy scales by adding connections; all-tenant reporting is the bottleneck.

Failure modes.

• Tenant context bleed — one tenant's data rendered in another's Nova view. Silent, severe, the primary reason to gate adoption on isolation tests.
• Broken Nova upgrades after resource-API changes.
• Service-provider boot conflicts between hyn and Nova.
• Stale dependency CVEs inherited from the tenancy layer.
• Orphaned tenants after failed provisioning.
• Admin lockout if the central connection is misconfigured.

Ramp-up. Low once running; onboarding is the cost. Engineers must understand two frameworks plus the glue, and the tenant resolution rules must be documented explicitly. Realistic: a few days for a Laravel developer to be productive, materially longer to be safe with isolation.

TPM recommendation. Low strategic value, high ongoing risk surface. Adopt only if already committed to both hyn and Nova and can pin the stack; otherwise mine it for patterns and build directly on a maintained tenancy layer.