Tentacles Laravel Package

Product Decisions This Supports

• Tenancy model selection (shared DB + tenant_id vs. database-per-tenant). Tentacles is a Laravel 5-era helper for the latter: it registers extra database connections and switches the default connection per request (typically by subdomain), and gives you tenant-scoped migration/seeder commands. Adopting or rejecting it is really a decision about whether tenant isolation is a product requirement (contractual data separation, per-customer restore, noisy-neighbour control) or just a nice-to-have.
• Build vs. buy for connection plumbing. The package is thin — connection registration, a resolver for the current tenant, and artisan commands. The "buy" case is roughly one to two weeks of engineering saved; the "build" case is ~300 lines of code you fully control. For a package last released in 2017 with 36 stars, the buy case is weak unless you are time-boxed inside an existing Laravel 5 app.
• Segmentation and packaging decisions. DB-per-tenant unlocks enterprise tiers: dedicated database, per-customer backup/restore SLAs, data-residency commitments, and "delete my data" requests that are a DROP DATABASE rather than a multi-table purge. That can justify a pricing tier and a sales motion.
• Roadmap / platform lifecycle calls. Because the package targets Laravel 5.x and PHP 7.0-era conventions, "do we adopt this?" is inseparable from "how long does this application stay on Laravel 5?" It is a marker of a legacy-codebase decision, not a greenfield one.
• Delivery-model choices for agency/internal work. It fits the pattern of spinning up one database per client site — a real, recurring use case, just one with a small blast radius where an unmaintained dependency is tolerable.

When to Consider This Package

Consider it only when all of the following hold:

• You are already on Laravel 5.x / PHP 7.x and cannot upgrade in the planning horizon.
• You need database-per-tenant, not row-level tenancy, and only for HTTP requests — verify for yourself whether console commands, queued jobs, and scheduled tasks correctly re-resolve the tenant, since packages of this vintage commonly handle only the web request lifecycle.
• The blast radius is small: internal tools, low-traffic client sites, a single team that can read and patch the source.
• You have accepted the maintenance risk: one maintainer, no release since November 2017, 36 stars, no visible security-response process, and a dependency graph that will not have tracked Laravel or PHP security releases.

Look elsewhere — or build it — when any of these are true:

• You are on Laravel 8+ or need PHP 8.x. Compatibility is the first thing to prove with a spike, not assume.
• You need tenant awareness beyond the DB connection: cache, filesystem, queues, sessions, search indexes, mail. That is where the real work is, and this package does not address it.
• You have compliance, data-residency, or enterprise security review requirements. An unmaintained 2017 dependency will not survive a vendor-risk questionnaire.
• You want a maintained, documented path: evaluate stancl/tenancy or spatie/laravel-multitenancy first, or hand-roll connection switching on top of Laravel's native config(['database.default' => ...]) and DB::purge().

The practical recommendation: do not adopt for new work. If it is already in production, pin the version, isolate it behind your own small tenant-resolution interface, and budget an exit.

How to Pitch It (Stakeholders)

To executives: Frame it as a risk, not an opportunity. This package would let us give each customer their own database — a real selling point for larger accounts — but it is a small, single-maintainer, unmaintained open-source component last updated in 2017. The capability is worth having; this specific implementation is not worth betting the platform on. Recommendation: if dedicated-database tenancy is on the roadmap, budget one to two weeks of engineering for a maintained package or an in-house implementation, rather than taking on a dependency that will fail a security review and block our Laravel upgrade path.

To engineering: It is a thin Laravel 5-era layer for registering per-tenant DB connections, resolving the current tenant per request (subdomain-style), and running tenant-scoped migrations. The value is small and reproducible; the cost is an orphaned dependency with an unknown compatibility surface against modern Laravel/PHP and likely gaps in queue/console contexts. Run a one-day spike if anyone wants proof, but default to stancl/tenancy, spatie/laravel-multitenancy, or a ~300-line in-house resolver behind our own interface. If it is already in the codebase, wrap it, pin it, and put a removal ticket on the roadmap.