Skip to main content

Matomo Cloud

Matomo Cloud and a self-hosted Matomo use the same code path. There is no Cloud mode, no separate driver and no feature that only works on one of them. Point MATOMO_HOST at your Cloud subdomain and everything is derived from it: the tracking endpoint, the Reporting API, the JavaScript tracker, the opt-out iframe and the no-script pixel.

MATOMO_HOST=https://your-instance.matomo.cloud
MATOMO_SITE_ID=1
MATOMO_TOKEN=your-cloud-auth-token   # Cloud UI -> Personal -> Security -> Auth tokens

Three things are worth knowing specifically on Cloud.

Set a token​

Matomo only honors the real visitor IP (cip), the exact hit time (cdt) and IP-derived geolocation when a token_auth accompanies the hit. For correct server-side attribution on Cloud, MATOMO_TOKEN is therefore effectively required. Without it, every server-side hit is attributed to your application server's IP and timed at the moment Cloud receives it.

Create a dedicated tracking token in the Cloud UI rather than reusing a personal one, so it can be rotated without disturbing anything else.

Plan limits fall on the read side​

Cloud bills by hits, and it is far more likely to throttle the Reporting API than tracking. The package is built for that shape:

  • Tracking already coalesces. In queue mode a request's hits leave as one Bulk request; in batch mode many requests' hits leave as one large Bulk request. See transmission modes.
  • Reporting is cached with date-aware TTLs — a realtime counter for a minute, a fully archived past period for an hour — so a dashboard that refreshes often does not turn into Reporting API calls at the same rate. See reporting.

Optionally serve the JavaScript from the CDN​

Cloud can serve matomo.js from its CDN. Set MATOMO_JS_HOST to load the asset from there while tracking itself continues to go to your own subdomain:

MATOMO_JS_HOST=https://cdn.matomo.cloud/your-instance.matomo.cloud

Only the script URL changes. The tracker still posts to MATOMO_HOST, so the first-party relationship a cookieless setup depends on is unaffected.

Verify Cloud end to end​

The definitive check is not reading config — it is a round trip. Both commands exercise the real instance:

php artisan matomo:test                       # sends a real hit, reports the HTTP status
php artisan matomo:report VisitsSummary.get   # confirms the Reporting API against Cloud

If the first passes and the second fails, the token lacks view access. If the first fails, the host or the site id is wrong — see troubleshooting.