Forgot your rakazo password? How to get back into a self-hosted instance

You click "Forgot password", nothing ever arrives, and there is no error telling you why. On a default self-hosted install this is expected behaviour, unfortunately: rakazo sends recovery mail through an SMTP server (SMTP_URL in .env), and a fresh install has none configured — so the reset email is never sent. Here is the way back in, verified end-to-end on a disposable copy of our real server (25 October 2026): after the fix, the new password signed in and the old one was rejected.

First, the two quick checks

Still signed in anywhere? A phone app or a second browser that is still logged in is the fastest way back: open account settings there and set a new password immediately.
Did you configure SMTP after all? If SMTP_URL is set in your .env, use the normal "Forgot password" link and check spam. If it is empty, don't wait for an email that cannot exist — use the database reset below.

The database reset (tested)

Rakazo stores accounts in Postgres. The password itself is a Better Auth scrypt hash in the account table — so the fix is: generate a proper hash of a new password, and replace the stored one. Never paste a plain-text password or a random hash from a web generator; the format has to be Better Auth's, or sign-in will keep failing.

Step 0 — Back up the database

You are about to edit the account table of a live system. Take the 5-second backup from our backup guide first. If anything goes wrong, you restore and nothing is lost.

Step 1 — Generate the new password hash

On any machine with Node.js (your laptop is fine — the hash contains no server secrets):

mkdir rakazo-pwreset && cd rakazo-pwreset
npm init -y && npm install better-auth
node -e "require('better-auth/crypto').hashPassword('YOUR-NEW-PASSWORD').then(h => console.log(h))"

It prints one long line shaped like 9f2c…salt…:b41a…hash…. That whole line is what goes into the database in step 2.

Step 2 — Replace the stored hash

On the server, in your rakazo install folder, open the database prompt:

docker compose -f docker-compose.images.yml exec postgres psql -U rakazo -d rakazo

(If you changed POSTGRES_USER / POSTGRES_DB in .env at install time, use your values.)

Then run this one statement, with your email and the hash from step 1:

UPDATE account SET password='PASTE-THE-HASH-HERE'
WHERE "userId" IN (SELECT id FROM "user" WHERE email='[email protected]')
AND "providerId"='credential';

It must answer UPDATE 1. If it answers UPDATE 0, stop: either the email is spelled differently in the database (SELECT email FROM "user"; shows the accounts), or the account signs in with a social/OAuth provider only and has no password row — in that case, sign in with that provider instead.

Step 3 — Sign in, and kick old sessions (optional)

Sign in with the new password — in our verification this worked immediately. If you are resetting because you suspect someone else knows the old password, also delete existing sessions while you are in psql:

DELETE FROM session
WHERE "userId" IN (SELECT id FROM "user" WHERE email='[email protected]');

Every device then has to sign in again with the new password.

Prevent the sequel

Configure recovery email: set SMTP_URL (providers like Resend or Amazon SES hand out SMTP credentials) and EMAIL_FROM in .env, restart, and test "Forgot password" once while you are not locked out.
Store the password in a password manager — the instance owner password is the one credential with no back office behind it.
Keep the database backup routine from our backup & rollback guide; it is also your way back from most other account accidents.

Rather not touch the database? This reset is part of what our deployment service handles during setup — including configuring recovery email so you never need this page.

Verified 25 October 2026 on a throwaway copy of our production-style test instance (the live instance's accounts were not touched). Rakazo is in beta and its auth internals can change — if your version behaves differently, the official docs win.