github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-11 10:03:05 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #17437] feat: Add SQLCipher support to official Docker image + application-level file encryption for data/ #72888

New Issue
Closed
opened 2026-05-13 05:05:06 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-13 05:05:06 -05:00
Owner
Copy Link

Originally created by @Lyhtande on GitHub (Sep 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17437

Check Existing Issues

  • I have searched the existing issues and discussions.

Problem Description

Motivation

Currently, Open WebUI stores all user data (database, uploads, cache, vector DB) in the mounted data/ directory as plain files.
Even though data/ can be protected at the host level (e.g. with gocryptfs, LUKS, or encrypted storage volumes), this is not true "application-level" encryption. Anyone with root access to the host while the system is running can still see the unencrypted files.

For environments where sensitive user data, documents, or audio files are processed, this is a significant concern. "At rest" encryption is needed beyond the database.

Requested Enhancements

  1. SQLCipher support in the official Docker image

    • The backend already supports SQLCipher when available (DATABASE_TYPE=sqlite+sqlcipher).
    • However, in the current Docker image, SQLCipher libraries are missing → starting with sqlite+sqlcipher leads to module errors.
    • Request: include SQLCipher in the official Docker image so that database encryption can be enabled via environment variables (DATABASE_TYPE, DATABASE_PASSWORD) without custom builds.

  2. Application-level file encryption for the data/ directory

    • Uploaded files, audio recordings, TTS/STT caches, and vector database contents should be encrypted by Open WebUI itself.
    • Decryption should only happen when files are actively accessed by the application.
    • This ensures that even with root access to the host, files remain unreadable without the application’s encryption key.
    • Could be implemented with a configurable master key (env var or key file), similar to WEBUI_SECRET_KEY.

Why not only rely on host encryption?

While host-level encryption (e.g., gocryptfs/LUKS) protects against storage theft or provider-level leaks, it does not protect against attackers or administrators with runtime access to the system. True security for sensitive data requires application-level encryption.

Benefits

  • Database encryption works out-of-the-box in Docker deployments.
  • Stronger protection for user-uploaded content, STT/TTS recordings, and vectorized document databases.
  • Better compliance with data protection requirements (GDPR, HIPAA, etc.).
  • Brings database and file storage in line with modern "zero trust" expectations.

Desired Solution you'd like

Request

Please consider:

  • Adding SQLCipher support to the official Docker image.
  • Providing an application-level encryption option for all files under data/.

Alternatives Considered

No response

Additional Context

No response

Originally created by @Lyhtande on GitHub (Sep 14, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/17437 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description ### Motivation Currently, Open WebUI stores all user data (database, uploads, cache, vector DB) in the mounted `data/` directory as plain files. Even though `data/` can be protected at the host level (e.g. with gocryptfs, LUKS, or encrypted storage volumes), this is not true "application-level" encryption. Anyone with root access to the host while the system is running can still see the unencrypted files. For environments where sensitive user data, documents, or audio files are processed, this is a significant concern. "At rest" encryption is needed beyond the database. ### Requested Enhancements 1. **SQLCipher support in the official Docker image** - The backend already supports SQLCipher when available (`DATABASE_TYPE=sqlite+sqlcipher`). - However, in the current Docker image, SQLCipher libraries are missing → starting with `sqlite+sqlcipher` leads to module errors. - Request: include SQLCipher in the official Docker image so that database encryption can be enabled via environment variables (`DATABASE_TYPE`, `DATABASE_PASSWORD`) without custom builds. 2. **Application-level file encryption for the `data/` directory** - Uploaded files, audio recordings, TTS/STT caches, and vector database contents should be encrypted by Open WebUI itself. - Decryption should only happen when files are actively accessed by the application. - This ensures that even with root access to the host, files remain unreadable without the application’s encryption key. - Could be implemented with a configurable master key (env var or key file), similar to `WEBUI_SECRET_KEY`. ### Why not only rely on host encryption? While host-level encryption (e.g., gocryptfs/LUKS) protects against storage theft or provider-level leaks, it does **not** protect against attackers or administrators with runtime access to the system. True security for sensitive data requires application-level encryption. ### Benefits - Database encryption works out-of-the-box in Docker deployments. - Stronger protection for user-uploaded content, STT/TTS recordings, and vectorized document databases. - Better compliance with data protection requirements (GDPR, HIPAA, etc.). - Brings database and file storage in line with modern "zero trust" expectations. ### Desired Solution you'd like ### Request Please consider: - Adding SQLCipher support to the official Docker image. - Providing an application-level encryption option for all files under `data/`. ### Alternatives Considered _No response_ ### Additional Context _No response_
GiteaMirror commented 2026-05-13 05:05:07 -05:00
Author
Owner
Copy Link

@traumschule commented on GitHub (Oct 19, 2025):

nice to have

<!-- gh-comment-id:3419609296 --> @traumschule commented on GitHub (Oct 19, 2025): nice to have
GiteaMirror commented 2026-05-13 05:05:08 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Oct 19, 2025):

@traumschule

https://docs.openwebui.com/getting-started/env-configuration#database_type

<!-- gh-comment-id:3419611763 --> @Classic298 commented on GitHub (Oct 19, 2025): @traumschule https://docs.openwebui.com/getting-started/env-configuration#database_type
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#72888
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?