- What is elfsundae/laravel-apps and when should I use it?
- It is an MIT-licensed Laravel package that adds a logical multi-application layer on top of standard Laravel conventions, letting one installation host several self-contained apps, each with its own routes, controllers, views, and config. It fits modular monoliths and multi-product codebases where you want separate route namespaces and view roots while still sharing the framework and vendor directory. It is a structuring convention rather than a runtime isolation boundary, so use it for organization, not for security separation.
- Is elfsundae/laravel-apps a multi-tenancy package?
- No. It partitions HTTP-layer concerns such as routes, controllers, views, and config within a single deployable Laravel codebase, but it does not isolate tenant data, credentials, or blast radius. If your requirement is per-tenant database separation or strict security boundaries, evaluate a dedicated tenancy package instead. Treating this package as tenancy would leave you with a false sense of isolation.
- How do I install elfsundae/laravel-apps?
- Install it with Composer using composer require elfsundae/laravel-apps. It ships the standard Laravel package shape: a service provider registered through package discovery and a publishable configuration file you can push into your app with the vendor:publish command. After publishing, you define your app directories and the convention used to select an app per request, then verify route and config caching before rolling it out.
- Which Laravel and PHP versions does elfsundae/laravel-apps support?
- The supported matrix is not something you should assume; check the package's composer.json constraints and its CI status against your target Laravel and PHP release before adopting. The package has a small user base and a single maintainer, so it is reasonable to expect it lags current Laravel majors until proven otherwise. Treat version compatibility as a hard gate and validate it before any sequencing or design work.
- How does elfsundae/laravel-apps choose which application handles a request?
- App selection is resolved at request time from the incoming request, typically via domain, subdomain, or path-prefix conventions defined in the package config rather than hardcoded per route file. The key thing to verify in your own project is that selection stays deterministic once routes and config are cached, since cached route registration can bypass resolver logic that runs dynamically. Write a test that boots each app under the route cache to confirm the correct app is chosen.
- Does the app boundary cover migrations, config, queues, jobs, and commands, or only HTTP routing?
- The documented scope is HTTP-layer partitioning: routes, controllers, views, and likely per-app config. Background contexts are the risk area, because convention-based partitioning often assumes per-request state that does not exist in queue workers, scheduled tasks, or artisan commands. Before adopting, confirm that jobs and commands receive an explicit app context rather than inheriting a leaked one, and extend the convention yourself if migrations and storage are not covered.
- Does elfsundae/laravel-apps work with route caching and config caching?
- It should work, but this is exactly the area to test rather than assume, because app-scoped route registration and late config resolution are common failure points under caching. Run php artisan route:cache and config:cache in a staging environment with every app registered and confirm each entry point still resolves to the right app. Also measure cold-start overhead, since loading multiple app directories can add cost to every request.
- Can I run elfsundae/laravel-apps alongside an existing tenancy package?
- Possibly, but conflicts are most likely in route registration and config resolution, where both packages want to influence how the framework boots. Prototype the combination in a branch with your tenancy package installed and unused first, then enable one app and watch for duplicated or missing routes. If the two overlap, prefer keeping tenancy strictly at the data layer so app partitioning stays an HTTP-layer concern.
- Is elfsundae/laravel-apps still maintained and safe to use in production?
- It has roughly 84 GitHub stars and a single maintainer, so assume there is no meaningful community scrutiny, no CVE triage, and limited responsiveness to issues. The practical stance is to fork and vendor the package into your own namespace so you can patch it, and to check the last commit date and trailing-twelve-month issue cadence before committing. The larger risk is silent constraint on framework upgrades later, not failure at install time.
- How hard is it to remove elfsundae/laravel-apps later?
- Removal cost depends entirely on how deeply the app-directory convention spreads through your routing, config, and namespaces, and it is genuinely expensive once every team has adopted it. A package that is costly to rip out deserves a higher bar, so pilot it with one low-risk app and keep cross-app imports out of the codebase via lint and CI checks. If you cannot describe the exit path in a paragraph, do not adopt it.