Vaultwarden silently falls back to SQLite if DATABASE_URL is invalid #5030

New Issue

GiteaMirror · 2026-03-07T20:10:21-06:00

GiteaMirror commented

2026-03-07 20:10:21 -06:00

Originally created by @netthier on GitHub (Oct 17, 2022).

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).   ### 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.

GiteaMirror added the enhancement bug labels 2026-03-07 20:10:21 -06:00

GiteaMirror closed this issue

2026-03-07 20:10:21 -06:00

GiteaMirror commented

2026-03-07 20:10:22 -06:00

@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.

GiteaMirror commented

2026-03-07 20:10:22 -06:00

@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.

GiteaMirror commented

2026-03-07 20:10:22 -06:00

@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.

GiteaMirror commented

2026-03-07 20:10:22 -06:00

@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.

GiteaMirror commented

2026-03-07 20:10:23 -06:00

@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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#5030