A Frona install can host more than one user. Each user has their own agents, chats, memory, and policies. Admins manage the user list from the Frona UI.

Self-registration

By default the Register link on the login page is open: anyone who can reach the URL can create an account. For a personal install this is usually fine. For a shared install you'll want to close it and add users manually.

Toggle this with auth.allow_registration in the config file or FRONA_AUTH_ALLOW_REGISTRATION env var:

auth:
  allow_registration: false

When registration is off, the Register page returns an error and the only way to create an account is the admin Add user flow described below.

Admin group

Frona has one built-in privileged group: admins. Members can:

• List all users
• Create users directly
• Promote or demote other users (toggle their admins membership)
• Deactivate or reactivate accounts
• Delete users (and everything they own)

The first user created during setup is automatically added to admins. After that, admins promote each other manually.

Frona refuses any action that would leave the install with zero active admins. You can't demote, deactivate, or delete the last admin. Promote someone else first.

Personal settings vs. Server Settings

Settings are split in two:

• My Settings (/settings) — everyone has this. Profile, Channels, Skills, MCP, and your personal Vault connections. Changes here only affect your own account.
• Server Settings (/admin/settings) — admin-only. Providers, Models, shared Skills, Search, Voice, Browser, the server Vault, Sandbox, Authentication, Single Sign-On, Users, Timezone, and other instance-wide configuration.

Admins reach Server Settings through the Administration dropdown in the top bar. The dropdown only appears for admins — a regular user never sees it. Because is_admin is resolved at sign-in, admin controls show up immediately after login without a page reload.

You can delegate just user management without making someone a full admin: grant the list_users permission (see Cedar User principal below). That user then sees the Administration dropdown with only the Users entry, and nothing else.

The Users page

In the Frona UI, open Administration → Users (under Server Settings). The page is visible to admins and to anyone granted the list_users permission.

You'll see a list of every account on the server, with an Admin badge for members of the admins group and a greyed-out row for deactivated accounts. Each row has actions:

Action	Effect
Grant admin / Revoke admin	Add or remove the user from the admins group.
Deactivate	Block sign-in and disable refresh tokens. The account and all its data are kept. Reactivate any time.
Reactivate	Re-enable a deactivated account.
Delete	Permanently remove the account and everything it owns — agents, chats, tasks, credentials and vault connections, apps, MCP servers, channels, memories, policies, API tokens, and any linked SSO identities. Running apps are stopped and MCP servers uninstalled as part of the delete. This cannot be undone; use Deactivate if you might want the account back. The last admin can't be deleted.

Adding a user

1. Click Add user.
2. Fill in Handle, Name, Email, and an initial Password.
3. (Optional) Check Make admin to add them to the admins group.
4. Click Create.

The Handle is the user's permanent identifier — 2–32 characters, must start with a lowercase letter, and contain only a-z, 0-9, -, or _. It's used in storage paths (data/users/<handle>/...), policy entity IDs, and URLs, and cannot be changed later. The Name is the editable display name shown in the UI.

Frona doesn't email the new user. Share the password out of band, and have them change it on first login.

Cedar User principal

Admin actions are gated by the same policy engine the rest of Frona uses. The relevant entities:

• Principal Policy::User::"<user_handle>". The admin performing the action.
• Actions Policy::Action::"list_users" and Policy::Action::"manage_users".
• Resource Policy::User::"<target_user_handle>", or the sentinel Policy::User::"*" for list actions.

The built-in system policy permits these actions only when the principal is in admins. If you need a more granular setup (e.g., a user manager who can add accounts but not promote anyone), write a custom permit policy targeting manage_users on a specific group of users.

Tips

• Set up a second admin early. If you lose the first admin password and there's only one admin, you'll have to reset the database. Promote a second admin as soon as you've created one.
• Prefer deactivate over delete. Deactivated users keep their data; if they come back, you flip a switch. Delete is permanent and now removes everything the user owns in one action — agents, chats, apps, credentials, and SSO links included — so reach for it only when you really want the account and its data gone.
• Lock down registration on shared installs. Anyone who can reach the URL with allow_registration: true can create an account. Turn it off if the install is reachable from the internet and you don't want public signups.

Next steps

• Setting Up Authentication. Encryption secret, PATs, key rotation.
• Single Sign-On. Replace local password login with Google, Okta, etc.
• Policies. Write custom rules for the manage_users action.