Discloud container persistence vs Discord bot state: verifying recovered application data after host-level restarts

Integration boundary

The boundary sits between Discloud's container orchestration layer and the Discord bot process that writes local state — SQLite databases, JSON configuration files, or cached assets — to the container filesystem. Discloud injects the Discord token via environment variables and manages redeploys, but public documentation does not confirm whether a host-level restart or container migration preserves files written outside a declared persistent volume.

Goal and uncertainty

A bot operator needs to know whether application data survives an unplanned container replacement and, if it does, how to verify that the restored dataset matches the pre-failure state bit-for-bit. The dashboard exposes runtime logs and environment variables but no checksum, manifest, or point-in-time snapshot API for the app directory.

Open questions

• Does Discloud automatically snapshot or replicate the container's writable layer during host maintenance, or is local filesystem data ephemeral by default?
• If data is restored, what mechanism lets a developer confirm integrity of recovered SQLite or JSON files against a known good baseline?
• Are there plan-tier differences that affect persistence guarantees or verification tooling?