One of the most common next steps after self-hosting Home Assistant is wanting the devices it manages to also be voice-controllable through Siri, show up in the iPhone’s Home app, or be usable as automation triggers for HomePod and Apple TV. The way to do this is with Home Assistant’s built-in HomeKit Bridge integration, which makes it masquerade as a HomeKit bridge, exposing selected entities one by one to Apple’s HomeKit ecosystem.
1. Get the Direction Straight First: Bridge Is Not Controller
Home Assistant’s official documentation specifically calls out one of the most common mix-ups: HomeKit Bridge (the homekit integration) and HomeKit Controller (the homekit_controller integration) do exactly opposite things, despite having almost identical names. HomeKit Controller brings in third-party devices that natively support HomeKit (“Works with HomeKit”) so Home Assistant can control them; HomeKit Bridge does the reverse — it exposes entities from Home Assistant so Apple Home and Siri can control them. This article covers the latter: making self-hosted devices visible to the Apple ecosystem, not bringing Apple devices into Home Assistant. Both integrations can be installed at the same time, and their functions don’t overlap at all — installing the wrong one for what you actually want won’t throw an error, it’ll just leave you thinking “I configured it but nothing happened.”
2. Enabling HomeKit Bridge
In Home Assistant, go to Settings → Devices & Services → Add Integration, and search for HomeKit. Choose the entity domains you want to expose (such as light, switch, climate) or individual entities. Once done, Home Assistant generates an 8-digit pairing code and displays a QR code. Scan it with the iPhone’s built-in Home app, or enter the code manually, to add this bridge to your home. Once added, Apple Home doesn’t see “Home Assistant” — it sees a bridge with a customizable name, with every exposed entity hanging off it.
3. The mDNS Pitfall Under Docker Deployment
HomeKit relies on mDNS (Bonjour) to broadcast itself on the local network so Apple devices can find the bridge. Docker’s default bridge network mode blocks the UDP 5353 multicast packets mDNS needs, which means that if Home Assistant is run with a plain docker run (without extra handling of the network mode), Apple devices may fail to discover the bridge entirely, or it may quickly show as “not found” after pairing.
The most direct fix is to switch the container to network_mode: host, letting Home Assistant share the host’s network interface directly, so mDNS broadcasts naturally reach other devices on the local network. If that’s not possible due to port conflicts with other services, or because the deployment environment doesn’t allow host networking, a fallback is to set advertise_ip in the HomeKit integration’s configuration to the host’s fixed local IP address, and run a separate mDNS reflector on the host (for example, avahi-daemon running in reflector mode) to forward the container’s broadcasts onto the physical network. If you’re running Home Assistant OS (HAOS), whether on a VM or bare metal, it has full host network access by default and doesn’t run into this problem — which is also why the official documentation recommends HAOS as the first choice when running HomeKit Bridge.
4. The 150-Device Limit
Each HomeKit bridge can carry at most 150 accessories. This isn’t noticeable with a small number of devices, but if you plan to expose your entire smart home — every light, every switch, every sensor — you can easily exceed this limit. The approach is to first filter down to the entities that actually need Siri or Apple Home control (excluding unneeded ones via the domain/entity filters in the integration’s configuration); if you’re still over 150 after filtering, you’ll need to create a second instance of the HomeKit Bridge integration and split devices across the two bridges, each paired into Apple Home independently.
5. How Much Does This Bridge Still Matter Now That Matter Exists?
In recent years, Apple Home has added direct support for the Matter protocol, and Home Assistant has its own Matter Server integration. If a device is natively Matter-capable, it can be paired directly into Apple Home (or any other Matter-supporting ecosystem) without going through Home Assistant’s HomeKit Bridge at all. Where HomeKit Bridge still genuinely has value is when a device doesn’t support Matter and has no native HomeKit support either, but has already been integrated into Home Assistant through some other means (Zigbee, Z-Wave, a vendor’s cloud API, etc.) — in that case, HomeKit Bridge remains the only bridge that makes those devices visible to the Apple ecosystem. In other words, it’s the device’s own protocol support that should decide whether to use this bridge, not “use it just because you can.”
6. Summary
HomeKit Bridge and HomeKit Controller point in opposite directions — confirming which one you actually want is the first step to avoid wasted effort. Under Docker deployment, mDNS is often the only sticking point, and host networking or an avahi reflector are the two viable paths around it; HAOS deployments generally don’t run into this at all. As the device count approaches the 150 limit, filtering entities or splitting across multiple bridges is more practical than ignoring it. The rise of Matter also means this bridge’s role will keep narrowing toward “existing devices that don’t support Matter,” rather than remaining the mandatory path for all smart-home traffic.