Where the Outpost stores data
Every folder the Outpost creates on the machine, what is in it, and which of them hold content from your documents.
The System tab shows two paths — the configuration file and the data folder. This page is the complete list behind them: for an uninstall that leaves nothing behind, and for the questionnaire that asks where document content sits on this machine.
The folder is still called "Vault"
The application is called Outpost, the directory is called meinGPT Vault.
That is deliberate: the folder name is an identifier, not a display name — if
it were renamed, every existing install would lose its state.
The data folder
One folder per user account, created by the account the Outpost runs as:
| System | Path |
|---|---|
| Windows | %LOCALAPPDATA%\meinGPT Vault — without that variable, %USERPROFILE%\AppData\Local\meinGPT Vault |
| macOS | ~/Library/Application Support/meinGPT Vault |
| Linux | $XDG_DATA_HOME/meingpt-vault — without that variable, ~/.local/share/meingpt-vault |
Everything the Outpost keeps permanently lives under it:
| Entry | What is in it |
|---|---|
desktop_state.json | The authoritative state: pairing, sources, services, settings — including the vault secret and the credentials of your services. |
app_config.yaml | The configuration derived from it, which the vault server reads. It carries the same secrets a second time: vault secret, database connection URLs, the API key of a custom embedding endpoint. |
data/ | The vault server's data directory. It holds one directory per data source, data/<data-source-id>, and the staging area: copies of the synced files while they wait between sync and indexing. |
data/.vault-tmp/ | Temporary files from format conversion and text extraction. See below. |
metadata/metadata.sqlite3 | The metadata database: documents with name and path, sync runs, job and error logs. Alongside it, -wal and -shm. |
metadata/lancedb/ | The search index. Besides the vectors it holds the extracted text of your documents (page_text_content, search_text). |
metadata/metadata.sqlite3.vault-recovery.json | A note that the database was recovered automatically. |
logs/ | vault-api.log, vault-ingest.log, bridge-agent.log, main-process.jsonl, vault.log, uvicorn.log; older rotations end in .1. Unfiltered — file names and paths from your sources appear in them. |
logs/crash-dumps/ | Crash reports of the application process. They are not uploaded anywhere. |
runtime/ | Runtime files for the Bridge agent and the sidecars, including tokens in clear text. |
diagnostics/ | The exported diagnostics bundles, vault-diagnostics-<trigger>-<timestamp>.zip. They are never deleted automatically. |
update-rollback/ | The rollback slot of the last update. See below. |
update_state.json | State of the automatic update. |
The second folder you do not expect
The Outpost creates two per-user directories. The one above is its own. The second belongs to the application platform the window runs on: it creates its own profile directory, and the Outpost does not move it.
It therefore carries a different name — the technical package name, not the product name:
| System | Path |
|---|---|
| Windows | %APPDATA%\@meingpt\vault-desktop |
| macOS | ~/Library/Application Support/@meingpt/vault-desktop |
| Linux | ~/.config/@meingpt/vault-desktop |
It holds the browser state of the application window — Cache, Code Cache, GPUCache, Local Storage, Session Storage, Preferences, Network Persistent State. No documents, no index, no credentials for your sources. Anyone who wants a clean machine after an uninstall still has to know about it: otherwise it stays behind.
When cleaning up, take both folders
meinGPT Vault and @meingpt sit under the same parent directory, but
not next to each other in an alphabetical listing. If you search only for
"meinGPT", you miss the second one.
The SharePoint token store
When you connect a SharePoint source, the Outpost creates an OAuth token store — inside the data folder, next to everything else:
<data folder>/.sharepoint-tokens/<data-source-id>/token_cache.binThe file holds OAuth tokens for your tenant and deserves the same care as a password, so it is created readable only by your user. If you remove the data source on the Data tab, the directory goes with it.
Note
On older installations this store lived in the home directory, at
~/.datavault/sharepoint_cache/. That was the wrong place: it sat outside
everything that protects the data folder, and refresh tokens stay valid long
after a pairing is revoked. The Outpost clears the old location itself on the
next SharePoint sync. Nothing is lost — the store is a shortcut that rebuilds
itself from your configuration.
One place outside both folders
The update cache. The downloaded installer for a pending update does not land in the data folder but in the user's cache directory — Windows %LOCALAPPDATA%, macOS ~/Library/Caches, Linux ~/.cache. The subfolder is named by updaterCacheDirName in the shipped app-update.yml in the installation directory. It contains only our signed installer files, nothing from your sources.
The copy an update leaves behind
Before every update the Outpost stages one rollback slot under update-rollback/, so a failed update can undo itself. It contains:
- a complete copy of the previous application,
- a copy of
metadata.sqlite3together with-waland-shm— a second copy of your metadata, - the state of the operation.
Only one slot is ever kept: the previous one is deleted once the new one is completely written. Plan for the space anyway — application plus database, once more.
The temporary files of conversion
On a customer machine the Outpost deliberately redirects every library's temporary files onto the data volume instead of leaving them on the system disk: one disk, one threshold, one measurement. They therefore land in data/.vault-tmp/.
Content from your documents passes through this directory — intermediate results of format conversion and text extraction.
Cleanup happens at startup, not continuously
The Outpost deletes every entry in .vault-tmp older than 24 hours when the
vault server starts. No service does this in between: if the machine runs
for weeks without a restart, nothing is cleaned up in that time. On a server
that runs unattended, this is the folder to keep an eye on.
Where content from your documents lives
The short answer for a security questionnaire — three places, all under the data folder:
metadata/lancedb/— the extracted text, permanently. That is the index itself.data/— copies of the synced files while they wait to be indexed.data/.vault-tmp/— conversion intermediates, until the cleanup at the next start.
File names and paths — not the content — additionally appear in metadata/metadata.sqlite3 and in the logs.
Your original files stay where they were. The Outpost moves nothing.
Removing it completely
Uninstall the application, then delete by hand:
- the data folder (
meinGPT Vault, ormeingpt-vault) — the SharePoint token store is inside it, - the platform profile directory (
@meingpt), - the update cache,
- on installations that have not synced SharePoint since the move:
~/.datavault/sharepoint_cache.
Unpair in meinGPT first — otherwise an access grant stays behind that nobody operates any more. Unpairing now also removes the tokens in runtime/; they used to be left behind and stayed valid. Nothing irrecoverable is lost: the index is rebuilt by pairing and one full indexing run, and the originals are untouched. Just write down first which path belongs to which data source ID — that only exists on this machine.
What is in the diagnostics bundle
The diagnostics bundle contains file paths, file names, error messages and search queries from your operation, plus system details, the configuration, the recovery state and the last 512 KiB of each log file. What is removed are secrets — vault secret, tokens, passwords, API keys — not content: document files and document content are not collected, but a document's name and path, and the text somebody searched for, are in there.
That is deliberate: without paths and error messages a support case cannot be resolved. It also means you should treat the ZIP like a log excerpt — look inside and review it under your own policy before you send it.