Profiles & kids mode

A household shares one server but not one taste. Accounts are the security boundary; profiles are the people.

Users vs profiles — two different things, on purpose

PurposeSecurity
UserAn account with a password. Owns permissions.A real boundary
ProfileOne person's taste and place in the library.Not a boundary

A self-hosted install typically has one or two accounts. Each profile carries its own history, resume points, highlights and watchlist. Profiles have no password — switching is a convenience, exactly as every streaming service treats it. Anything that must be enforced lives on the account, and the admin panel enforces its own permissions regardless of the active profile.

Roles

RoleCan do
super_adminEverything, including granting roles
adminManage the catalogue and settings
ownerSame as admin; kept for installs that used it
memberBrowse the catalogue, rate and annotate

The first account registered on a fresh install becomes the owner automatically.

Kids mode

A profile can cap the highest rating it may see, and the cap is enforced everywhere:

  • every browse page,
  • every search query,
  • and the detail, watch and stream routes directly — so a direct link doesn't slip past the filter. Filtering only the browse pages while a pasted URL still plays would read as working while failing, which is precisely the bug this design exists to prevent.

Unrated titles pass through. Most music and books carry no certification, and excluding them would empty a kids profile rather than protect it. If your kids profile exists to gate films and TV, this is the behaviour you want; know it's there.

Locked out?

A self-hosted install has no reset email configured, so password resets happen at the server's console:

php artisan user:password you@example.com

It verifies the new credentials actually authenticate before reporting success.