Users and passwords

The users collection holds every account that can sign in to the Payload Admin. It is registered by default (users: true).

Enlarge screenshot

Accounts and accessLink to this section

The default collection uses username login and also accepts email, which remains required. Sessions expire after 24 hours. Five failed login attempts lock an account for five minutes. The collection also stores a display name and optional image avatar.

Reading and updating your own account is allowed; other accounts require users.read or users.update. Creating and deleting accounts require their matching capabilities. Roles and per-user grants have separate users.roles.read, .create and .update checks. Server hooks reject privilege escalation and self-lockout. Developer accounts without the admin role are hidden from non-developer reads, including author relationship pickers.

With Posts enabled, changing a public byline name or avatar invalidates affected post and listing caches.

RolesLink to this section

Each user carries one or more roles and optional per-user capabilities. What each role may do is described in Access control.

PasswordsLink to this section

Every password input in the Admin (login, create first user, account, user edit, reset password) gets a show/hide button. Where a new password is set, a generate button next to it fills both fields with 20 random characters, shows them and copies them to the clipboard, and a checklist below tracks the rules: at least 8 characters, an uppercase letter and a number. A tip suggests symbols such as - _ / @ ! ? * + = . $ # & % without requiring them; any other symbol is accepted too. The generator uses the same set and leaves out ~ and ^, which are dead keys on several European keyboard layouts. A generated password can contain $ or #, so quote it when it goes into a .env file or a shell command.

A password that meets the rules can still be easy to guess, like Website2026!. The Admin checks it in the browser with zxcvbn-ts (opens in new tab), adding the site's host name and the user's name, username and email to its dictionary, and shows a note when the password scores below 3 of 4. The note is advisory and never blocks a save. zxcvbn and its dictionaries load only when a new-password form opens.

The rules themselves are enforced on the server for create, update and resetPassword over REST and GraphQL. The Local API (seeds, scripts, tests) is not checked. Existing passwords keep working until they are changed.

withSysthema(config, {
  users: {
    passwords: {
      enforce: true, // default; false keeps the checklist but stops rejecting
      jev: { apiKey: process.env.TYPESAFE_API_KEY }, // optional, off by default
    },
  },
})

jev adds a second opinion from TypeSafe's Jev (opens in new tab) for passwords that pass every local check. It runs only for signed-in users, through the server endpoint POST /api/systhema/password/guessable, so the key never reaches the browser. This sends the candidate password in plain text to TypeSafe, which retains requests unless your plan includes zero data retention. Leave it off unless that is acceptable for the project. If the call fails, the check is skipped.

RelatedLink to this section

• Access control
• Media