Gostaria de perguntar por que minhas credenciais de Pinecone/Supabase não podem ser configuradas com sucesso no n8n Cloud, mesmo que funcionem corretamente no meu ambiente n8n local. No n8n Cloud, continua exibindo o erro: “Forbidden – perhaps check your credentials?” Estou na Enterprise Edition.
Alguém poderia me aconselhar sobre o que pode estar causando esse problema?
Isso é na verdade mais comum do que você imagina ao migrar de local para Cloud e geralmente se resume a uma dessas coisas.
A primeira coisa a verificar é se sua instância Pinecone ou Supabase tem restrições de IP ativadas. Seu n8n local se conecta a partir do seu próprio endereço IP, mas n8n Cloud se conecta a partir dos IPs do servidor deles. Se seu banco de dados ou índice Pinecone tem uma lista de permissão de IP, o IP do n8n Cloud não estará nela e você receberá um erro Forbidden toda vez. Verifique a documentação do n8n para os endereços IP do Cloud e adicione-os à lista de permissão em ambos os serviços.
A segunda coisa é verificar novamente as credenciais em si ao inseri-las no Cloud. As chaves de API às vezes têm espaços ou caracteres ocultos quando copiadas e coladas, especialmente de gerenciadores de senhas ou documentos PDF. Delete completamente o campo da chave, digite um espaço, delete-o, depois cole a chave novamente. Parece bobagem, mas pega muita gente.
Terceiro, especificamente para Supabase, certifique-se de que você está usando a chave correta. A chave anon e a chave servicerole têm níveis de permissão diferentes. Se sua configuração local usa a chave de função de serviço, mas você inseriu a chave anon no Cloud, você terá erros de permissão em certas operações.
Para Pinecone, confirme que a chave de API que você está usando tem acesso ao índice específico que você está tentando conectar e que o ambiente/região corresponde exatamente.
Como funciona localmente, as credenciais em si são válidas, então o culpado mais provável aqui é o problema de restrição de IP. Comece por lá primeiro.
O erro “Forbidden” que você está vendo é provavelmente enganoso. Como suas credenciais funcionam perfeitamente no seu computador local, o problema não é seu nome de usuário ou senha; em vez disso, é uma “cerca digital” (um firewall) bloqueando a comunicação do n8n Cloud com Pinecone e Supabase.
Quando você executa o n8n localmente, a requisição vem de sua própria conexão de internet, que esses serviços provavelmente confiam. No entanto, o n8n Cloud envia requisições a partir de seu próprio conjunto de servidores. Se Pinecone ou Supabase não reconhecerem esses endereços IP de nuvem específicos, eles rejeitarão automaticamente a conexão e enviarão de volta uma mensagem “Forbidden”.
Especificamente para Supabase, frequentemente há um conflito técnico entre as conexões “Direct” e “Pooler”. O n8n Cloud às vezes tem dificuldades com a forma como Supabase processa roteamento de rede (IPv6) ou certificados de segurança. Alternar entre os dois métodos de conexão nas suas configurações geralmente contorna esse bloqueio.
Como você está na Enterprise Edition, você tem uma vantagem significativa. Se a adição de IPs à lista de permissões não funcionar, você pode entrar em contato com o suporte prioritário do n8n. Eles podem analisar os logs de backend de sua instância de nuvem específica para ver exatamente onde a conexão está sendo perdida e corrigi-la para você.
Funciona localmente, proibido na Cloud é o sintoma clássico de IP-allowlist, e a resposta acima está apontando na direção certa. Seu n8n local se conecta a partir do seu IP de casa/escritório, que seu índice Pinecone ou projeto Supabase já confia. n8n Cloud se conecta a partir dos IPs dos servidores da n8n, que não estão em sua allowlist, então o banco de dados recusa a conexão e você recebe “Forbidden”.
Solução: no Supabase, verifique as restrições de rede (e confirme que está usando a string de conexão correta, o pooler versus conexão direta importa na Cloud). No Pinecone, verifique se o índice tem restrições de IP ou ambiente. Coloque na allowlist o intervalo de saída da n8n Cloud ou, onde o provedor suporta, use um método de conexão que não se fixe ao IP.
Se não for IP, o próximo suspeito é o escopo da credencial, uma chave que tem leitura mas não escrita, ou uma chave com escopo de projeto usada contra o projeto errado. Mas comece com IP, encaixa perfeitamente em “funciona localmente, falha na Cloud”.