Requirements and responsibilities
Record the current provider, a harmless known-answer prompt and a credential controlled by the new provider owner. Check the current xCloud Providers list instead of assuming every upstream OpenClaw provider is hosted.
How to Deploy OpenClaw with xCloud · Managed OpenClaw Hosting
Keep the old provider credential valid until the new answer and a rollback check are complete.
How to Deploy OpenClaw with xCloud · Managed OpenClaw Hosting
Illustrative situation
Illustrative scenario: an owner changes the assistant’s model provider after a billing or reliability decision and needs proof that the new provider answers.
Choose the approach
Use xCloud OpenClaw → Providers → Change Provider, which the deployment guide documents. A provider switch changes model access but does not grant new tools or sender permissions.
How to Deploy OpenClaw with xCloud · Managed OpenClaw Hosting
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Capture the current answer
- Where
- Approved private conversation and xCloud Providers
- Permissions
- Authorized OpenClaw owner or application administrator
- Inputs
- Current provider and known-answer prompt
- Action
- Run a short prompt whose correct answer is independently known, then record response and time without storing secrets.
- Expected result
- A comparison baseline exists.
- Verify
- Confirm provider identity in the dashboard and answer correctness.
- If it fails
- If the baseline already fails, investigate current service health before changing providers.
Sources: How to Deploy OpenClaw with xCloud
Step 2 of 5
Check the offered destination
- Where
- xCloud Providers → Change Provider
- Permissions
- Authorized OpenClaw owner or application administrator
- Inputs
- Proposed provider, model and account owner
- Action
- Inspect the provider options available in this deployment and confirm the chosen credential has the intended account scope and billing owner.
- Expected result
- The intended provider is selectable and owned.
- Verify
- Compare displayed provider name with the change ticket.
- If it fails
- If the provider is absent, stop; upstream support does not prove the xCloud form offers it.
Sources: How to Deploy OpenClaw with xCloud · Managed OpenClaw Hosting
Step 3 of 5
Change the default provider
- Where
- xCloud Providers
- Permissions
- Authorized OpenClaw owner or application administrator
- Inputs
- Dedicated API key or documented token option
- Action
- Enter the credential in the provider form and Save Changes once. Do not put the key in a chat prompt, log or runbook.
- Expected result
- The dashboard accepts the new default.
- Verify
- Reopen Providers and confirm the selected provider; check status for a configuration error.
- If it fails
- If Save fails, leave the old provider in place and resolve token format or provider account access.
Sources: How to Deploy OpenClaw with xCloud
Step 4 of 5
Run the same answer check
- Where
- Private OpenClaw conversation
- Permissions
- Authorized OpenClaw owner or application administrator
- Inputs
- Original known-answer prompt
- Action
- Send the identical prompt and compare factual answer, latency and any provider error with baseline.
- Expected result
- The new provider returns the correct answer through the existing private channel.
- Verify
- Check the answer and dashboard logs for authentication or quota errors.
- If it fails
- If the new run fails, revert to the recorded prior provider and repeat the baseline check.
Sources: How to Deploy OpenClaw with xCloud
Step 5 of 5
Close the credential handoff
- Where
- Provider account and operations record
- Permissions
- Authorized OpenClaw owner or application administrator
- Inputs
- New provider owner, old key disposition and check outcome
- Action
- Record the observed cutover, owner and rollback result. Retire the old credential only after the new path is stable and no other authorized consumer needs it.
- Expected result
- The provider change is reproducible and secrets remain out of notes.
- Verify
- Have the owner locate the provider selection and confirm the old key disposition.
- If it fails
- If ownership or billing is unclear, restore the previous known-good setting and keep the change open.
Sources: How to Deploy OpenClaw with xCloud · OpenClaw security and access control
Maintenance
After the provider switch, repeat the exact known-answer prompt and compare correctness, response time and authentication errors with baseline.
Recovery decisions
If the new provider fails, use Providers → Change Provider to restore the saved prior provider and its valid credential, then repeat the baseline prompt. Keep the failed key out of logs.
AI handoff
Use the named xCloud dashboard for hosted controls and verify application tools in the deployed OpenClaw version before use. An xCloud hosting MCP write operation for these actions is not documented.
Supported scope
- Configure an OpenClaw application behavior app · manual
Upstream OpenClaw documentation describes application features. xCloud does not document every app configuration surface or pre-enabled tool. Verify the feature and permissions in the deployed build before editing.
Checkpoint: Use a harmless positive and negative test; preserve current configuration and stop if the feature is unavailable.
How to Deploy OpenClaw with xCloud · OpenClaw security and access control
- Inspect and manage the hosted OpenClaw service dashboard · manual
Use only controls visible for this managed OpenClaw server. Creation, provider, channel, UI, updates and logs are separate xCloud dashboard actions; no OpenClaw hosting MCP write operation is documented.
Checkpoint: Confirm the exact server, selected control and effect before changing it; inspect resulting status and a bounded chat.
Copyable agent brief
Manual checkpoints
- The provider owner enters the dedicated credential in xCloud Providers.
- The operator compares old and new prompt results and checks provider errors before retiring the old key.
Feature coverage
- task setup and decision (covered): Defines prerequisites and an explicit hosted/application handoff. Capture the current answer Check the offered destination
- task acceptance and failure (covered): The new hosted provider answers the same known-answer prompt correctly without changing channel or tool permissions. Failure: Unavailable provider, failed authentication, wrong answer or unclear ownership means the cutover is unaccepted. Change the default provider Run the same answer check Close the credential handoff