Disclosure: Some links in this article are affiliate links. We may earn a commission on qualifying purchases at no extra cost to you.
Getting Home Assistant entities into Apple Home starts with one integration: HomeKit Bridge. It's the piece that takes lights, locks, sensors and climate entities already running locally in Home Assistant and exposes them to Siri and the Home app — the opposite direction of the separate HomeKit Device integration, which pulls native Apple accessories into Home Assistant.
That direction confusion is the single most common reason HomeKit Bridge setups go wrong. The second most common reason is treating an iPad as a Home Hub, which no longer works under Apple's current Home architecture. The third is deploying on Docker without adjusting the container's networking, which silently breaks the mDNS discovery the integration depends on.
This guide covers the native HomeKit Bridge integration end to end: which installation types need special handling, how the 150-accessory-per-bridge limit works and when to split bridges, which entity types require accessory mode, how to fix the networking issues that account for most support threads, and where HomeKit Bridge stops making sense in favor of Matter.
It assumes a working Home Assistant install (HAOS, Supervised, Container, or Core) and at least one Apple device to run the Home app for pairing.
What You'll Need
- A running Home Assistant instance (HAOS, Supervised, Container, or Core), on the same local network as your Apple devices
- An Apple Home Hub: HomePod, HomePod mini, or Apple TV — an iPad no longer qualifies under Apple's current Home architecture
- Network access for mDNS (UDP 5353) and the integration's default port (TCP 21063)
- An iPhone or iPad with the Home app, for scanning the pairing code
- For Container/Docker installs: access to the compose file to set
network_mode: host, or to configureadvertise_ip
Before You Start — Prerequisites & Considerations
HomeKit Bridge vs. HomeKit Device — don't confuse the two
Home Assistant ships two separate integrations with overlapping names and opposite functions:
- HomeKit Bridge — takes Home Assistant entities and exposes them to Apple Home and Siri. This is what this guide covers.
- HomeKit Device (Controller) — takes native Apple HomeKit accessories and pulls them into Home Assistant.
They're configured independently, and a setup that only adds one won't produce the other's behavior. If the goal is "control my Home Assistant lights from Siri," HomeKit Bridge is the correct integration; HomeKit Device solves the reverse problem.
Installation type changes what you need to configure
- HAOS and Supervised installs typically work with no extra networking changes — the integration handles mDNS advertisement on its own.
- Container/Docker installs are the hard case: Docker's default bridge networking isolates mDNS traffic from the host network, which prevents the Home app from discovering the bridge at all. This needs
network_mode: host, oradvertise_ipcombined with an Avahi mDNS reflector (covered in Step 6). - Core (Python venv) installs behave like HAOS for this purpose, since there's no container network boundary to work around.
A Home Hub is mandatory for anything beyond the local network
A HomePod, HomePod mini, or Apple TV added to a room in the Home app becomes a Home Hub automatically. Local, same-network control from an iPhone doesn't strictly require one, but remote access, automations while away, and multi-user/family sharing all do. An iPad can no longer serve this role under Apple's current Home architecture — a legacy detail several older tutorials still get wrong.
Which Apple Home Hub to use
All three current Home Hub devices are Thread-capable and, per Home Assistant's own bridge testing, reliably handle up to 400 accessories. The differences are in networking and budget, not core reliability.
HomePod mini
Specifications: Apple S5 chip, Thread border router, Wi-Fi + Bluetooth 5.0, automatic Home Hub on setup.Budget tier — the cheapest way to unlock remote access and automations for a HomeKit Bridge setup.Check Price on Amazon
Pros: lowest cost of entry; small footprint; Thread border router included.
Cons: no Ethernet option; weaker as a hub if the Wi-Fi network is congested.
Verdict: the default choice for a single Apple TV-less household that just needs remote access to work.
Perfect for: apartments and single-room setups adding their first Home Hub.
Apple TV 4K (3rd gen, 128GB Wi-Fi + Ethernet)
Specifications: A15 Bionic, Thread radio, Gigabit Ethernet, Wi-Fi 6, becomes a Home Hub once added to a room.Mid tier — the most reliable option in Home Assistant's own hub testing, largely because it can run on Ethernet instead of Wi-Fi.Check Price on Amazon
Pros: wired connection removes Wi-Fi as a failure point; doubles as a media device; strongest large-bridge performance.
Cons: pricier than a HomePod mini; only the Wi-Fi+Ethernet 128GB configuration includes the Thread radio — the Wi-Fi-only variant does not.
Verdict: the safer pick for anyone running more than a handful of accessories or planning to split across multiple bridges.
Perfect for: households with 50+ HomeKit accessories or an existing home-theater setup.
HomePod (2nd generation)
Specifications: Apple S7 chip, Thread radio, Bluetooth 5.0, room-sensing audio, automatic Home Hub on setup.Premium tier — same hub reliability as the mini and Apple TV, at a higher price point justified mainly by audio quality rather than bridge performance.Check Price on Amazon
Pros: identical Thread/Matter capability to the mini; best speaker in the lineup.
Cons: the highest-priced of the three hub options, with no bridge-specific advantage over the Apple TV or mini.
Verdict: worth it only if the speaker itself is a factor — for hub duty alone, the mini or Apple TV do the same job for less.
Perfect for: buyers who want a home hub and a serious speaker in one device.
Step 1 — Add the HomeKit Bridge Integration
From Settings → Devices & Services → Add Integration, search for HomeKit Bridge. The setup wizard asks for a mode:
- Bridge mode (default) — groups multiple entities behind a single HomeKit accessory, up to the 150-accessory limit described below.
- Accessory mode — exposes exactly one entity as its own standalone HomeKit accessory. Required for certain entity types (see Step 3).
For a first setup, bridge mode covering most of the home is the normal starting point; accessory-mode instances get added separately per entity as needed.
Step 2 — Filter Which Entities Get Exposed
The integration lets filtering happen at three levels: by domain, by specific entity ID, or by entity glob pattern, with include and exclude lists at each level. Practically, this means a bridge can be scoped to "all lights and switches except the three test entities" or "everything in the living room area" without hand-picking every entity.
Home Assistant's supported domains for HomeKit Bridge include:
| Domain | Notes |
|---|---|
light, switch, fan, cover, valve |
Standard bridge support |
climate, water_heater |
Full thermostat controls |
lock |
Requires accessory mode |
camera |
Requires accessory mode; HomeKit Secure Video is not supported |
media_player (TV/receiver) |
Requires accessory mode |
alarm_control_panel, humidifier, binary_sensor |
Standard bridge support |
sensor (temperature, humidity, air quality, CO, CO₂, light) |
Standard bridge support |
scene, script, automation, vacuum, button |
Represented in Apple Home as switches, not their native type |
That last row matters: a Home Assistant scene doesn't show up in Apple Home as a scene — it appears as a toggle switch. This is a known, documented behavior gap, not a misconfiguration (see the FAQ below).
Step 3 — Set Accessory Mode Where Required
Cameras, locks, activity remotes, and TV/receiver media players won't work correctly inside a shared bridge — each needs its own dedicated HomeKit Bridge integration entry running in accessory mode, exposing that single entity as its own accessory. Skipping this step is one of the more common reasons a lock or camera pairs but then behaves unpredictably in the Home app.
For camera setups specifically, keep in mind that HomeKit Secure Video (Apple's cloud-recording feature) isn't supported through this integration — a locally-recorded system like the one covered in the Frigate self-hosted camera guide still needs Frigate or the equivalent doing the actual recording.
Step 4 — Pair with the Home App
Once the integration entry is created, Home Assistant generates a pairing code (QR code and numeric code, shown on the integration's detail page). In the Home app: Add Accessory → More options → enter/scan the code, then assign the bridge to a room. Repeat this pairing step independently for every additional bridge instance created (multi-bridge setups and accessory-mode entries each get their own code).
Step 5 — Split Bridges Once You Hit 150 Accessories
The HomeKit Accessory Protocol caps a single bridge at 150 unique accessories (aid). Past that limit, entities silently stop being exposed rather than throwing a clear error, which is why this ceiling catches larger installs by surprise.
The fix is to add a second (or third) HomeKit Bridge integration entry, each with its own include/exclude filter scoped to a non-overlapping set of entities — for example, one bridge for lighting and switches, a second for climate and sensors. Each instance gets its own pairing code and needs to be added to the Home app separately; they don't merge automatically.
Step 6 — Fix Docker and VLAN Networking
This is where most Container installs stall, and where most general-purpose HomeKit tutorials go thin.
Docker/Container installs: the integration relies on mDNS (UDP 5353) for discovery, which Docker's default bridge networking isolates from the host network. Two working fixes:
- Set
network_mode: hostin the compose file, giving the container direct access to the host's network stack. - If host networking isn't an option, set the
advertise_ipconfiguration option and run an Avahi mDNS reflector alongside the container to bridge the announcement across networks.
VLAN-segmented networks: mDNS/Bonjour doesn't cross VLAN boundaries by default. An Apple device on one VLAN won't discover a HomeKit Bridge announced from Home Assistant on another unless something reflects that multicast traffic — an Avahi or mDNS reflector service on the router/firewall (common on OPNsense/pfSense setups), paired with a static IP for the Home Assistant host so the reflector rule doesn't break on IP renewal.
Required ports, regardless of setup: UDP 5353 (mDNS) and TCP 21063 (the integration's default port; additional bridge instances increment from there).
Common Mistakes to Avoid
- Confusing HomeKit Bridge with HomeKit Device. They move data in opposite directions and are configured separately — adding one doesn't produce the other's behavior.
- Using an iPad as the Home Hub. It no longer qualifies under Apple's current Home architecture; use a HomePod, HomePod mini, or Apple TV instead.
- Skipping accessory mode for cameras, locks, and TV media players. These entity types need their own dedicated bridge instance — bundling them into a shared bridge causes inconsistent behavior in the Home app.
- Expecting HomeKit Secure Video to work. It isn't supported through this integration; local recording (e.g., Frigate) has to happen independently of the HomeKit Bridge.
- Deploying on Docker with default networking. Without
network_mode: hostoradvertise_ipplus an mDNS reflector, the Home app simply won't discover the bridge. - Ignoring VLAN segmentation. mDNS doesn't cross VLANs on its own; without a reflector, pairing and rediscovery after a restart will fail intermittently or entirely.
- Assuming Home Assistant can bridge entities to non-Apple Matter controllers. Home Assistant is a Matter controller, not a Matter bridge — it can consume and control Matter accessories, but it cannot natively expose its own entities to Alexa or Google Home over Matter. That requires a separate, third-party add-on (see below).
HomeKit Bridge vs. Matter — Which Should You Use?
Home Assistant's native Matter integration lets it control Matter accessories — it does not let it export Home Assistant entities to other ecosystems' Matter controllers. Getting Home Assistant entities into Alexa or Google Home over Matter requires a separate, community-maintained add-on (the third-party Home Assistant Matter Hub project), which is a materially different setup than the native HomeKit Bridge covered here.
| Native HomeKit Bridge | Third-party Matter Hub add-on | |
|---|---|---|
| Target ecosystem | Apple Home / Siri only | Alexa, Google Home, Apple Home simultaneously |
| Maintenance | Official, core Home Assistant integration | Community-maintained, separate install |
| Entity coverage | Broad (see domain table above) | Narrower, evolving |
| Setup complexity | Moderate | Higher |
For an Apple-only household, the native HomeKit Bridge remains the simpler, better-supported path — it's a first-party integration with a decade of iteration behind it. For anyone who needs the same Home Assistant entities visible to Alexa and Google Home and Apple Home at once, the third-party Matter Hub route is worth the extra setup, but it's a genuinely different project, not a checkbox inside this integration. The Matter integration setup guide and the broader Zigbee vs. Z-Wave vs. Matter comparison cover that path in depth.
Frequently Asked Questions
Q: Do I need a Home Hub if I only want local control?
No — local, same-network control from an iPhone or iPad works without one. A Home Hub (HomePod, HomePod mini, or Apple TV) is required for remote access away from home, automations that run while you're out, and multi-user/family sharing.
Q: Why do all my accessories show "No Response" after a restart or update?
This is usually one of three causes: router IGMP/multicast settings interfering with mDNS, the Home Hub switching between two eligible devices (e.g., an Apple TV and a HomePod), or an overloaded entity group inside Home Assistant. Try homekit.unpair followed by re-pairing, or homekit.reset_accessory for a single stuck entity, before assuming a full reconfiguration is needed.
Q: Can I bridge more than 150 devices?
Not on a single bridge — the HomeKit Accessory Protocol hard-caps a bridge at 150 unique accessories. Add a second (or third) HomeKit Bridge integration instance, each scoped to a different, non-overlapping set of entities via the include/exclude filters, and pair each one separately in the Home app.
Q: Why do my Home Assistant scenes show up as buttons in Apple Home instead of scenes?
This is a known, documented behavior of the integration — scenes are transferred as toggle buttons rather than native Apple Home scenes. It isn't a misconfiguration. The community workaround is the "Stateful Scenes" integration, installable via HACS, which better approximates scene-like behavior.
Q: Should I use Matter instead of the HomeKit Bridge?
Only if multiple ecosystems (Alexa, Google Home, Apple Home) need simultaneous access to the same Home Assistant entities. Home Assistant can control Matter accessories natively, but exporting its own entities to Matter controllers requires a separate third-party add-on — for Apple-only households, the native HomeKit Bridge is simpler and better supported.
Q: Does this work with Home Assistant Container/Docker installs?
Yes, but not out of the box. Docker's default networking isolates the mDNS traffic the integration needs for discovery. Set network_mode: host in the compose file, or configure advertise_ip alongside an Avahi mDNS reflector if host networking isn't available.
Conclusion
The native HomeKit Bridge integration is a mature, first-party way to get Home Assistant entities into Apple Home — the friction almost always comes from three predictable places: mixing it up with the reverse-direction HomeKit Device integration, underestimating what Docker and VLAN networking do to mDNS discovery, and missing the accessory-mode requirement for cameras, locks, and media players.
Get the Home Hub and networking prerequisites right first, filter entities deliberately instead of exposing everything at once, and split bridges proactively once an install approaches the 150-accessory ceiling. For most Apple-centric households, that's the entire setup — Matter's third-party bridging route is only worth the added complexity when Alexa or Google Home need the same entities too.
For related setup work, see the Home Assistant Matter integration guide, the beginner's guide to Home Assistant for anyone still setting up their first instance, and the Home Assistant automations guide for putting newly-bridged accessories to use in Apple Home shortcuts and Home Assistant automations alike. Anyone deciding on hub hardware for a larger install should also check the Home Assistant Green and Home Assistant Yellow reviews before committing to a platform.
