Troubleshooting n8n to Supabase Connections: A Practical Checklist for Docker on macOS

The symptoms described-using a Supabase REST URL that includes /rest/v1/ and supplying an API key-are a typical source of misconfiguration. For server-side integrations like n8n you should use the project's base URL (for example, https://.supabase.co) rather than the REST path, and you must provide the appropriate server-side secret (usually the service_role key) for privileged operations such as RLS-bypassing RAG ingestion. Using client publishable keys will fail for server actions.

Start with simple connectivity checks outside n8n: from your Mac run curl against the Supabase endpoint using the candidate key to confirm a valid response. Example: curl -H "apikey: " "https://.supabase.co/rest/v1/health" (adjust to a benign endpoint). If that succeeds, the issue is likely Docker networking: ensure the n8n container can access the internet and DNS, and that no host-binding or proxy is interfering. On macOS Docker, avoid assuming localhost mapping-use proper container networking or set DOCKER_HOST appropriately.

In n8n, confirm you used the Service Node credentials fields correctly (host = base project URL, secret = service_role key), and check for environmental variables that may override credentials. Review Supabase Project Settings to ensure the API is enabled and that RLS/policies permit the intended queries. Also watch TLS: Supabase requires HTTPS; mixed or terminated TLS at a proxy can cause failures.

If problems persist, capture logs from the n8n container, reproduce the failing request with curl to get error details, and rotate keys after testing. For production, avoid embedding service_role in client-side contexts; instead run n8n centrally or behind controlled access. These steps will narrow the root cause and restore the Supabase-n8n connection reliably.