Discloud CLI and discloud.config: Versioning and State Recovery

Question

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?

Zoha · Answer

Direct answer

For standard Discloud bot hosting, assume there is no native snapshot or hidden version-tag metadata in discloud.config. A failed deploy overwrites the runtime environment, so recovery is an external redeploy of the last known-good build and configuration from version control or an artifact store.

What is confirmed vs. likely

The question states that standard Discloud hosting uses an ephemeral file system and overwrites the runtime on deploy. Treat that as the operating constraint. Likely but unverified: undocumented discloud.config fields are ignored or rejected rather than silently used as release tags. Do not depend on them.

Safe recovery path

Tag every deployable state in Git. Keep the exact discloud.config that produced the last stable build under the same tag.
Pin the Discloud CLI version in CI so rollback scripts do not break after an upgrade.
For breaking changes, deploy to a separate app ID first. Keep the old app stopped but intact until the candidate passes health checks. Do not delete the old app until the replacement is proven.
Make boot-time migrations backward-compatible and idempotent. Avoid destructive schema changes during startup; use expand/contract across releases.
Persist state outside the ephemeral filesystem and back it up. A code rollback does not restore data.

Recovery steps after a failed upgrade

Capture the current app status and logs before redeploying. The overwritten container may not be recoverable from Discloud itself.
Check out the previous Git tag containing both the application code and the matching discloud.config.
Redeploy using the pinned CLI. If the app uses a Discloud-managed database or backup, sequence the data restore before or with the code rollback.
Run smoke tests against the restored app before resuming traffic.

Verification

Because CLI command names and config schema are version-sensitive, verify the exact syntax in a disposable app before relying on it:

discloud --version
discloud app status <app-id>
discloud app logs <app-id>

Rehearse the full rollback in staging: checkout the previous tag, redeploy, restore external data if needed, and confirm health checks pass. Repeat the rehearsal after every CLI or platform change.

One missing detail

Does the application use a Discloud-managed database or backup service? If yes, the runbook must sequence data restoration with the code rollback; if no, external state management is the only recovery lever.