Remote Integration Execution

[titilambert]

Describe your core improvement

Enable Home Assistant integrations to run on separate machines (workers) while keeping the Core in control of all configuration and scheduling.

Users would configure workers in configuration.yaml (e.g., Docker hosts, Kubernetes clusters) and choose where each integration runs when adding it (local by default, or on a specific worker).
The Core would start/stop workers, trigger updates, and receive entity states via gRPC. Integration code would remain unchanged.

Example use cases:

• Run Core on a Raspberry Pi (critical integrations), resource-intensive integrations on a NAS
• Run AI/camera integrations on a machine with GPU
• Run Zigbee on the machine with USB dongle, everything else on another machine
• Isolate untrusted community integrations from Core

Current limitations

Currently, all integrations run in the same Home Assistant process on a single machine. This creates several problems:

• Limited isolation: Integration issues (memory leaks, native library crashes, infinite loops) can affect the entire Home Assistant instance
• Resource bottleneck: You need a powerful single machine to run everything (cameras, AI processing, many integrations)
• Can't leverage specialized hardware: No way to run AI integrations on a GPU machine, or Zigbee on the machine with the USB dongle while running Core elsewhere
• Expensive upgrades: When a Raspberry Pi isn't enough, you must buy a much more powerful single machine instead of reusing existing hardware
• No gradual scaling: Can't start small and add compute resources as needed

Technical benefits

• Isolation: Integration failures don't affect Core or other integrations
• Resource flexibility: Distribute integrations based on their resource needs (CPU, GPU, RAM)
• Hardware specialization: Use specific hardware where needed (USB dongles, GPUs) without moving all of Home Assistant
• Cost efficiency: Reuse existing hardware (old laptops, Pi's) as workers instead of buying expensive single machine
• Security: Isolate untrusted/community integrations from Core
• Gradual scaling: Start with Core on Pi, add workers as needs grow
• Better reliability: Critical integrations (alarms, locks) on UPS-backed hardware, others on cheaper machines
• No code changes: Existing integrations work without modification (uses gRPC proxy for hass.* calls)

Additional context

I have a working proof-of-concept with the Pi-hole integration:

• Integration code runs UNMODIFIED on a separate process
• Bidirectional gRPC communication between Core and worker
• States sync correctly, services work, polling works identically to local mode

Worker types planned:

• Process (local subprocess)
• Docker (local or remote Docker hosts)
• Kubernetes (pods)