Skip to main content
Password login is the default (AUTH_MODE=local). You set your password during the first-run setup, and after that any browser that can reach your instance can sign in with it. No extra configuration is needed — if you haven’t touched AUTH_MODE in .env, you’re already in this mode.

​
Setting your password

You choose your password during First Run, when you enter the one-time setup token that the API prints to its log. The token is single-use and expires the moment the instance is claimed — after that, your password is the only credential needed to sign in.

​
Resetting your password

If you forget your password, run this command on the host machine to reset it:
The command prompts you for a new password, sets it immediately, and signs every active browser session out. Run it only from the host machine — it is deliberately not available over the network. To sign everyone out without changing the password, use revoke-sessions instead:
Neither command touches your personal access tokens. Revoke those from Settings → Access tokens once you are back in.

​
Getting a 429 Too Many Attempts error

plamotrack slows down login attempts from any address that submits repeated wrong guesses. The delay doubles with each failure and tops out at five minutes; after ten quiet minutes the counter resets. Everyone behind one resolved address shares the slowdown — a household NAT, or a proxy you have not listed in TRUSTED_PROXIES — and nobody else’s guesses touch it. Behind the per-address slowdown there is also one allowance for password checks shared by every address, so a flood of guesses from many addresses cannot make the instance check passwords without limit. This means:
  • A genuine typo or two won’t lock you out — you’ll just wait a few seconds.
  • A sustained flood of guesses from one address will be heavily throttled, but your own guesses from that address share the same slowdown.
A few tips if you hit this:
  • Wait it out. The backoff resets after ten minutes of no attempts from your address.
  • Use a browser that still holds a session cookie this instance recognises — one whose session idled out, or that a host-side reset-password or revoke-sessions ended. It draws on a separate, reserved allowance that nobody without such a cookie can use. A browser that signed out normally holds no cookie, and neither does one restored from a backup older than the session it remembers, so from those you compete with the flood for the shared allowance: wait for a gap, or block the flood at your proxy.
  • Block the flood at your proxy. If someone else is hammering your instance, stopping the attempts upstream is more effective than waiting for the instance’s counters to clear.
  • Restart the API container. This resets all counters and clears all backoffs immediately:
Restarting stops the rate limiting but does not stop the flood itself — block the source at your proxy or firewall if the guesses are coming from outside.

​
Session length

A session ends after 14 days without use, and after 30 days in any case — then the browser asks for your password again. Sign out from the sidebar to clear your session immediately — signing out also removes the session cookie from your browser, so the next visit will ask for your password again.
To switch to sign-in via Google or another provider, see OIDC Login. Switching signs all active browser sessions out and your password becomes unused. Switching back to password mode also signs everyone out.