Troubleshooting n8n → Chroma: CORS, Collections, and Self-Hosted Networking

The described failure - heartbeat endpoint reachable via direct HTTP but the n8n Chroma node failing with CORS and not listing collections - often indicates a request path difference between manual tests and the n8n node. n8n nodes typically make server-side calls; however, some flows (especially credential validation in the UI) can make browser-originated requests that are subject to CORS policies on the Chroma side.

Start debugging by reproducing the exact request from the environment that fails. Use curl from the n8n host to the Chroma API and compare headers and response to the heartbeat check. Check if the Chroma container exposes the API on a different base path or port for admin vs. public endpoints. Confirm reverse proxies (NGINX, Traefik) are preserving Host and Origin headers and not injecting unexpected CORS or auth headers.

Remediations include configuring Chroma's CORS to explicitly allow the n8n origin (or the proxy), ensuring the node uses the correct collection base URL, and validating that any auth/token headers are set correctly. If the UI is trying to call Chroma directly, route those calls through n8n or a backend proxy to avoid browser CORS dependencies. Also verify network policies and DNS resolution inside the VNet and container network so both services see the same endpoint.

For business leaders: self-hosted stacks reduce cloud costs but increase integration fragility. Mitigate by codifying runbooks for common failures, adding synthetic integration tests that run on deploy, and considering a managed vector-store if uptime and predictable integrations are higher priorities than total cost of ownership.