Hyn approach to tenancy

Global integration

Each tenant is neatly integrated into any functionality you can come up with globally. Packages from the root vendor folder, global routes, all files in the public directory etc..

Another benefit of both the global functionality ánd a system connection is the ability to use global users and localized (tenant-only) users.

Terminology

• Hostname; a resolvable domain to connect to the application.
• Website; technically most closely an implementation of a tenant, can have multiple hostnames and allows for tenant specific logic. A website has its own folder.
• Customer; hostnames and websites belong to a customer. They have a name, e-mail address. Previously (v1.x) we incorrectly named these Tenants.

Tenant seperation

Each tenant is seperated from another tenant both by files and by database.

The files seperation applies to the following:

• composer.json, full composer functionality, generates a vendor directory.
• providers.php, allows registering service providers and other runtime code.
• routes.php, used to set up specific routes for this tenant.
• config, allows overruling global configuration files, use at your own risk.
• lang, allows using a seperate tenant specific set of language files.
• media, a publicly available directory, eg for using images in views or stylesheets.
• vendor, in combination with the composer file allows using any packages for only this tenant.
• views, used for instance for blade or twig templates.

Database mutations

Both the native migrate and seed commands have been gracefully extended to add a tenant option, allowing for easy database management. Or if you want mutation on all tenants at the same time. Ofcourse mutation can also be ran on the system connection alone by leaving out the tenant option in both those commands.