Accounts and access

When you first start Savorum, there’s no sign-in: it opens straight to your library. That’s local mode, and it’s fine while only you, on the same computer, can reach it. Before anyone else uses Savorum, or you open it from another device, turn on sign-in. Your recipes, preferences, and history are kept.

Turn on sign-in

Nobody can claim Savorum from the web: you create the first administrator on the machine that runs it.

1. While Savorum is stopped, or still in local mode, create the administrator:

   savorum user create-admin --database /var/lib/savorum/savorum.db --login chef

   It asks twice for a password, between 12 and 1024 bytes, and prints the account’s user ID. Note the ID: other account commands need it. This account takes over your existing library.

2. Start Savorum with sign-in on, and the address people will type:

   savorum serve \
     --database /var/lib/savorum/savorum.db \
     --assets /var/lib/savorum/assets \
     --listen 127.0.0.1:8080 \
     --auth-enabled \
     --public-url https://recipes.example.com

3. Sign in, then add a passkey and save recovery codes. See Your account and sign-in.

Running in Docker? See Turn on sign-in for the container version.

Invite people

An account on its own reaches no library. Give each person a role in each library they need:

• Viewer reads recipes and books.
• Editor also adds and changes recipes.
• Owner also manages the library and who can use it.

To invite someone:

1. Open Your account → Your libraries and choose Manage access for the library.
2. Under Invite someone, choose the Library role and how many days the link lasts, from 1 to 30.
3. Choose Create invitation and copy the link. It’s shown once.
4. Send the link privately. Savorum sends no email.

An invitation grants only that library role, never administration, and can’t be reused once it’s accepted, revoked, or expired. To add someone who already has an account, ask for the Savorum user ID on their account page and use Add member.

As administrator, you can also create an account yourself under Instance administration, or from the command line with your own user ID:

savorum user create --database /var/lib/savorum/savorum.db --actor ADMIN_USER_ID \
  --login cook --password-file /run/secrets/cook-password

To grant roles from a company sign-in service’s groups, see Single sign-on.

Remove someone

Disabling an account is the normal first step. It stops sign-in and ends their sessions at once, and keeps their memberships and shared history.

Deleting an account first needs someone else to own any library they own alone. It removes their sign-in methods, sessions, preferences, and personal recipe state. Shared libraries show them as “Former user”. The last active administrator can be neither disabled nor deleted.

Retire a library

When a library is no longer needed, its owner opens Manage access, chooses Retire library, and types the library name to confirm. Nobody can reach it after that. At least one other library must remain.

Retiring is not secure erasure. The content and its history stay in the database and in backups. Retiring never deletes an account or anything in another library.

See who did what

Savorum records sign-ins, permission changes, and anything destructive, such as permanent deletions. Administrators read it in Instance administration → Audit history. Library owners see their library’s Activity on its access page.

Events are kept indefinitely, and Savorum offers no way to edit or delete them. That doesn’t make the history tamper-proof: anyone who controls the server or its database can change it.

Integrations and API tokens

People create their own personal API tokens; see Your account and sign-in. You set how long tokens last with --token-default-days (90 by default) and --token-maximum-days (365). Tokens that never expire need --token-allow-nonexpiring. Disabling an account or removing a membership applies to its tokens at once, with no need to reissue them.

Recover administrator access

If you lose the administrator’s sign-in, reset the password from the machine that runs Savorum:

savorum user reset-password --database /var/lib/savorum/savorum.db \
  --user-id ADMIN_USER_ID --password-file /run/secrets/recovery-password

This replaces the password, signs that account out everywhere, and records it in the audit history. It doesn’t change anything at an outside sign-in service. Anyone who can reach the database can do this, so protect access to the server as you would the administrator’s password.

Good to know

• Passkeys are tied to the hostname in --public-url. Changing it later breaks existing passkeys, so make sure everyone has a second way to sign in before you move.
• No email address or mail service is involved.
• Without a terminal, give the password from a file with --password-file; - reads standard input. There’s no password flag or password environment variable.
• Sessions last 30 idle days or 180 days in total. Change this with --session-idle and --session-absolute, using durations such as 720h. The total must be at least the idle time. See Configure an instance.
• Failed sign-ins slow down for a while, but nothing locks an account permanently.
• Checking a password takes a lot of memory, so Savorum handles at most two sign-ins at once. Others get 503 authentication-rate-limited and can try again a moment later.
• An HTTPS public URL makes session cookies Secure. A password reset ends all of that person’s sessions.

Next: Set up secure remote access.