Requirements and responsibilities
Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: A WordPress business wants online bookings managed in a separate service.
xCloud agent capability boundaries · WordPress roles and capabilities
Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.
xCloud agent capability boundaries · WordPress plugin administration
Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: An iframe or shared login can fail across cookies and domains.
Illustrative situation
Illustrative scenario, not a customer case study: A WordPress business wants online bookings managed in a separate service. A visitor completes a booking and staff can find it in the app.
Choose the approach
Start with a plain booking link unless deeper integration passes tests. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · WordPress roles and capabilities · Easy!Appointments hosting, setup and deployment requirements
Keep application setup, domain/DNS ownership, mail delivery and external integrations with their named administrators. Use a plain documented path when a proposed integration cannot be demonstrated end to end.
xCloud agent capability boundaries · WordPress plugin administration
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Define required slots, service rules and confirmation behavior
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Define required slots, service rules and confirmation behavior; exact site identity, named approver and controlled sample data.
- Action
- Write required services, provider hours, timezone, cancellation and message rules for the separate scheduler.
- Expected result
- The app choice has real booking tests.
- Verify
- The app choice has real booking tests. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If a requirement is unsupported, keep it off the public promise.
Sources: WordPress roles and capabilities · Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments hosting, setup and deployment requirements
Step 2 of 5
Request scheduler deployment
- Where
- xCloud dashboard app catalog and Easy!Appointments administrator
- Permissions
- Named xCloud team/site administrator; confirm target and scope.
- Inputs
- Choose documented booking app and deploy separately; exact site identity, named approver and controlled sample data.
- Action
- Verify Easy!Appointments is currently available in the selected xCloud dashboard catalog on the intended Docker-capable stack, then have the authorized dashboard operator deploy it at a separate hostname. If unavailable, choose another documented path; do not imply the MCP creates the app.
- Expected result
- The scheduler has its own accessible site and named operator.
- Verify
- The scheduler has its own accessible site and named operator. Record the exact account or record tested, result, and time with the responsible owner.
- If it fails
- If template is unavailable, revise the plan rather than invent an MCP install.
Sources: Easy!Appointments hosting, setup and deployment requirements · xCloud agent capability boundaries · Easy!Appointments official initial configuration · Easy!Appointments official application settings · xCloud One Click Apps catalog
Step 3 of 5
Configure availability, staff and notifications in app
- Where
- Easy!Appointments administrator
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Configure availability, staff and notifications in app; exact site identity, named approver and controlled sample data.
- Action
- In Easy!Appointments administration enter services, providers, working plan and blocked periods; configure mail with its documented settings.
- Expected result
- The app exposes the intended slots.
- Verify
- The app exposes the intended slots. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If mail setup differs from the site host, treat delivery as a separate task.
Sources: Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments hosting, setup and deployment requirements
Step 4 of 5
Link from WordPress and run mobile booking tests
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Link from wordpress and run mobile booking tests; exact site identity, named approver and controlled sample data.
- Action
- Add a plain booking link from WordPress, then book and cancel from a test visitor; inspect staff calendar and customer message.
- Expected result
- The booking journey spans website and app.
- Verify
- The booking journey spans website and app. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If an embed or single sign-on is unproven, keep the plain link.
Sources: WordPress roles and capabilities · Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments hosting, setup and deployment requirements
Step 5 of 5
Assign separate backup and outage response owners
- Where
- xCloud Docker Site Backup dashboard
- Permissions
- Named xCloud team/site administrator; confirm target and scope.
- Inputs
- Assign separate backup and outage response owners; exact site identity, named approver and controlled sample data.
- Action
- Confirm separate Docker app backup and WordPress backup, and reconcile newer bookings before any scheduler restore.
- Expected result
- Both services have recovery owners.
- Verify
- Both services have recovery owners. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If the app backup predates active appointments, preserve them before recovery.
Sources: Back up and restore Docker apps · xCloud agent capability boundaries · Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments hosting, setup and deployment requirements
Maintenance
Assign a cadence for selected WordPress core, theme and plugin updates, review version-based findings and retest the path in this guide. In particular, repeat: A visitor completes a booking and staff can find it in the app. A chat prompt is not a scheduled task.
Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud
Record actual backup completion, storage access and responsible staff. Recheck connected application and provider behavior after changes rather than relying on a site health status alone.
Recovery decisions
Easy!Appointments data lives in its own application/database. Preserve its completed backup and reconcile bookings made since the capture before restoring that service; restoring WordPress content does not rebuild the scheduler ledger.
Back up and restore Docker apps · Easy!Appointments official initial configuration
AI handoff
Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.
Supported scope
- Confirm requirements and inspect resources mcp · read
Discover the connected profile and operation schema first; only teams granted to the connection are visible.
Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.
Operation identifiers and scopes to discover
teams.index, servers.show, sites.show
Scopes: read:servers, read:sites
xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
- Review a WordPress business journey app · manual
Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence.
Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision.
- Deploy selected catalog application in xCloud dashboard dashboard · manual
Verify current catalog entry, compatible stack, domain and app prerequisites. An MCP resource read cannot establish installation support for a particular app or perform application setup.
Checkpoint: Confirm the exact dashboard app, team, server, hostname and completed first-run setup before relying on it.
xCloud One Click Apps catalog · xCloud agent capability boundaries
- Configure the booking application and run acceptance tests app · manual
xCloud hosting operations do not configure business rules, staff calendars, reminders, payments or WordPress plugins.
Checkpoint: An authorized application administrator performs configuration and confirms each customer and staff journey.
Easy!Appointments hosting, setup and deployment requirements · Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments official appointment notifications · xCloud MCP documentation and connection profiles
- Create and inspect Docker backups mcp · write
Backup capture briefly stops the app. Use supported local, S3-compatible or SFTP storage; the packaged REST wrapper is GET-only.
Checkpoint: Confirm site, storage, retention and the interruption window before creating a backup or changing settings. Check terminal completion.
Operation identifiers and scopes to discover
sites.docker.backup, sites.docker.backups, sites.docker.backupSettings.update
Scopes: read:sites, write:sites
Docker backup operations and storage constraints · Back up and restore Docker apps
Copyable agent brief
Manual checkpoints
- The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: In Easy!Appointments administration enter services, providers, working plan and blocked periods; configure mail with its documented settings.
- The business owner compares the controlled sample with this observable result: The booking journey spans website and app.
- Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage
- business-acceptance (covered): A visitor completes a booking and staff can find it in the app. Link from WordPress and run mobile booking tests
- recovery (covered): An iframe or shared login can fail across cookies and domains. Assign separate backup and outage response owners
Sources
- xCloud agent capability boundaries
- WordPress roles and capabilities
- WordPress plugin administration
- Site backups in xCloud
- WordPress hardening handbook
- xCloud MCP documentation and connection profiles
- Easy!Appointments hosting, setup and deployment requirements
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- Back up and restore Docker apps
- Easy!Appointments official initial configuration
- Easy!Appointments official application settings
- xCloud One Click Apps catalog
- Easy!Appointments official appointment notifications
- Docker backup operations and storage constraints