Multi-tenancy

Arrel has no multi-tenancy strategy of its own, neither by domain, nor by subdomain, nor by database, because there are already good ones in the Laravel ecosystem (stancl/tenancy is the usual one) and there is no point in reinventing a worse one. Instead, it exposes two hooks for you to plug yours into:

1. TenantResolver

namespace Arrel\Tenancy;

interface TenantResolver
{
    public function resolve(): mixed;
}

Implement it and bind it in the container:

final class StanclTenantResolver implements TenantResolver
{
    public function resolve(): mixed
    {
        return tenant();
    }
}

// AppServiceProvider::register()
$this->app->bind(TenantResolver::class, StanclTenantResolver::class);

Once bound, $this->tenant() is available inside any Resource:

public function canViewAny(): bool
{
    return $this->tenant()->hasFeature('students');
}

public function getEloquentQuery(): Builder
{
    return parent::getEloquentQuery()->where('tenant_id', $this->tenant()->id);
}

With no TenantResolver bound, $this->tenant() returns null, Arrel works just as well in an application without tenancy, with nothing to configure.

2. Middleware

// config/arrel.php
'middleware' => [
    \App\Http\Middleware\IdentifyTenant::class,
],

This middleware runs before authentication and Arrel's own routing, on all the panel's web and API routes. It is where you identify the tenant from the request (domain, subdomain, header...) and activate the corresponding database connection, so that by the time Arrel queries any Resource it is already resolving against the right database.

Neither of these two hooks forces anything on how you define "tenant": it is an interface and a middleware slot, not a system.