Where is the issue?
Setup Wizard, README, FAQ / Troubleshooting
What's wrong or unclear?
The webhook proxy addon (homeassistant-addon-webhook-proxy) has its own DOCS.md with complete setup instructions, but it's not mentioned anywhere in the main documentation — not in the README, the setup website, the FAQ, or the main addon's docs. Users have no way to discover it unless they happen to find it in the HA add-on store.
This matters because the webhook proxy provides a simpler setup path for certain users. Instead of requiring a dedicated tunnel to port 9583 (like Cloudflared), it proxies MCP traffic through HA's main port 8123 — which Nabu Casa and other existing reverse proxies already tunnel. For users who already have Nabu Casa or another reverse proxy pointing at their HA instance, this can be an easier setup than configuring a separate Cloudflare tunnel to port 9583.
In #784, a user with a TLS-configured HAOS installation couldn't connect via the standard direct method. After troubleshooting, they resolved the issue by installing the Nabu Casa webhook addon instead — but only after being pointed to it in the comments. Better documentation would have let them find this option on their own.
How should it be fixed?
Add mentions/references to the webhook proxy addon in:
- README — List it as an alternative setup option alongside Cloudflared
- Main addon DOCS.md — Cross-reference the webhook proxy for users who already have Nabu Casa or a reverse proxy pointing at HA's port 8123
- Setup site (
site/src/content/connections/remote.md and/or a new deployment/webhook-proxy.md) — Document it as a deployment option
- FAQ / Troubleshooting — Add an entry for users with TLS/connection issues pointing them to the webhook proxy as an alternative
A comparison or guidance section would also help users choose the right method:
- Direct to port 9583 (via Cloudflared or port forwarding): No extra hop, simpler architecture — best when you don't already have a reverse proxy or Nabu Casa
- Webhook proxy (via port 8123): Leverages existing Nabu Casa or reverse proxy infrastructure — simpler setup if that's already in place, but adds an extra hop (client → HA → webhook → MCP) and requires an HA restart on first install
It would be worth noting any known limitations or performance differences between the two methods, if any exist. From the issues I've seen, users have gotten both methods working successfully once configured correctly — but a systematic comparison would be valuable.
Additional context
Where is the issue?
Setup Wizard, README, FAQ / Troubleshooting
What's wrong or unclear?
The webhook proxy addon (
homeassistant-addon-webhook-proxy) has its ownDOCS.mdwith complete setup instructions, but it's not mentioned anywhere in the main documentation — not in the README, the setup website, the FAQ, or the main addon's docs. Users have no way to discover it unless they happen to find it in the HA add-on store.This matters because the webhook proxy provides a simpler setup path for certain users. Instead of requiring a dedicated tunnel to port 9583 (like Cloudflared), it proxies MCP traffic through HA's main port 8123 — which Nabu Casa and other existing reverse proxies already tunnel. For users who already have Nabu Casa or another reverse proxy pointing at their HA instance, this can be an easier setup than configuring a separate Cloudflare tunnel to port 9583.
In #784, a user with a TLS-configured HAOS installation couldn't connect via the standard direct method. After troubleshooting, they resolved the issue by installing the Nabu Casa webhook addon instead — but only after being pointed to it in the comments. Better documentation would have let them find this option on their own.
How should it be fixed?
Add mentions/references to the webhook proxy addon in:
site/src/content/connections/remote.mdand/or a newdeployment/webhook-proxy.md) — Document it as a deployment optionA comparison or guidance section would also help users choose the right method:
It would be worth noting any known limitations or performance differences between the two methods, if any exist. From the issues I've seen, users have gotten both methods working successfully once configured correctly — but a systematic comparison would be valuable.
Additional context
DOCS.md