Cloudways Integration

OpenClaw Cloudways integration reference and workflow guide. Use when creating, editing, reviewing, debugging, or extending the built-in Cloudways feature; w...

Security Scan

This is a documentation/integration reference for a Cloudways feature and its files and behavior are internally coherent with that purpose, but the docs reference local secret paths and runtime tools that you should verify before use.

Purpose & Capability

The skill is an integration reference for Cloudways and the files describe exactly that (account auth, inventory, vault-backed secrets, guarded DB queries, UI controllers). That purpose matches the included docs and examples. One mismatch: the runtime docs reference runtime tooling (Playwright Chromium for DB automation, Python+Paramiko for SSH) and local vault/config files, but the skill metadata declares no required binaries or env vars — this is plausible for an instruction-only skill but worth noting.

Instruction Scope

SKILL.md and the references explicitly name local config and secret paths (e.g., ~/.openclaw/secrets.json, ~/.openclaw/workspace/config/cloudways.json, DB audit log path) and tell maintainers to read implementation files at absolute paths. While the docs also warn not to include live secrets, these instructions reference filesystem locations and behaviors that could cause an agent or developer to access sensitive local state. The skill does not itself contain code, but the instructions expect interacting with secrets, network endpoints, and running tools to test SSH/DB — these are high-sensitivity operations and the docs should be treated carefully.

Install Mechanism

Instruction-only skill with no install spec or downloads; lowest install risk. No external install sources or archived code are included.

Credentials

The skill declares no required environment variables or primary credential. The documentation describes vault-backed keys (CLOUDWAYS_EMAIL, CLOUDWAYS_API_KEY) and references storing credentials in a local secrets file; this is appropriate for the integration but the skill itself doesn't request credentials. If you deploy the actual implementation, it will legitimately need Cloudways credentials and vault access — verify that only those service credentials (and not unrelated credentials) are provided and that vault/storage permissions are scoped.

Persistence & Privilege

Skill is not always:true and does not request persistent installation or modifications to other skills. It documents local audit log and vault file paths but does not itself claim forced presence or elevated platform privileges.

Assessment

This skill is a developer-facing integration guide (no executable code included) and is coherent with its described purpose. Before installing or using it: 1) Treat the referenced filesystem paths as sensitive — do not upload/package ~/.openclaw/secrets.json or live cloudways config. 2) Review the actual implementation files the docs point to (src/gateway/... and ui/...) in your repo to ensure they do not leak secrets or call unexpected endpoints. 3) Note the docs expect Playwright (Chromium) for DB automation and Python+Paramiko for SSH testing — ensure those tools are intentionally installed and sandboxed. 4) When enabling DB write functionality in actual code, verify the confirmation and audit-log behavior and that write-query parsing is robust. 5) If you need to provide Cloudways credentials, give only the Cloudways account API key/email and restrict vault access; do not provide unrelated credentials. If you want higher assurance, ask for the implementation code to be reviewed (the referenced gateway and UI files) before enabling any runtime tests that touch secrets or network resources.

Use this skill when working on OpenClaw's built-in Cloudways integration.

What this system does

The Cloudways integration adds a Control UI workflow and gateway methods for:

• storing Cloudways account auth in the vault
• loading server and application inventory from the Cloudways API
• storing server-level master SSH/SFTP credentials
• storing app-level SSH, WordPress admin, and DB access secrets
• deriving WordPress review metadata for local code review/edit flows
• testing SSH access and DB Manager access
• running guarded read-only SQL queries
• running tightly constrained write SQL with confirmation + audit logging

Core workflow

1. Read references/implementation.md first.
2. If UI work is involved, also read references/ui-design.md.
3. If API behavior matters, read references/cloudways-api-notes.md.
4. If you need payload shapes or examples, read references/request-methods.md and assets/examples/.
5. When changing behavior, keep gateway handlers, controller state, and the UI in sync.

Source of truth files

Read these files in the OpenClaw repo when making code changes:

• src/gateway/server-methods/cloudways.ts
• ui/src/ui/controllers/cloudways.ts
• ui/src/ui/views/cloudways.ts

Important behaviors

• Account auth is validated before storage.
• Cloudways account email + API key are stored in the vault, not plain config.
• App and server secrets are stored in the vault under generated key prefixes.
• Inventory is read from Cloudways API responses, with applications flattened from server inventory.
• WordPress admin passwords should be treated as manual secure inputs, not assumed retrievable from Cloudways inventory.
• DB Manager read queries are limited to read-only statements.
• Write queries require an exact confirmation phrase and are audit logged locally.
• SQL shape is intentionally restricted to single statements; DDL and multi-statement SQL are blocked.

Security requirements

When packaging or documenting this system:

• Do not include ~/.openclaw/secrets.json
• Do not include workspace/config/cloudways.json from a live setup
• Do not include any live email addresses, API keys, DB manager URLs, SSH keys, passwords, DB hosts, app ids, or server ids from local memory/config
• Use placeholders in examples
• Keep examples obviously fake

Debugging checklist

• Does cloudways.status reflect configured/unconfigured state correctly?
• Does cloudways.save validate credentials before storing them?
• Does cloudways.inventory flatten apps from server inventory correctly?
• Do server-level credentials load/save independently from app-level credentials?
• Does app metadata correctly inherit server credentials when app SSH fields are blank?
• Does DB access test succeed only when DB Manager launcher URL + credentials are valid?
• Do read queries reject write statements?
• Do write queries require exact confirmation text and produce audit log entries?

References in this skill

• references/implementation.md — architecture and code map
• references/request-methods.md — gateway request methods and behaviors
• references/cloudways-api-notes.md — Cloudways API usage notes for this integration
• references/ui-design.md — Control UI layout and UX notes
• assets/examples/cloudways-status-response.json
• assets/examples/cloudways-metadata-response.json
• assets/examples/cloudways-read-query-response.json