Persistence & Storage

Data that must survive container recreation, and where Vyline stores it.

Two persistence boundaries

/app/data
├─ accounts.json
├─ accounts/<account>/chatdb.sqlite
├─ accounts/<mid>/settings.json
├─ backups/
├─ logs/
├─ plugins/
└─ application state such as tokens/sessions

/app/storage
├─ cache/cdn-cache/
├─ cache/icons/
├─ saved-media/
└─ media-index.sqlite

The standard Compose file bind-mounts host ./data and ./storage to these paths. The container itself can be removed and recreated, but deleting either host directory removes persistent state.

Bind mount ownership

Even if /app/data is owned by the Bun user inside the image, a host bind mount replaces it with the host filesystem's ownership and permissions. The entrypoint starts as root only long enough to correct ownership, verifies write access, then drops to an unprivileged user.

Restore appears to work, then disappears

restore -> history exists in memory
        -> database write fails
        -> UI looks correct temporarily
        -> reload/restart
        -> history disappears

For this symptom, check the bind mount and write permissions before focusing only on Protocol decryption. Current chat history is persisted in per-account SQLite databases, so seeing history in the UI does not by itself prove that persistence succeeded.

docker inspect vyline
docker logs vyline
du -sh data storage

Storage display

Backend scans data and storage to calculate usage, while available capacity comes from statfs on the filesystem containing the configured storage location. Cache, saved media, and backups are counted separately. If you move the host storage path, the filesystem actually mounted there becomes the basis for the displayed capacity.