starred/vaultwarden

Fork 0

mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-04-26 01:35:54 +03:00

[GH-ISSUE #2835] Vaultwarden silently falls back to SQLite if DATABASE_URL is invalid #1391

New issue

Closed

opened 2026-03-03 02:08:47 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 02:08:47 +03:00

Owner

Originally created by @netthier on GitHub (Oct 17, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2835

Subject of the issue

When an invalid DATABASE_URL is specified, e.g. with a typo such as postgreql://user:pwd@host or with quotes like "postgresql://user:pwd@host", Vaultwarden silently falls back to using the SQLite database without logging any errors or warnings.

Deployment environment

Used image is vaultwarden/server:1.26.0

Steps to reproduce

I started vaultwarden via a docker-compose file with the DATABASE_URL variable set

Expected behaviour

If an invalid DATABASE_URL is specified, Vaultwarden should either log an error or a warning along the lines of "Failed to parse DATABASE_URL, falling back to SQLite"

Actual behaviour

Vaultwarden starts regularly and runs migrations against an SQLite database.

Originally created by @netthier on GitHub (Oct 17, 2022). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2835   ### Subject of the issue  When an invalid `DATABASE_URL` is specified, e.g. with a typo such as `postgreql://user:pwd@host` or with quotes like `"postgresql://user:pwd@host"`, Vaultwarden silently falls back to using the SQLite database without logging any errors or warnings. ### Deployment environment Used image is `vaultwarden/server:1.26.0` ### Steps to reproduce  I started vaultwarden via a docker-compose file with the `DATABASE_URL` variable set ### Expected behaviour  If an invalid `DATABASE_URL` is specified, Vaultwarden should either log an error or a warning along the lines of "Failed to parse DATABASE_URL, falling back to SQLite" ### Actual behaviour  Vaultwarden starts regularly and runs migrations against an SQLite database.

kerem

2026-03-03 02:08:47 +03:00

closed this issue
added the
enhancement

bug
labels

kerem commented

2026-03-03 02:08:48 +03:00

Author

Owner

@tessus commented on GitHub (Oct 17, 2022):

I've noticed the same beavior and IMO it should not fall back to sqlite, but abend with an error message.

@tessus commented on GitHub (Oct 17, 2022): I've noticed the same beavior and IMO it should not fall back to sqlite, but abend with an error message.

kerem commented

2026-03-03 02:08:48 +03:00

Author

Owner

@BlackDex commented on GitHub (Oct 17, 2022):

Where did you configured this? Docker compose file? Custom export? Systemd file. And could you give an example? Without the actual password etc if course.

@BlackDex commented on GitHub (Oct 17, 2022): Where did you configured this? Docker compose file? Custom export? Systemd file. And could you give an example? Without the actual password etc if course.

kerem commented

2026-03-03 02:08:48 +03:00

Author

Owner

@netthier commented on GitHub (Oct 17, 2022):

Where did you configured this? Docker compose file? Custom export? Systemd file. And could you give an example? Without the actual password etc if course.

As mentioned in the issue, I specified this in my docker-compose file. The issue also contains examples without actual passwords.
I noticed this issue after accidentally specifying the URL like this:

environment:
  - DATABASE_URL="postgresql://user:pwd@host/vaultwarden"

Specifying it as "DATABASE_URL=postgresql://user:pwd@host/vaultwarden" instead worked.
Before opening this issue I further investigated by intentionally introducing a typo in the working variant, and removing a letter from the protocol, ending up with postgreql://etc, which led to the same issue.

@netthier commented on GitHub (Oct 17, 2022): > Where did you configured this? Docker compose file? Custom export? Systemd file. And could you give an example? Without the actual password etc if course. As mentioned in the issue, I specified this in my docker-compose file. The issue also contains examples without actual passwords. I noticed this issue after accidentally specifying the URL like this: ```yaml environment: - DATABASE_URL="postgresql://user:pwd@host/vaultwarden" ``` Specifying it as `"DATABASE_URL=postgresql://user:pwd@host/vaultwarden"` instead worked. Before opening this issue I further investigated by intentionally introducing a typo in the working variant, and removing a letter from the protocol, ending up with `postgreql://etc`, which led to the same issue.

kerem commented

2026-03-03 02:08:48 +03:00

Author

Owner

@BlackDex commented on GitHub (Oct 17, 2022):

Thanks for the extra info.
The thing is that the quotes are an issue with compose, but not with export or a .env loaded by Vaultwarden it self.

But, it indeed should not continue if there is a faulty setting.
The only setting which could be seen as faulty but still should fall back is an empty string, since that indicates a default.

Thanks for the report.

@BlackDex commented on GitHub (Oct 17, 2022): Thanks for the extra info. The thing is that the quotes are an issue with compose, but not with export or a .env loaded by Vaultwarden it self. But, it indeed should not continue if there is a faulty setting. The only setting which could be seen as faulty but still should fall back is an empty string, since that indicates a default. Thanks for the report.

kerem commented

2026-03-03 02:08:48 +03:00

Author

Owner

@BlackDex commented on GitHub (Dec 8, 2022):

Should be resolved via #2873 already.

@BlackDex commented on GitHub (Dec 8, 2022): Should be resolved via #2873 already.