Users and roles

Everyone who uses the control panel has an account and exactly one role. The role decides what they can see and do — and because roles are rows rather than code, you can adjust them without a deploy.

Adding someone

There are two ways, and which you want depends on whether you are at a terminal or not.

From the control panel. Go to Users, choose Invite, and give a name, email address and role. They receive a link and set their own password, so nobody ever has to send a password to anyone.

From a terminal. Useful for the very first account, or on a server where mail is not set up yet:

bin/rails nibble:admin:create

It asks which role, then a name, email address and password. On a deployed server, run it inside the container:

bin/kamal app exec -i 'bin/rails nibble:admin:create'

Passwords must be at least 12 characters with a lowercase letter, an uppercase letter, a number and a symbol. The same rule applies everywhere — invitations, resets, and someone changing their own.

The roles that ship

Role	Can
Administrator	everything, including users, roles and settings
Editor	all content, assets and forms; redirects, trash and utilities
Author	create entries and edit their own; view terms; upload assets
Contributor	create entries and edit their own; view terms and assets
Viewer	look, not touch

The difference between Author and Contributor is uploading: an Author can add images, a Contributor can only use what is already there.

Give people the smallest role that lets them do their job. It is not about distrust — it is that a smaller role means fewer ways to break something by accident on a busy afternoon.

Roles of your own

Open Roles in the control panel and you will find every ability as a checkbox, grouped by what it touches: each collection, each taxonomy, assets, forms, users, settings. Create a role, tick what it should allow, and assign it to people.

Abilities are fine-grained by design. “Can edit blog posts but not pages”, “can publish but not delete”, “can see form submissions but not export them” are all expressible without writing any code.

Administrator is the exception: its role grants everything, rather than listing abilities one by one. That is why new features are immediately available to administrators and have to be granted deliberately to everyone else.

The last way in

At least one role must grant full access at all times. Nibble refuses to remove the last one, or to strip the ability that makes it complete.

This is not bureaucracy. A site with no administrator cannot be repaired from inside the control panel — it needs somebody at a terminal with bin/rails nibble:admin:create, which is a bad afternoon nobody should have by accident.

Signing in, and staying signed in

Under the user menu each person can change their own password, manage their sessions and turn on two-factor authentication.

Two things happen automatically and are worth knowing about before they surprise you:

• Sensitive screens ask for the password again before they open — users, roles, API tokens, imported content. A borrowed laptop should not be enough to add an administrator.
• The panel locks itself after a period of inactivity, with a warning first so nothing in progress is lost.

Removing someone

Deleting a person in Users removes their access immediately and ends their sessions. What they wrote stays where it is — entries record who created and last changed them, and that history survives the account.