The hosted release workflow gives staging and production independent deployment pointers. Use it when you want to review changes at the Answer Cloud address before publishing them to your production custom domain.
Requirements and addresses#
Confirm that the hosted site's plan includes the release workflow and custom domains. Connect and activate the production domain before promoting or deploying to production within this workflow.
| Destination | Address and behavior |
|---|---|
| Staging | The site's Answer Cloud address; staging-only updates leave production unchanged |
| Production | The site's active production custom domain |
| Both | One processed artifact published to both destinations with one upload |
These are release destinations for your hosted website. They are separate from Answer Cloud's own application-server environments. Companion CMS sites support production publishing only.
Enable the workflow#
Ask your authenticated agent to inspect list_sites, then call:
{"organization_id":42,"site_slug":"example-site","enabled":true}
Use those arguments with configure_release_workflow, replacing the example identity with your actual site. Enabling seeds staging from the available current deployment; it does not build new website source.
Inspect the returned site configuration and confirm the staging URL, production URL, and domain activation state. Keep the environment explicit on later deployment requests rather than rely on an assumed default.
Publish and review staging#
Deploy the complete artifact with environment: "staging", finalize it, and poll to live. Open the returned staging URL and verify content, links, layout, images, generated discovery resources, and an actual chat answer.
Record the reviewed deployment ID or sequence. Check production as well to confirm it is still serving the intended earlier release.
Widget settings are shared site configuration. If a new theme stylesheet exists only on staging, avoid changing the shared widget configuration to that staging-only file. Publish assets at the intended stable host before applying a shared theme change.
Promote the reviewed deployment#
Call promote_deploy with the site and the reviewed deploy_id or to_sequence. If neither is supplied, the current staged deployment is selected. Explicitly naming the reviewed version helps avoid promoting a newer staging change accidentally.
Promotion uses the processed deployment rather than rebuilding source. It requires a live, ready deployment and an active production domain. Open the returned production URL and verify the actual content and discovery origin after promotion.
Change or recover the workflow#
A direct both release publishes one artifact to staging and production together. Use it when that combined publication is intended, rather than as a review step.
Rollback targets staging or production separately. Disabling the release workflow returns the site to a shared live configuration based on its current production deployment, or staging if no production deployment is available. Review the current pointers before changing that setting.