Skip to main content
Ungathered Thoughts

Disabling data reporting in Lando

I looked today for instructions on disabling data reporting in Lando, and thought to capture some notes on doing so.

Here's what worked for me:

Disabling usage reporting

Usage reporting is enabled by default, and lets the Lando team know how you're using Lando. At various Lando events, a report "ping" is sent to metrics.lando.dev. Here's an example of data reported, as shown by running lando restart -vvv:

example reporting stop action to url=https://metrics.lando.dev, report=true +31ms
example reporting data command=lando restart, context=local, devMode=false,
instance=abcdef, nodeVersion=v18.19.1, mode=cli,
type=Linux, platform=linux, landoPlatform=linux,
release=6.8.0-71-generic, arch=x64, isWsl=false,
isWslInterop=false, product=lando, version=3.23.26,
app=0123abc, type=drupal7,
services=[
api=3, type=drupal-php, version=7.4,
api=3, type=mariadb, version=10.3,
api=3, type=compose, version=custom,
api=3, type=mailhog, version=v1.0.0
],
action=stop, created=2025-08-20T10:26:55.784Z +1ms

To disable it, add the following to your ~/.lando/config.yml file, as documented in https://docs.lando.dev/data.html

stats:
- report: false
url: https://metrics.lando.dev

You might read that yaml and think url might be redundant. It's not - and the reporting URL changed at some point in the past, so you might even have a different URL (https://metrics.devwithlando.io) disabled in your configuration, and be surprised to find that Lando has resumed reporting to its new URL.

I think it would be an improvement to permit a clearer global disable there (eg stats: false), to avoid a future change to the default reporting URL restoring stats reporting without signal to the user.

Disabling crash reports

Disabling crash reporting takes a slightly different format: ~/.lando/cache/report_errors will either not exist (prompts on next run), or contain "true" or "false". To disable:

echo "false" > ~/.lando/cache/report_errors

About that data

Data is reported to Amplitude and crash information stored in BugSnaq.

While it's really helpful to developers to have access to crash data and usage metrics, it's a decision to consider. I'm wary of the level of data reported from systems - in 2025 I'm far more cautious about, say, webserver access logs than I was in 2015 or 2005. The safest option is to minimise data gathered.

I still expect to use the excellent Lando toolkit, and to report detailed bug information manually.