Vaultwarden fails to start after update – DB migration error (SSO)

[archos]

After updating the Vaultwarden app on Cloudron, the application never reaches the Running state and gets stuck in a start / restart loop.

The app logs show the following error:

Dec 29 18:21:11 9: vaultwarden::main
Dec 29 18:21:11 [2025-12-29 17:21:11.256][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2024-03-06-170000_add_sso_users", version: MigrationVersion("20240306170000") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'sso_users_ibfk_1' are incompatible."))': src/db/mod.rs:505
Dec 29 18:21:11 [INFO] Using saved config from `/app/data/config.json` for configuration.
Dec 29 18:21:11 [WARNING] Please use the admin panel to make changes to them:
Dec 29 18:21:11 [WARNING] SIGNUPS_ALLOWED, INVITATIONS_ALLOWED, YUBICO_CLIENT_ID, YUBICO_SECRET_KEY
Dec 29 18:21:11 [WARNING] The following environment variables are being overridden by the config.json file.
Dec 29 18:21:14 2025-12-29T18:21:14+01:00
Dec 29 18:21:14 2025-12-29T18:21:14+01:00
Dec 29 18:21:14 2025-12-29T18:21:14+01:00
Dec 29 18:21:14 2025-12-29T18:21:14+01:00
Dec 29 18:21:14 /--------------------------------------------------------------------\
Dec 29 18:21:14 0: vaultwarden::init_logging::{{closure}}
Dec 29 18:21:14 10: std::sys::backtrace::__rust_begin_short_backtrace
Dec 29 18:21:14 11: main
Dec 29 18:21:14 12: <unknown>
Dec 29 18:21:14 13: __libc_start_main
Dec 29 18:21:14 14: _start
Dec 29 18:21:14 1: std::panicking::panic_with_hook
Dec 29 18:21:14 2: std::panicking::panic_handler::{{closure}}
Dec 29 18:21:14 3: std::sys::backtrace::__rust_end_short_backtrace

It looks like the migration related to SSO fails, but I’m not sure what the correct or recommended way to handle this situation is.

Has anyone encountered this issue?
Is there a supported way to fix this without manually modifying the database?

Thanks for any pointers.

[Kubernetes]

@archos No issues on my Cloudron after updating Vaultwarden.

[robi]

Another restart could do it, but if not, it could need more memory to complete the migration, so bumping that and another restart.

[archos]

@Kubernetes said in Vaultwarden fails to start after update – DB migration error (SSO):

@archos No issues on my Cloudron after updating Vaultwarden.
Thanks for the feedback.
On our server we have two Vaultwarden apps — both were updated, but only one updated without issues. The other one fails with the migration error.

[archos]

@robi Thanks for the suggestion. I’ve tried restarting and increased the app memory — it’s now set to 4 GB, which should be sufficient. Unfortunately, it still ends with the same migration error.

[james]

Hello @archos
I think, I have the same issue.
This is the log:

[2025-12-29 19:23:43.075][panic][ERROR] thread 'main' panicked at 'Error running migrations: QueryError(DieselMigrationName { name: "2024-03-06-170000_add_sso_users", version: MigrationVersion("20240306170000") }, DatabaseError(Unknown, "Referencing column 'user_uuid' and referenced column 'uuid' in foreign key constraint 'sso_users_ibfk_1' are incompatible."))': src/db/mod.rs:505

And seems to be already reported upstream: https://github.com/dani-garcia/vaultwarden/issues/6611

---

EDIT:
I followed the guided instructions and was able to fix it => https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend#foreign-key-errors-collation-and-charset

be sure to replace "vaultwarden" in the SQL querries with your cloudron database name.

[archos]

@james Thanks for the links. The workaround looks rather complex, and I honestly don’t feel confident performing manual database changes. I’m wondering whether it would be safer to resolve this by reinstalling the app and restoring from a backup.

[james]

Hello @archos
I am unsure if that would work.
The restore from backup might also restore the old charset and thus recreating the issue.

You can always clone the app from the latest backup, tinker to your liking with zero risk.