7 months ago
If u have that issue, just type in custom start command "n8n user-management:reset && n8n start", it will not deploy, but u will be able to change password, then abort deploy, then type in custom start command "n8n start" and everything will work fine ;)
1 Replies
16 days ago
n8n user-management:reset is the correct emergency command when email password reset is unavailable, but it must be run once, not left before n8n start in the permanent Start Command.
n8n's documentation says this command returns user management to the pre-setup state and removes all user accounts. If the Start Command remains n8n user-management:reset && n8n start, every restart or redeploy can reset the accounts again.
A safer Railway sequence is:
-
Back up the n8n database/volume first.
-
Confirm the service still uses the same persistent data source. For the standard SQLite deployment, the Railway volume should be mounted at
/home/node/.n8n. For Postgres, keep the same database variables on the service. -
Temporarily set the Start Command to only:
n8n user-management:reset -
Deploy once and wait until the log confirms that the reset command completed. It is expected for that one-shot deployment to exit afterward.
-
Immediately restore the Start Command to:
n8n start -
Redeploy, open the n8n URL, and create the owner account again.
Do not abort the reset while it is writing to the database, and do not delete or wipe the volume. The official references are:
- n8n CLI user-management reset: https://github.com/n8n-io/n8n-docs/blob/main/docs/deploy/host-n8n/configure-n8n/use-the-command-line.md#user-management
- Railway n8n persistent-volume path: https://docs.railway.com/guides/n8n#attach-persistent-storage
This resets the instance's user accounts; it is not a routine password-change command. Once access is restored, configuring SMTP password resets avoids having to repeat this emergency recovery.