Book a demo
Book a demo
Login

Operations Umami + Docker workloads

Operate a self-hosted analytics service

Review access, data retention, update path, privacy decisions, and backup recovery. 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

A self-hosted analytics dashboard suddenly shows fewer WordPress visits. The operator must distinguish tracker, filters, consent and app/database faults before changing reports.

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

Identify selected service

Where
xCloud site and analytics admin
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Umami or Matomo, property ID, app version
Action
Confirm actual deployed app, property and WordPress hostname. Note report time zone and last normal date.
Expected result
A specific measurement path.
Verify
Check tracker/property ID against public site source.
If it fails
If tracking points to staging, correct the property before interpreting trends.

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

Step 2 of 5

Trace a controlled event

Where
WordPress browser network and analytics UI
Permissions
Authorized Analytics application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Test page, consent state, known event
Action
Visit a public page and trigger a harmless event. Inspect browser request and whether the app recorded it.
Expected result
A direct signal from visitor to report.
Verify
Compare request time and report count with filters off/on.
If it fails
If no request leaves browser, inspect script, blocker and consent settings.

Sources: Umami tracking setup · Umami event tracking · Matomo tracking code for WordPress · Matomo application and data backup · Matomo report auto-archiving

Step 3 of 5

Review filters and access

Where
Analytics property settings
Permissions
Authorized Analytics application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Internal IP rules, exclusions, user roles
Action
Check whether internal-traffic filtering, consent or property permissions changed. Confirm reports are viewed at the intended date range.
Expected result
A scoped explanation for missing visits.
Verify
Repeat controlled event outside excluded traffic.
If it fails
If users can see restricted data, adjust app rights.

Sources: Umami tracking setup · Umami event tracking · Matomo tracking code for WordPress · Matomo application and data backup · Matomo report auto-archiving

Step 4 of 5

Inspect service and data

Where
xCloud Docker site and app database
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Logs, disk, DB health, background jobs
Action
Check app health, database capacity and errors without assuming a green web UI means ingestion works. For Matomo review archive job health if used.
Expected result
An infrastructure or app fault assessment.
Verify
Compare known event with ingest/log status.
If it fails
If DB is full or job stopped, repair before recalculating reports.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Umami tracking setup · Matomo report auto-archiving

Step 5 of 5

Protect history and policy

Where
xCloud Backup and analytics retention settings
Permissions
Authorized xCloud team/site operator with the discovered write scope for this exact operation and owner approval for its target and interruption.
Inputs
Database, config, retention, deletion owner
Action
Verify a Completed backup covering selected app state; for Matomo include database/config/plugins and for Umami its DB. Reconfirm privacy and retention decisions.
Expected result
A recoverable and governed analytics service.
Verify
Restore sample or document the untested recovery gap.
If it fails
If backup omits database, do not delete or rebuild the production property.

Sources: Back up and restore Docker apps · Docker backup operations and storage constraints · Umami tracking setup · Matomo application and data backup

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 Umami 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