GitHub auto-deploy vs CLI upload for gated Discloud bot releases

Direct answer

Discloud’s GitHub integration is a push-to-deploy connection, not a promotion pipeline. If the dashboard offers branch selection, it only decides which pushes deploy; it does not create a staging or preview gate. CLI upload is the manual deployment path, but it is not a documented approval engine—Discloud activates whatever artifact you upload. Environment variables are app-scoped dashboard settings that persist across code versions and apply to whatever version is active.

What branch selection can and cannot do

Connecting an app to a development branch keeps production untouched only while that app remains connected to the dev branch. It does not provide environment separation, required reviewers, or preview URLs. The likely source of confusion is that branch selection feels like environment separation, but the model is one connected source to one active app version. If you need a production gate, either connect the app to a protected production branch and enforce approval through your Git workflow, or leave production unconnected and deploy only approved artifacts via CLI or the dashboard after sign-off.

Enforcing a manual approval step

The CLI upload requires local packaging and explicit action, which makes it the natural place for a human gate. However, the approval must live in your process or CI: Discloud does not hold an uploaded version in a pending state. A repeatable pattern is to build a reproducible artifact, tag it with the release commit, obtain sign-off, then upload that exact artifact and record the tag in your runbook.

Environment variables and code versions

Dashboard environment variables are not versioned with code. They persist across uploads and immediately affect the active bot. Treat them as release inputs: snapshot the expected keys and values alongside the release tag, validate them before upload, and recheck them after deploy or restart. A rollback to older code can therefore run with newer configuration unless you explicitly restore the previous values.

Comparison for gated releases

Aspect	GitHub auto-deploy	CLI upload
Trigger	Push to the connected branch	Explicit command after approval
Built-in approval	None; use protected branches/PR review	None; gate before the upload command
Rollback	Revert the branch and push again	Re-upload the previous artifact
Env var behavior	App-scoped dashboard values persist	Same app-scoped values persist

Verification before finalizing the runbook

• Open the app’s Discloud dashboard integration page and confirm whether a branch selector exists, which events trigger deploys, and whether any staging or preview option is documented.
• Run the installed Discloud CLI help and version commands to confirm the exact upload syntax and flags for your version, then test with a disposable app.
• In a test app, push to the connected branch, then upload via CLI, and observe whether the active version or commit identifier changes and whether environment variables persist.
• Change one environment variable in the dashboard, restart or redeploy, and check whether the value survives a subsequent code upload.

One detail that would change this recommendation

If the current Discloud dashboard exposes a staging/preview environment or a deployment history with one-click rollback, the CLI-only gate becomes unnecessary. Confirm that setting before locking in the process.