Cannot log in after reboot on n8n 1.88.0 (Self-hosted Startup Plan previously activated and cancelled)

Questions
1

Hello,

We are encountering a serious issue and would appreciate any help.
@ihortom @jon

Our Situation:

  • We upgraded our self-hosted n8n server (VPS) to v1.88.0 about two weeks ago.
  • Everything was functioning normally until we rebooted our VPS today.
  • After rebooting, the system forces us into the Create Account page, even though all user, workflow, and credentials data still exist in the sqlite database.

Actions We’ve Already Taken:

:white_check_mark: Created a backup of database.sqlite.

:white_check_mark:Verified user table has correct globalRoleId and instanceOwnerRoleId.

:white_check_mark:Confirmed all records in workflow_entity have a valid createdById.

:white_check_mark:Confirmed all records in credentials_entity have a valid createdById.

:white_check_mark:Confirmed all records in shared_workflow and shared_credentials have valid createdById.

:white_check_mark:Confirmed all records in folder have valid createdById.

:white_check_mark:Verified passwords are correctly hashed in bcrypt format ($2a$10$).

:white_check_mark:Performed a VACUUM operation on the database.

:white_check_mark:Verified migrations table has 80 entries and no missing migrations.

:white_check_mark:Inserted userManagement.skipInstanceOwnerSetup = true into the settings table to skip Instance Owner setup.

:white_check_mark:I have clear the license key after taking all actions you see above

Additional Context:

  • We previously purchased the Self-hosted Startup Plan from n8n to enable multi-user features.
  • However, due to a billing misunderstanding, we cancelled the Startup Plan recently.
  • During the Startup Plan activation, we had two user accounts configured.
  • After cancellation, we are uncertain whether the system properly reverted back to “single-user mode.”
  • We suspect that residual configurations from the Startup Plan might be causing the current issue, forcing n8n to expect a full “multi-user structure” even though we are now back to Community mode.

Problem:

➡️ Despite all corrections, we are still stuck at the Create Account screen after reboot .

Our Questions:

:white_check_mark:Is it possible that the cancellation of the Self-hosted Startup Plan left the database structure or internal system state inconsistent?

:white_check_mark:] If so is there a recommended process to revert a previously Startup-enabled system safely back to Community Edition?

:white_check_mark:Can you advise how we can bypass the forced “Create Account” page and restore our original users?

Environment Info:

  • n8n version: 1.88.0
  • Deployment: Docker on VPS (Ubuntu 22.04)
  • Database: SQLite
  • Previous plan: Self-hosted Startup Plan (cancelled)

Thanks so much for your assistance! :pray:

We really appreciate it because our business heavily depends on our n8n system.

Chun Liang Hsu
CEO
Universal Vinyl Music
[email protected]

2

@hse_David ,

  1. Do you have all the users set up in user table?
  2. In settings table, what do you have for the key userManagement.isInstanceOwnerSetUp? Is value set to “true” and does loadOnStartup has 1?
  3. Are you using the very same ENCRYPTION_KEY?
3

Thank you very much for your guidance.

Regarding your first question about the user table, here is a detailed update from our side:

We checked the user table inside our SQLite database.

Below are the current users we have:

id email firstName lastName globalRole

•	Both users have properly hashed passwords.
•	isPending field for both users is 0 (not pending).
•	deletedAt field is 0 (not deleted).
•	createdAt and updatedAt timestamps are properly recorded.
•	Both users have valid globalRoleId linked to their roles.
•	settings and personalizationAnswers fields are populated as well.

From what we can see, the table structure and user data appear complete and healthy, with no missing fields or corrupted records.
We also ensured that at least one owner exists (which is [email protected]).

Regarding the third point about the ENCRYPTION_KEY,

we would like to provide some context to explain what happened:

At the beginning, we had our own fixed ENCRYPTION_KEY

However, during a certain period, we mistakenly launched n8n without specifying the ENCRYPTION_KEY in the Docker run command.

Because of that, n8n automatically generated a random encryption key during startup.

During that time, although the system was running with a random key, we were still able to log in and operate normally because the server was never rebooted and the container stayed alive.

The real problem happened recently:

After we downgraded from the Startup Plan back to the Community Edition,

we needed to install other programs on the VPS, which required us to reboot the entire server.

After the reboot, the Docker container restarted without the original random encryption key (since it was only stored in memory, not on disk), and at the same time, we were still missing the manually-set ENCRYPTION_KEY in the Docker command.

As a result, n8n started with a new random key, causing all password hashes to mismatch, and that’s when we found ourselves unable to log in anymore, even though we did not modify any n8n settings manually.

We have now corrected this by setting the original ENCRYPTION_KEY back into our Docker run command.

However, because the user passwords had already been hashed during the time when the wrong key was active, they no longer match.

Thus, we understand that we need to reset the passwords manually.

Thank you for your assistance in helping us identify this!