Discloud CLI and discloud.config: Versioning and State Recovery

Managing application updates on Discloud involves modifying the discloud.config file and pushing new builds via the CLI. Because the platform utilizes an ephemeral file system for standard bot hosting, the current deployment process overwrites the existing runtime environment.

When a new deployment introduces a breaking change or a configuration error that prevents the application from booting, there is no native snapshot mechanism to revert to the previous stable build instantly. This creates a dependency on external version control to restore the last known working state.

Given these constraints, what are the best practices for implementing a safe recovery path during a failed upgrade? Specifically, does the platform support any hidden metadata for version tagging, or must state recovery be handled entirely through external storage and manual CLI re-deployments?