Ubuntu's AI Kill Switch Explained: Disabling Canonical's AI Features on Your Homelab Server

Canonical has been steadily expanding Ubuntu’s AI footprint — AI-assisted package suggestions, Snap-delivered model runtimes, and Ubuntu Pro integrations that touch your system in ways that aren’t immediately obvious from a minimal server install. The “kill switch” framing comes from Canonical’s own acknowledgment that these features are opt-in and removable, but “opt-in” is doing a lot of work when some components land by default on cloud and desktop images.

This guide is for homelab operators running Ubuntu Server 24.04 LTS (Noble Numbat) or planning for 26.04. Here is exactly what gets installed, how to audit it, and how to cleanly remove AI-related components without breaking your base system.

What Canonical’s AI Features Actually Install

On a minimal Ubuntu Server ISO install, you get less than you might fear. The danger zone is cloud images (AWS/GCP/Azure), the full server ISO, and anything pulled in by ubuntu-advantage-tools (now rebranded as pro).

The components to know about:

• ubuntu-pro-client (pro) — Manages Ubuntu Pro subscriptions. Since 23.10 it ships by default and includes hooks for AI-related services under the Pro umbrella.
• snapd — The snap daemon. Not inherently AI, but it is the delivery mechanism for Canonical’s AI snaps.
• landscape-client — System management agent that reports inventory to Canonical’s Landscape SaaS. Often auto-installed on cloud images.
• ubuntu-report — Sends hardware/software telemetry on first boot.
• AI model snaps — Things like ollama, openai-cli, or future Canonical-published model snaps are Snap-packaged. On 26.04, Canonical has signaled intent to publish curated AI snap bundles.

The Phoronix coverage of the kill switch confirms that Canonical’s position is: AI features are snap-delivered and snap-removal is the kill switch. That is accurate but incomplete — the telemetry and Pro client hooks persist unless you deal with them separately.

Step 1: Audit What’s Running

Run this immediately after a fresh install or on an existing server:

#!/usr/bin/env bash
# audit-ubuntu-ai.sh — quick audit of AI/telemetry components

echo "=== Snap packages ==="
snap list 2>/dev/null || echo "snapd not installed"

echo ""
echo "=== Ubuntu Pro status ==="
pro status 2>/dev/null || echo "ubuntu-pro-client not installed"

echo ""
echo "=== Landscape client ==="
systemctl status landscape-client 2>/dev/null || echo "landscape-client not found"

echo ""
echo "=== Telemetry service ==="
systemctl status ubuntu-advantage 2>/dev/null
systemctl status ua-timer 2>/dev/null

echo ""
echo "=== Phoning-home candidates ==="
ss -tlnp | grep -E '443|80' | grep -v "127.0.0"

echo ""
echo "=== /etc/ubuntu-advantage/uaclient.conf ==="
cat /etc/ubuntu-advantage/uaclient.conf 2>/dev/null || echo "File not found"

Make it executable and run it: chmod +x audit-ubuntu-ai.sh && sudo ./audit-ubuntu-ai.sh

Step 2: Remove or Disable AI and Telemetry Components

Disable ubuntu-report (telemetry on first boot)

sudo ubuntu-report send no

That writes a suppression flag. To confirm it won’t fire again:

cat ~/.config/ubuntu-report/ubuntu-report.json

Remove the Ubuntu Pro client (if you don’t need it)

If you are not using Ubuntu Pro ESM patches or FIPS, the pro client is dead weight:

sudo apt purge ubuntu-pro-client ubuntu-advantage-tools
sudo apt autoremove

Warning: If you rely on livepatch or esm-infra repos, do not remove this. Most homelabbers running behind a patching schedule don’t need it.

Disable Landscape

sudo systemctl disable --now landscape-client
sudo apt purge landscape-client landscape-common
sudo apt autoremove

Remove snapd entirely (the nuclear option)

If you have no snaps you need and want the cleanest possible system:

# Remove all installed snaps first
snap list | awk 'NR>1 {print $1}' | xargs -I {} sudo snap remove {}

