I would like to ask why my Pinecone/Supabase credentials cannot be set up successfully in n8n Cloud, even though they work correctly in my local n8n environment. In n8n Cloud, it keeps showing the error: “Forbidden – perhaps check your credentials?” I’m on Enterprise Edition.
Could anyone please advise on what might be causing this issue?
This is actually more common than you’d think when moving from local to Cloud and it usually comes down to one of these things.
First thing to check is whether your Pinecone or Supabase instance has IP restrictions enabled. Your local n8n connects from your own IP address, but n8n Cloud connects from their own server IPs. If your database or Pinecone index has an IP allowlist, n8n Cloud’s IP won’t be on it and you’ll get a Forbidden error every time. Check n8n’s documentation for their Cloud IP addresses and whitelist them on both services.
Second thing double check the credentials themselves when entering them in Cloud. API keys sometimes have hidden spaces or characters when copy pasted, especially from password managers or PDF documents. Delete the key field completely, type a space, delete it, then paste the key again. Sounds silly but it catches people out a lot.
Third, for Supabase specifically make sure you’re using the correct key. The anon key and the servicerole key have different permission levels. If your local setup uses the service role key but you entered the anon key in Cloud, you’ll hit permission errors on certain operations.
For Pinecone, confirm the API key you’re using has access to the specific index you’re trying to connect to and that the environment/region matches exactly.
Since it works locally the credentials themselves are valid so the most likely culprit here is the IP restriction issue. Start there first.
The “Forbidden” error you’re seeing is likely misleading. Because your credentials work perfectly on your local computer, the problem isn’t your username or password; instead, it’s a “digital fence” (a firewall) blocking n8n Cloud from talking to Pinecone and Supabase.
When you run n8n locally, the request comes from your own internet connection, which these services likely trust. However, n8n Cloud sends requests from its own set of servers. If Pinecone or Supabase don’t recognize those specific cloud IP addresses, they will automatically reject the connection and send back a “Forbidden” message.
For Supabase specifically, there is often a technical conflict between “Direct” and “Pooler” connections. n8n Cloud sometimes struggles with the way Supabase handles network routing (IPv6) or security certificates. Switching between the two connection methods in your settings often bypasses this block.
Since you are on the Enterprise Edition, you have a significant advantage. If whitelisting the IPs doesn’t work, you can contact n8n’s priority support. They can look at the backend logs of your specific cloud instance to see exactly where the connection is being dropped and fix it for you.
Works local, forbidden on Cloud is the classic IP-allowlist symptom, and the reply above is pointing the right way. Your local n8n connects from your home/office IP, which your Pinecone index or Supabase project already trusts. n8n Cloud connects from n8n’s server IPs, which are not on your allowlist, so the database refuses the connection and you get “Forbidden.”
Fix: in Supabase, check the network restrictions (and confirm you are using the right connection string, the pooler vs direct connection matters on Cloud). In Pinecone, check whether the index has IP or environment restrictions. Either allowlist n8n Cloud’s egress range or, where the provider supports it, use a connection method that does not pin to IP.
If it is not IP, the next suspect is the credential scope, a key that has read but not write, or a project-scoped key used against the wrong project. But start with IP, it fits “works local, fails on Cloud” exactly.