Skip to content

First start

The instance is up and the login page is open. What happens next decides who owns it. The account on this page is the one you sign in with: the instance’s own. The first bank account, a passbook or a PEA, comes later and is a separate matter: see Your first account.

After that, an administrator hands out the role with Make admin, under each account’s role in Managing users. That is the role the first account gets.

  1. On the login page, follow Create an account. Email, username and a password of at least twelve characters; the rule is written under the field, and a password that is long but guessable is refused, with the reason given.

  2. You are signed in, and you are the administrator. Settings → Administration now appears in your settings, and only in yours.

  3. Close sign-ups there, unless the instance is meant to take more people. The switch is separate from the .env variable, and Open registration explains which of the two wins.

An ordinary user cannot promote themselves, and the Administration tab does not appear for them. An administrator names them from that tab, as Managing users describes.

A reset request creates a link valid for one hour, and where that link goes depends on whether this instance has a mail server. A fresh instance has none, so it goes to the application log, where an administrator with server access reads it:

Terminal window
docker compose logs app | grep "reset link"

Give it a server and the link is emailed to the account instead. You can configure one in two places, the same two as every other setting of the instance: the SMTP_* variables of .env, read at boot, and Settings → Administration, which stores its own values and takes over as soon as you save there. The screen shows where the active values come from. Send a trial posts one message to your own address and shows the server’s refusal when there is one, which is how you spot a wrong port or a wrong encryption box. Configuration lists the variables.

Nothing about this is required. A server that is unreachable, refuses your credentials or presents a certificate nothing trusts never stops the application from starting and never fails the reset request: the link falls back to the log, exactly as above.

The link is built from PUBLIC_URL either way. That variable holds the address your users reach the instance at, not the name the machine knows itself by. Leave it at its default and the link points to localhost, and nothing is emailed at all: a one-hour link to an address only the server can open would be worse than reading it from the log. So the link goes to the log, with a line naming the variable. Any other value is taken as written, so a stale one still sends you to an address that does not answer.

Next: Behind a proxy if the instance is to be reached from outside the machine.