# Remove snapd
sudo apt purge snapd
sudo apt-mark hold snapd   # prevent reinstall via dependencies

# Clean up snap directories
sudo rm -rf /snap /var/snap /var/lib/snapd /var/cache/snapd ~/snap

After this, pin snapd to prevent it sneaking back in:

cat <<EOF | sudo tee /etc/apt/preferences.d/no-snapd
Package: snapd
Pin: release a=*
Pin-Priority: -1
EOF

Remove specific AI snaps without nuking snapd

If you want to keep snapd for other snaps (e.g., lxd):

sudo snap remove --purge ollama 2>/dev/null
sudo snap remove --purge ubuntu-ai 2>/dev/null   # placeholder for future snap names

Run snap list and remove anything you didn’t deliberately install.

Docker-Based Approach: Isolate Everything

If you are running homelab services in containers anyway, the cleanest approach is a minimal Ubuntu base with all of this handled at build time:

# docker-compose.yml — minimal Ubuntu service with no AI/telemetry cruft
services:
  myservice:
    build:
      context: .
      dockerfile: Dockerfile.minimal-ubuntu
    restart: unless-stopped
    network_mode: bridge

# Dockerfile.minimal-ubuntu
FROM ubuntu:24.04

# Suppress interactive prompts
ENV DEBIAN_FRONTEND=noninteractive

# Remove telemetry and pro client from the base image
RUN apt-get update && \
    apt-get purge -y ubuntu-pro-client ubuntu-advantage-tools ubuntu-report && \
    apt-get autoremove -y && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

# snapd doesn't run inside containers by default — confirm it's absent
RUN apt-get list --installed 2>/dev/null | grep -v snapd || true

CMD ["/bin/bash"]

Container images don’t run snapd anyway (no D-Bus, no systemd by default), so the snap attack surface is zero inside Docker. The purge step handles the Pro client hooks.

Ubuntu vs Debian vs Fedora: Does This Change the Calculus?

Honest take for homelabbers:

Ubuntu Server 24.04 LTS — Still the path of least resistance if you need broad package availability, LXD integration, or cloud tooling that assumes Ubuntu. The AI components are removable. The 5-year LTS window matters if you set servers up and leave them.

Debian 12/13 — No snapd, no Canonical telemetry, no Pro client. apt and done. If your workload runs fine on Debian’s package versions (which are conservative), this is the lower-noise option. The tradeoff is slower package updates and occasionally older versions of tools like Docker Engine requiring third-party repos anyway.

Fedora Server 41+ — Fresh packages, SELinux by default, no snap infrastructure. Good if you want rpm-ostree immutable deployments. Less ideal if your homelab scripts assume Debian/Ubuntu conventions.

For a headless homelab server you SSH into and forget — Debian or Ubuntu minimal with the steps above applied. For a homelab that doubles as a dev environment where you want current packages — Ubuntu 24.04 with snapd removed and Pro client purged is still competitive.

Verifying Nothing Is Calling Home

After your cleanup, confirm with a 60-second tcpdump or check with ss:

sudo tcpdump -i any -n 'host contracts.canonical.com or host landscape.canonical.com or host motd.ubuntu.com' -c 20 &
sleep 60
sudo kill %1

No output means no callbacks to Canonical endpoints. Also worth blocking at the DNS level in your homelab if you run Pi-hole or AdGuard Home: add contracts.canonical.com, landscape.canonical.com, and motd.ubuntu.com to your blocklist.

What’s Next

• /homelab/debian-vs-ubuntu-server-homelab — Deep comparison of Debian vs Ubuntu for headless homelab servers
• /homelab/snapd-remove-ubuntu-server — Full guide to removing snapd from Ubuntu without breaking LXD
• /homelab/pihole-network-dns-blocking-homelab — Block telemetry at the network level with Pi-hole
• /homelab/docker-minimal-ubuntu-base-images — Building stripped-down Ubuntu Docker base images for homelab services