Book a demo
Book a demo
Login

App workflow Docker workloads + n8n + Nextcloud + Umami

Install dashboard-only one-click app templates

Choose the xCloud dashboard path for one-click templates whose installation is not exposed by the documented public MCP capability map. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

An operator sees an app in the xCloud one-click catalog and assumes an AI agent can install it. They need a safe dashboard procedure for a template excluded from MCP install.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Name one target template

Where
xCloud One-Click Apps catalog and capability map
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Chosen app, template version, team ID
Action
Select the exact template and read its current requirements. Check the connected MCP profile rather than inferring install permission from catalog discovery.
Expected result
A named dashboard-only app and documented stack.
Verify
Compare app name and version with the current create form.
If it fails
If the template is absent, do not substitute a similarly named image without review.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 2 of 5

Prepare a Docker server

Where
xCloud Servers and app documentation
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Docker + NGINX server, CPU/RAM/storage, domain
Action
Check server compatibility and resource headroom. Identify required persistent data, initial secrets and external providers before creating the site.
Expected result
An approved hosting target.
Verify
Compare template minimums with actual server and free disk.
If it fails
If capacity is insufficient, select a different resource before install.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Step 3 of 5

Install in the dashboard

Where
xCloud Add site → One-Click Apps
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Selected template, server, site title, domain
Action
Complete the displayed app form in the dashboard and wait for deployment to finish. Store generated credentials securely.
Expected result
A running application site with a recorded site ID.
Verify
Inspect install status and open its HTTPS URL.
If it fails
If creation fails, inspect phase and logs; never try a generic MCP install based only on catalog presence.

Sources: xCloud One Click Apps catalog · xCloud agent capability boundaries

Step 4 of 5

Complete app first run

Where
Application administrator interface
Permissions
Authorized Docker application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Admin identity, safe test data, app-specific requirements
Action
Configure the app's first administrator, access rules, integrations or model/database connections as its upstream guide requires. Use harmless sample data.
Expected result
A usable app-level task, not just a login screen.
Verify
Perform one representative app action and inspect its output.
If it fails
If app setup is incomplete, label the service as installed but not ready.

Sources: xCloud One Click Apps catalog

Step 5 of 5

Protect and hand over

Where
xCloud Docker Backup and app runbook
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Volumes, external data, backup destination, owner
Action
Confirm persistent paths and external data scope, create or schedule backups, and document who updates the app and tests restores.
Expected result
A maintenance owner and recovery path.
Verify
Check a Completed backup and plan a safe restore rehearsal.
If it fails
If backup coverage is uncertain, keep production data out until verified.

Sources: Back up and restore Docker apps · Docker backup operations and storage constraints

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

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

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized Docker administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases