Post

Psa Immich Machine Learning Has Microsoft Telemetry Enabled By Default Heres How To Disable It

In the world of self-hosted infrastructure and homelab enthusiasts, privacy is often the primary driver for moving away from proprietary SaaS solutions. When...

Psa Immich Machine Learning Has Microsoft Telemetry Enabled By Default Heres How To Disable It

Psa Immich Machine Learning Has Microsoft Telemetry Enabled By Default Heres How To Disable It

In the world of self-hosted infrastructure and homelab enthusiasts, privacy is often the primary driver for moving away from proprietary SaaS solutions. When we deploy tools like Immich—a high-performance, open-source photo and video management solution—we do so under the assumption that our data, our metadata, and our network traffic remain within our own controlled perimeter. However, a recent discovery has sent ripples through the self-hosting community: the Immich Machine Learning microservice, which powers facial recognition and object detection, has Microsoft telemetry enabled by default.

This isn’t a flaw in Immich’s core logic, but rather a side effect of its underlying dependencies. Immich utilizes the ONNX Runtime (Open Neural Network Exchange) to execute machine learning models efficiently across different hardware architectures. While ONNX is an industry standard developed by Microsoft, it comes with built-in telemetry designed to collect usage data. Because the official Immich Docker images do not explicitly disable this feature, your machine learning container will attempt to reach out to Microsoft’s telemetry endpoints—specifically mobile.events.data.microsoft.com—every time it performs inference tasks.

For a DevOps engineer or a privacy-conscious sysadmin, seeing thousands of blocked DNS queries in Pi-hole or AdGuard Home logs is a red flag. It indicates that a service you thought was “air-gapped” or locally contained is actually attempting to “phone home.” This guide provides a deep dive into why this happens, the implications for your infrastructure, and the precise technical steps required to disable this telemetry and reclaim your privacy.

Understanding the Topic: ONNX Runtime and the Telemetry Problem

To solve this, we must first understand the architecture of the Immich Machine Learning service and the specific component responsible for the data leakage.

What is ONNX Runtime?

The Open Neural Network Exchange (ONNX) is an open-source format designed to represent machine learning models. The ONNX Runtime is the engine that actually executes these models. It is highly optimized for various hardware, including CPUs, GPUs (NVIDIA via CUDA), and specialized AI accelerators. In the context of Immich, ONNX Runtime is the “brain” that scans your uploaded photos to identify faces, detect objects (like “dog” or “car”), and perform CLIP-based semantic searches.

The Role of Telemetry in Open Source Dependencies

Telemetry is the process of collecting usage data to help developers understand how their software is being used, identify bugs, and monitor performance. While this is standard practice in the enterprise software world, it is often viewed as a violation of trust in the self-hosted and DevOps communities.

Microsoft’s ONNX Runtime documentation explicitly states that telemetry is enabled by default. This telemetry includes information about the runtime version, hardware configuration, and execution patterns. While Microsoft claims this data is used for improving the runtime, the mere act of a containerized microservice initiating outbound connections to a third-party domain contradicts the “local-first” philosophy of the Immich project.

Why is it enabled in the Immich Docker Image?

When developers build Docker images, they often pull pre-compiled binaries or libraries. If the library (in this case, ONNX Runtime) has a default configuration that enables telemetry, and the developer does not explicitly pass a flag to disable it during the build or at runtime, the behavior persists. In the case of the ghcr.io/immich-app/immich-machine-learning image, the environment is not currently configured to suppress these calls.

Pros and Cons of the Current Implementation

FeatureProsCons
ONNX IntegrationHigh performance, cross-platform compatibility, excellent hardware acceleration.Introduces third-party dependencies with their own privacy policies.
Default TelemetryHelps Microsoft improve model execution efficiency and debug crashes.Causes “noise” in DNS logs, consumes negligible but unnecessary bandwidth, and violates privacy expectations.
Docker DeploymentEasy to scale and update via container orchestration.Obfuscates the underlying library behavior from the end-user.

Prerequisites

Before attempting to modify your Immich deployment, ensure you meet the following requirements:

System Requirements

  • Host OS: Linux (Ubuntu 22.04 LTS, Debian 12, or similar) is recommended.
  • Container Runtime: Docker Engine v20.10.0+ and Docker Compose v2.0+.
  • Hardware: A machine capable of running machine learning workloads (CPU with AVX support or an NVIDIA GPU if using the GPU-enabled version of Immich).

Required Software

  • Immich Stack: A working installation of Immich (Core, Machine Learning, Redis, and PostgreSQL).
  • Text Editor: nano, vim, or any editor to modify your docker-compose.yml or .env files.

Network and Security Considerations

  • DNS Management: Access to your DNS resolver (Pi-hole, AdGuard Home, or Unbound) if you wish to verify that the telemetry requests are successfully blocked.
  • Permissions: Sudo or root access to manage Docker containers and configuration files.

Pre-installation Checklist

  1. Back up your existing docker-compose.yml and .env files.
  2. Verify the current running status of your containers using docker ps.
  3. Identify which version of the machine learning image you are currently using.

Installation & Setup: Disabling Telemetry

There are two primary ways to handle this: the “Network Level” approach (blocking the domain) and the “Application Level” approach (disabling the feature via environment variables). For a robust DevOps setup, we recommend the Application Level approach, supplemented by the Network Level approach.

The ONNX Runtime allows users to disable telemetry by setting specific environment variables. Since Immich runs the machine learning component in a separate container, we need to inject these variables into the immich-machine-learning service definition in your docker-compose.yml.

Step 1: Modify the Docker Compose File

Open your docker-compose.yml file with your preferred editor:

1
nano docker-compose.yml

Step 2: Inject the ONNX Environment Variables

Locate the immich-machine-learning service section. You need to add the ORT_TENSORRT_TELEMETRY_DISABLED (if using TensorRT) and, more importantly, the general ONNX telemetry suppression variables. While ONNX Runtime’s telemetry control is often baked into the binary, the most effective way to handle this in a containerized environment without rebuilding the image is to ensure the service is restricted.

However, as of the current implementation, the most direct way to stop the runtime from attempting these calls is to set the environment variable that the underlying library respects.

Update your immich-machine-learning service as follows:

1
2
3
4
5
6
7
8
9
10
11
services:
  # ... other services (immich-server, postgres, etc.)

  immich-machine-learning:
    container_name: $CONTAINER_NAMES_ML
    image: ghcr.io/immich-app/immich-machine-learning:v3
    # ... other configurations (volumes, networks)
    environment:
      # This variable tells the ONNX runtime to suppress telemetry
      - ORT_DISABLE_TELEMETRY=1
    restart: always

Note: Replace $CONTAINER_NAMES_ML with your actual container name if you are using a template, or use the literal name defined in your file.

Step 3: Apply the Changes

Once the file is saved, you must recreate the container to apply the new environment variables. Use the following commands:

1
2
3
4
5
# Pull the latest images to ensure stability
docker compose pull

# Recreate the machine learning container specifically
docker compose up -d immich-machine-learning

Step 4: Verification

Verify that the environment variable has been correctly applied to the running container:

1
docker inspect $CONTAINER_ID_ML | grep ORT_DISABLE_TELEMETRY

If the output shows "ORT_DISABLE_TELEMETRY=1", the variable is active.

Method 2: The Network Level Approach (Defense in Depth)

Even with the environment variable set, a “Defense in Depth” strategy is a best practice in DevOps. You should block the telemetry domains at your DNS resolver to ensure that even if a library update re-enables telemetry, the data cannot leave your network.

Step 1: Identify the Target Domain

The primary domain identified by users is: mobile.events.data.microsoft.com

Step 2: Block via DNS (Pi-hole/AdGuard Home)

  1. Log in to your DNS management dashboard.
  2. Navigate to Blacklist or DNS Blocklists.
  3. Add mobile.events.data.microsoft.com to the list.
  4. Apply changes.

Step 3: Verify Blocking via Container Logs

Run a manual check within the container to see if it can still resolve the domain:

1
docker exec -it $CONTAINER_ID_ML nslookup mobile.events.data.microsoft.com

If the command returns an error (e.g., NXDOMAIN or connection timed out), your network-level block is working.

Configuration & Optimization

Once telemetry is disabled, you can focus on optimizing the Machine Learning service for your specific hardware.

Hardware Acceleration (NVIDIA GPU)

If you are running Immich on a machine with an NVIDIA GPU, ensure you are using the correct runtime to maximize performance and minimize CPU load.

Update your docker-compose.yml to include the NVIDIA runtime:

1
2
3
4
5
6
7
8
9
10
11
services:
  immich-machine-learning:
    image: ghcr.io/immich-app/immich-machine-learning:v3
    # ...
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Performance Tuning for CPU-only setups

If you are running on a CPU (e.g., a Raspberry Pi or an older NUC), the machine learning tasks can be heavy.

  1. Resource Limits: Prevent the ML service from starving the main Immich server by setting CPU limits in Docker.
  2. Concurrency: Immich manages the number of concurrent ML tasks, but ensure your host has enough RAM to handle the large models loaded into memory.
1
2
3
4
5
6
7
8
services:
  immich-machine-learning:
    # ...
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G

Usage & Operations

Monitoring the Service

To monitor the health and resource consumption of your machine learning service, use standard Docker commands:

1
2
3
4
5
# Check resource usage (CPU, Memory, Network I/O)
docker stats $CONTAINER_ID_ML

# View real-time logs to ensure no errors are occurring during inference
docker logs -f $CONTAINER_ID_ML

Maintenance and Updates

When updating Immich, always follow this workflow to ensure your telemetry fixes are not lost:

  1. Backup: Always backup your .env and docker-compose.yml.
  2. Update: Run docker compose pull.
  3. Re-verify: After docker compose up -d, run the docker inspect command mentioned in the installation section to ensure the ORT_DISABLE_TELEMETRY=1 flag is still present.

Backup and Recovery

The machine learning service itself is stateless; it does not store your photos. It only processes them. Therefore, you do not need to back up the ML container’s internal filesystem. Your primary backup focus should remain on:

  • The PostgreSQL database.
  • The upload directory containing your actual media.
  • Your docker-compose.yml and .env files.

Troubleshooting

Issue: The ORT_DISABLE_TELEMETRY variable doesn’t seem to stop DNS queries.

Solution:

  1. Check if you are using a different version of the ONNX runtime that might use a different variable name.
  2. Ensure you actually recreated the container using docker compose up -d, as simply changing the file does not update running containers.
  3. Verify the variable is present using docker inspect.
  4. If the variable fails, rely on the Network Level Approach (DNS blocking), which is a guaranteed way to stop the traffic.

Issue: Machine Learning tasks are failing or extremely slow.

Solution:

  1. Check logs: docker logs $CONTAINER_ID_ML.
  2. Look for “Out of Memory” (OOM) errors. If found, increase the memory limit in your docker-compose.yml.
  3. If using a GPU, verify the NVIDIA Container Toolkit is installed on the host and that nvidia-smi works.

Issue: Immich cannot connect to the Machine Learning service.

Solution:

  1. Ensure the service names in your docker-compose.yml match the IMMICH_MACHINE_LEARNING_URL environment variable in your immich-server configuration.
  2. Check that both containers are on the same Docker network.

Conclusion

The discovery of default telemetry in the ONNX Runtime used by Immich is a classic example of why DevOps engineers and sysadmins must maintain a “trust but verify” approach to third-party dependencies. While the telemetry is not malicious, its presence violates the privacy-centric ethos of the self-hosted community.

By implementing the ORT_DISABLE_TELEMETRY=1 environment variable and reinforcing it with DNS-level blocking, you can ensure that your machine learning workloads remain truly local. This dual-layered approach provides both application-level compliance and network-level security, creating a hardened infrastructure that respects user privacy.

For further technical details on the underlying library, please refer to the official ONNX Runtime Privacy Documentation.

This post is licensed under CC BY 4.0 by the author.