Subject: Self-Hosted n8n Supabase Node Fails (401 Unauthorized) Despite Working curl/HTTP Request Node

Questions
1

Hello everyone,

I’ve been struggling with an issue for several days and haven’t found a solution.

My Setup:

  • I have self-hosted n8n and Supabase on the same VPS.
  • Each runs in its own Docker containers managed via Docker Compose.
  • A reverse proxy (based on jwilder/nginx-proxy and jrcs/letsencrypt-nginx-proxy-companion) handles HTTPS access and subdomains.
  • n8n is accessible and working correctly.
  • Supabase Studio is accessible via its subdomain (https://supabase.cyriloup.shop).
  • Both n8n and the Supabase containers (including supabase-kong) are on the same Docker network (web-network).

The Problem:

I cannot connect n8n to the Supabase API using the dedicated n8n Supabase credential/node.

  • When setting up the Supabase credential in n8n, the connection test fails with the message: “Couldn’t connect with these settings - Unauthorized”.
  • The supabase-kong container logs consistently show a 401 Unauthorized error for requests originating from n8n (identified by the user agent): GET /rest/v1/ HTTP/1.1" 401 ... "-" "n8n"

Key Troubleshooting Finding:

The issue seems specific to the n8n Supabase integration, as direct API calls work:

  1. Direct curl Test: A test using curl from the host VPS, targeting the public Supabase URL with the correct SERVICE_ROLE_KEY in the apikey header, succeeds (HTTP/2 200 OK).Bashcurl -I -H "apikey: YOUR_SERVICE_ROLE_KEY" https://supabase.cyriloup.shop/rest/v1/This confirms the API key is correct and Kong’s key-auth works for direct external requests.
  2. n8n “HTTP Request” Node Test: Using n8n’s standard “HTTP Request” node (configured with “Header Auth” using the same apikey header and SERVICE_ROLE_KEY) to target https://supabase.cyriloup.shop/rest/v1/ also succeeds (returns Code 200 OK).

This strongly suggests the problem lies specifically with how the n8n Supabase credential type or the Supabase node handles the connection/authentication.

Checks and Attempts Made (without success for the n8n Supabase credential/node connection):

  • API Key (SERVICE_ROLE_KEY):
    • Double-checked and carefully copy-pasted multiple times from the Supabase .env file to the n8n credential field (ensuring no extra spaces/characters).
    • Verified the key is correctly loaded as an environment variable inside the supabase-kong container using docker exec supabase-kong env | grep SUPABASE_SERVICE_KEY.
  • Host URL in n8n (Supabase API Credential):
    • Tested with the public URL managed by the proxy: https://supabase.cyriloup.shop.
    • Tested with the internal Docker service address: http://supabase-kong:8000.
    • Both result in the same 401 error when used specifically within the Supabase API credential setup.
  • Supabase/Kong Configuration:
    • Confirmed ~/docker/supabase/volumes/api/kong.yml exists and is loaded by Kong (visible in logs).
    • Verified kong.yml contains standard consumers (anon, service_role) with keyauth_credentials using $SUPABASE_ANON_KEY and $SUPABASE_SERVICE_KEY.
    • Confirmed key-auth and acl plugins are applied to the /rest/v1/ route. Temporarily disabling the acl plugin didn’t help.
    • (Attempted fix) Corrected the $SUPABASE_ANON_KEY variable mapping for the anon consumer in kong.yml.
  • Kong Entrypoint:
    • Tested with the original Supabase entrypoint (using eval) and a simplified version using --declarative_config_string. Both lead to the 401 error only in the Supabase API credential test. (Reverted to the original entrypoint).
  • Restarts:
    • Performed full restarts of the Supabase stack (docker-compose down && docker-compose up -d) after changes.
    • Restarted the entire VPS.
  • n8n Credential:
    • Deleted and recreated the Supabase API credential in n8n (e.g., named “Supabase API New”), but the issue persists.

Conclusion:

The problem is isolated to the n8n “Supabase API” credential type or the “Supabase” node itself. Standard authentication using the SERVICE_ROLE_KEY works perfectly fine via curl and n8n’s generic “HTTP Request” node. Kong only rejects the key when the connection attempt originates from n8n’s specific Supabase integration mechanism. This could potentially be a bug within this n8n feature or an issue where n8n misinterprets the configuration or API response.

Technical Information:

  • Kong Version (used by Supabase): 2.8.1
  • n8n Version: 1.90.0 (Issue was present also on 1.89.2, updating did not resolve it)

I’m looking for help understanding why the n8n Supabase credential/node fails with a 401 error, while other methods using the exact same API key and URL succeed.

Any ideas or suggestions would be greatly appreciated!

Thanks.

2

Hi, unfortunately this is an English speaking forum (désolé:)
Reg,
J.

1 Like
3

Okay, here is the English translation of the summary for the forum:

Subject: [Update] Issue Connecting n8n <> Self-Hosted Supabase (401) (You can adjust)

Message:

Hello everyone,

Following up on my initial post regarding connection failures between the n8n (v1.90.0) “Supabase API” credential and my self-hosted Supabase instance (with Kong 2.8.1 and a reverse proxy), here’s a summary of the tests performed and the results:

What Works:

  • :white_check_mark: API Keys: Verified correct (ANON_KEY and SERVICE_ROLE_KEY in Supabase .env file and confirmed loaded correctly into the Kong container’s environment).
  • :white_check_mark: Kong Config (kong.yml): Appears standard and correct (consumers anon/service_role defined, keyauth_credentials linked to $SUPABASE_ANON_KEY/$SUPABASE_SERVICE_KEY, key-auth and acl plugins applied to /rest/v1/ allowing anon/admin groups).
  • :white_check_mark: curl (from the VPS): Works perfectly using -H "apikey: YOUR_KEY" targeting the Supabase API (https://supabase.cyriloup.shop/rest/v1/) for both the ANON_KEY and the SERVICE_ROLE_KEY → 200 OK.
  • :white_check_mark: Postman (from my local machine): Works perfectly using the apikey: ANON_KEY header targeting the Supabase API (/rest/v1/) → 200 OK.
  • :white_check_mark: n8n “HTTP Request” Node: This standard node, running from my self-hosted n8n container, works perfectly targeting the Supabase API (/rest/v1/) using Header Auth (Name: apikey, Value: YOUR_KEY) for both the ANON_KEY and the SERVICE_ROLE_KEY → 200 OK.

What Still Fails:

  • :x: n8n “Supabase API” Credential: The connection test still fails with the “Couldn’t connect…” message, even when using the verified SERVICE_ROLE_KEY. Kong logs confirm a 401 Unauthorized response for requests with the “n8n” User-Agent.
  • :x: n8n “Supabase Vector Store” Node: (Presumably fails as it likely depends on the Supabase API credential).
  • :x: (FYI) Uptime Kuma: Also fails with 401 according to Kong logs, even when configured correctly (URL /rest/v1/, header apikey: ANON_KEY).

Checks Performed:

  • Temporarily disabling the acl plugin in Kong did not resolve the 401 error for the failing clients.

Conclusion:

The problem appears to be specifically related to the implementation of the n8n “Supabase API” credential (and the nodes that depend on it, like “Supabase Vector Store”), and also affects Uptime Kuma, when interacting with this specific self-hosted Supabase environment (Kong 2.8.1 + reverse proxy).

It’s not an issue with:

  • The API keys themselves (they work with other methods).
  • The basic Kong configuration or variable loading.
  • Network connectivity or n8n’s general ability to make authenticated requests (proven by the standard “HTTP Request” node).

Workaround:

Using the standard n8n “HTTP Request” node is a reliable workaround, but it significantly complicates workflows compared to using the dedicated nodes, especially for beginners or for tasks like using the Vector Store.

Hypothesis:

This strongly suggests a potential bug or incompatibility in how n8n’s dedicated Supabase integration handles authentication or formats requests specifically for self-hosted instances configured this way.

Has anyone else encountered this specific issue? Are there any other suggestions, or could the @n8nteam potentially investigate this incompatibility with self-hosted Supabase setups using Kong 2.8.1?

Thanks for your help.

4

Hi dude,
The problem is due to when making request for checking supabase credential, n8n added both “apiKey” and “Auhorization” to the Header (you can refer to their code here: n8n/packages/nodes-base/credentials/SupabaseApi.credentials.ts at master · n8n-io/n8n · GitHub)
Combining with the info from supabase API docs menu, I found out that when having Authorization in header, supabase under-the-hood logic seems to omit the “apiKey” as it will be looking for the user of that Authorization (not the service role key which not belong to any user)

image
image715×278 22.4 KB

My solution is to add the plugin that remove authorization key in the kong.yml file (you can find it in ./your-project/volumes/api/kong.yml):

- name: request-transformer
        config:
          remove:
            headers:
              - Authorization

image
image348×401 7.38 KB

And making sure in docker-compose file the kong service can use the kong.yml file correctly:

  kong:
    container_name: supabase-kong
    image: kong:2.8.1
    restart: unless-stopped
    networks:
      - supabase_network
    ports:
      - "${KONG_HTTP_PORT}:8000"
      - "${KONG_HTTPS_PORT}:8443"
    volumes:
      - ./volumes/api/kong.yml:/home/kong/temp.yml:ro,z
    depends_on:
      tailscale:
        condition: service_healthy
      analytics:
        condition: service_healthy
    environment:
      KONG_DATABASE: "off"
      KONG_DECLARATIVE_CONFIG: /home/kong/kong.yml
      KONG_DNS_ORDER: LAST,A,CNAME
      KONG_PLUGINS: request-transformer,cors,key-auth,acl,basic-auth
      KONG_NGINX_PROXY_PROXY_BUFFER_SIZE: 160k
      KONG_NGINX_PROXY_PROXY_BUFFERS: 64 160k
      SUPABASE_ANON_KEY: ${ANON_KEY}
      SUPABASE_SERVICE_KEY: ${SERVICE_ROLE_KEY}
      DASHBOARD_USERNAME: ${DASHBOARD_USERNAME}
      DASHBOARD_PASSWORD: ${DASHBOARD_PASSWORD}
    entrypoint:
      - bash
      - -c
      - |
        sed -e "s/\$$SUPABASE_ANON_KEY/${ANON_KEY}/g" \
            -e "s/\$$SUPABASE_SERVICE_KEY/${SERVICE_ROLE_KEY}/g" \
            -e "s/\$$DASHBOARD_USERNAME/${DASHBOARD_USERNAME}/g" \
            -e "s/\$$DASHBOARD_PASSWORD/${DASHBOARD_PASSWORD}/g" \
            /home/kong/temp.yml > /home/kong/kong.yml
        /docker-entrypoint.sh kong docker-start

Hope this can help!!

4 Likes
5

VPS

Gem personnalisé

Okay, here’s a draft for a thank you message in English to the expert. I’ve kept a slightly in

Hi
I just wanted to send a massive thank you for your incredibly insightful analysis and solution regarding the connection issue I was facing between the n8n “Supabase API” node and my self-hosted Supabase instance. We were really hitting a wall, and your explanation about n8n sending both an apikey and an Authorization header, and how Kong likely prioritizes the Authorization header (expecting a user JWT), was a complete game-changer!

I followed your instructions دقیقاً (exactly):

  1. Confirmed that the request-transformer plugin was enabled in Kong’s environment variables (it was).
  2. Carefully edited my /opt/supabase/volumes/api/kong.yml file to add the request-transformer plugin to both the rest-v1 and auth-v1 services, configured to remove the Authorization header.
  3. Restarted the Kong service.

And… IT WORKS PERFECTLY NOW! The n8n “Supabase API” node connects flawlessly using the SERVICE_ROLE_KEY.

Your diagnosis was spot-on, and the suggested fix resolved the issue террористической (immediately). I likely would never have figured out this specific interaction quirk on my own. This kind of deep expertise makes a huge difference.

Thanks again a million for sharing your knowledge and time to help me (and potentially others who might run into this). It’s truly appreciated!

Best regards,

6

legend this is great, thanks bro :slight_smile:

7

Your solution is genius (until n8n fixes the bug)! I have been struggling for a full 24 hours with this issue and none of the LLMs were able to pinpoint this behaviour … We came to the same conclusion empirically.

You fixed it in seconds.

Thank You!