Users & roles
No open sign-up
The first visit to a fresh instance creates the admin account. After that, accounts are created by an admin from Users → New user. There is no registration page and no invite link.
That is the right default for a self-hosted tool that will end up on a home network or behind a company VPN: the set of people who should have an account is small, known, and does not change often.
The two roles
| member | admin | |
|---|---|---|
| Own groups, add apps, share their own groups | ● | ● |
| Create, disable, delete accounts | ● | |
| Reset someone's password | ● | |
| Read the activity log | ● | |
| Access other people's groups |
That last row is not a typo. An admin has no access to anyone else's groups or bookmarks. Role governs management, not reach. An admin asking for a group they have not been given returns the same "not found" a stranger gets.
If an admin needs to see someone's board, its owner shares it with them, like anyone else.
Disabling versus deleting
Disabling is reversible and cheap. The account cannot sign in, and any session it already holds stops working on its very next request — there is no window where an old cookie keeps working. Their groups, their apps, and every grant they hold are untouched, so re-enabling restores exactly the access they had.
Deleting is permanent and takes everything with it: their groups, every app on those groups (including ones an editor added), and every grant they held on other people's groups. Groups they had shared with other people disappear from those people's boards.
Prefer disabling.
An account's audit trail survives deletion — the log records what was done, and losing that history because someone left would defeat the point of having it.
The last-admin guard
monoki refuses any change that would leave zero enabled admins: demoting the last one, disabling them, or deleting them. It also refuses letting you delete your own account.
Recovering an instance with no admin needs shell access, which is exactly why the guard is allowed to be strict — and why the escape hatch exists:
monoki create-admin --username andre
That works directly against the database file and does not care about the guard.
Passwords
Passwords are hashed with argon2id (64 MiB, t=1, p=4), with the parameters stored in the hash itself so they can be raised later without a migration.
Login is rate-limited per source address: ten failures in a minute locks that address out for five minutes, and the lockout holds even for the correct password.
Anyone can change their own password from Account. Doing so signs out every other session on that account, which is the point — if you are changing your password because you think somebody else has it, leaving their cookie working would make the change theatre.
An admin resetting someone else's password does not sign that person out.