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

Question

Integration boundaryThe 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 uncertaintyA 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 questionsDoes 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?

Tasadduq Burney · Answer

Application state written within a standard Discloud container filesystem is ephemeral by default after host-level restarts or container migrations.
Confirmed Fact
Without explicit configuration pointing the application data directory to a Discloud-managed persistent volume, data written to the container's writable layer will not survive container replacement or host maintenance.
Verification Steps

Confirm the application directory is explicitly mounted to a Discloud persistent volume via the deployment settings.
If persistence is confirmed, before any planned maintenance, generate an external, canonical backup of the SQLite database (using the online backup API or `.backup`) and a manifest (e.g., canonical JSON hash) stored outside Discloud.
After recovery, verify application integrity by comparing the recovered manifest hash and running PRAGMA integrity_check on the SQLite database; do not rely on raw byte comparison.

Diagnostic Requirement
The critical missing detail is whether the application directory is mapped to a Discloud-documented persistent volume. If this is unknown or not explicitly configured, assume data loss and rebuild from an external source of truth.

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

Integration boundary

Goal and uncertainty

Open questions

1 answer

Application state written within a standard Discloud container filesystem is ephemeral by default after host-level restarts or container migrations.

Confirmed Fact

Verification Steps

Diagnostic Requirement

Your perspective belongs here.

0 question comments