Privacy and safe sharing
dtxWiki keeps knowledge on the computer or server where you install it. “Local first” describes where the application stores data; you still choose how to share pages and whether to connect external services.
Decide who should see the material
Use a private workspace for work that should be limited to its members. Membership covers the whole workspace rather than one folder. An author-private MCP editing session is visible only to its author until submitted. Browser Save draft and autosave create unpublished drafts readable by workspace Editors and Owners; they are not author-private. Viewers receive the published version. Review submission and anonymous web exposure are separate actions.
There are three distinct sharing decisions:
| Action | Who gains access? |
|---|---|
| Add a member | That account receives the selected role across the workspace |
| Copy a workspace page link | Only a signed-in member with the required access can open it |
| Publish a Context version to the web | Anonymous visitors can read the separately published version |
A public page includes its References section, but an unexposed private reference is shown as unavailable without disclosing its title. Adding it to a public document does not expose the target.
An unlisted public URL still allows anyone who obtains the URL to read it. Treat it as external sharing, not a confidential invitation. A Public workspace exposes a discoverable profile; it does not automatically publish all internal pages. Review Sharing before publishing.
Some choices stay personal. Favorites you mark with Add to my favorites are shown only to you, not to other members or Owners; they are stored in the server database with your account and workspace. Settings → Labs choices, such as Show Ask menu, are saved only in your browser for your account. They are not sent to the server, and they do not change what anyone can access.
Understand AI data access
Connecting an AI app through MCP lets that app request content and permitted actions from the running dtxWiki server. It uses your account, role, chosen workspaces, and scopes. Content returned to the app may then be processed by its AI provider under that provider’s policies. Configure only the workspaces and actions the app needs.
Configuring dtxWiki’s own model provider is a separate choice. Ask, an experimental menu that each person turns on in Settings → Labs, works without it. With a provider enabled, the service sends the question and selected evidence to that provider to compose an answer. An external embedding service receives text used for semantic indexing or queries; an external reranker receives candidates to rank. These choices are off by default. See Optional AI providers.
Library ingestion of a web source can contact that source’s host. Optional account mail sends the recipient address and verification, recovery, five-minute identity-confirmation or Add account email link through the configured mail service; mail is disabled by default. Add account email also requires password login to be enabled. See Optional email delivery for the Gmail example and delivery checks. Local storage does not mean every optional workflow is disconnected from the network.
Protect access keys
An access key, also called a PAT, allows an app to act with the permissions you grant. Treat it like a password.
- Give each person and connection its own key; avoid shared credentials.
- Start with read access if the app only needs to consult knowledge.
- Select only the required workspaces; a key created in Settings → MCP access expires after 90 days. In the workspace dialog, check the Selected items view before you apply the selection.
- Copy a new key when shown once, then keep it in an approved secrets store.
- Revoke lost or exposed keys in Settings → MCP access and create a replacement. Clients that used the key then show Credential revoked under Connected MCP clients. A workspace Owner can also stop one client at once with Disable; it then shows Use blocked.
Do not paste keys, one-time reset URLs, .env files, or full client configurations into public issues, documentation screenshots, or shared chats. Some client configurations store the PAT in plain text, even if the setup helper hides it from terminal output. Restrict those files and their backups.
OAuth avoids manually placing a PAT in a configuration file, but the app still receives tokens and permissions. Read the consent screen and revoke an app you no longer use.
Files uploaded into pages
Files uploaded into a page are stored on the dtxWiki server with that workspace. In Settings → Attachments, each member sees uploads on pages they can read: Viewers and Editors see their own, and Owners also see other members' uploads. An upload held by someone else's author-private edit stays hidden; browser drafts follow the page's Editor/Owner visibility.
An upload that no page version uses is Unused. dtxWiki removes unused uploads automatically once the workspace's retention period has passed since the upload: 7 days unless the server default or the workspace setting was changed. An Owner can change the period, turn this cleanup off, or return to the server default under Unused file auto reclamation. Files used by any page version, or by an edit that is still open, are never removed this way, and Library sources are not affected. Deleting a file in Settings → Attachments is permanent; only a backup can bring it back.
Server administrators can see attachment details across the whole server. With Attachment scope set to All workspaces, they see the workspace, file name, page title, uploader and upload time for every workspace, including workspaces they are not members of, and they can delete unused files. This view shows no previews or file contents, and it does not let them open the pages or change a workspace's cleanup setting.
For the operator
Use HTTPS for remote access. Limit exposed ports and trust forwarded headers only from the actual reverse proxy. Keep signing keys and session secrets stable across ordinary restarts, and include them in protected backups. A local installation does this for you: it creates its OAuth signing key oauth-jwt.pem and its session_secret in the data directory, ~/.dtxwiki by default, and reuses them on every start. Treat both files like passwords, and keep them with the data when you back it up or move it.
The data directory, and the folder that holds the SQLite database, also contain .lock files. dtxWiki uses them to stop a second copy from using the same data at the same time. They remain after dtxWiki stops; do not delete them.
DTXWIKI_CONTEXT_MEDIA_ORPHAN_RETENTION_HOURS sets the server default for keeping unused uploads: 168 hours unless you change it. 0 turns cleanup off for workspaces that use the default. A value an Owner saves for a workspace takes precedence. Restart dtxWiki, including a separately run worker, after changing it. The provided Docker Compose file does not pass this variable, so Docker installations keep 168 hours unless you add it to the Compose configuration.
SQLite files and uploads need operating-system permissions and disk/backup protection. dtxWiki’s application access controls do not replace disk encryption or prevent a server operator with filesystem access from reading stored data. Workspaces are logically separated in a single database in this version.
Do not disable security guards to silence an error. Use Troubleshooting to resolve the configuration or certificate issue. Review Backups and maintenance before key rotation, restore, or a version change.
External identity and account deletion
External sign-in follows the installed provider plugin and IdP policy; email equality does not merge accounts. Account deletion revokes credentials immediately but retains submitted documents, review and conversation history in other workspaces. Inspect retention and sole-admin workspace impact first. Graphs and Inbox also follow the current reader's access.
Version evidence: sharing screen rules, membership and key controls, provider and storage settings, connected client states, personal favorites, Labs choices in the browser, attachment views, unused-file retention, server-wide attachment list, local signing key, lock files.