I’m currently setting up a workflow on n8n Cloud and encountering persistent issues when trying to establish a secure connection to my Supabase PostgreSQL database hosted in the eu-central-1 region.
I have attempted to configure the Postgres credentials using two different connection methods provided by Supabase, and both fail when using secure settings (SSL: require, Ignore SSL Issues: OFF):
When using the Supabase Transaction Pooler connection string:
The connection fails with the error: Couldn’t connect with these settings - self-signed certificate in certificate chain.
The connection only succeeds if I enable the insecure option Ignore SSL Issues (Insecure), which is not suitable for production.
The Pooler Hostname used: aws-0-eu-central-1.pooler.supabase.com
When using the Supabase Direct Connection string:
The connection fails with the error: Couldn’t connect with these settings - connect ENETUNREACH [IPv6 Address] - Local (:::0). It seems the n8n Cloud environment cannot reach the resolved IPv6 address for the direct database host.
The Direct Connection Hostname used: db.fiytqolahyaophzrtdjb.supabase.co (This resolves to IPv6).
Given these two distinct errors depending on the connection method, it suggests there might be an issue within the n8n Cloud environment regarding either SSL certificate validation for the pooler endpoint or IPv6 network reachability for the direct endpoint in the eu-central-1 region.
Could you please investigate potential connectivity or SSL validation issues from your side to these Supabase endpoints?
I am currently using n8n Cloud and experiencing persistent problems establishing a secure connection to my Supabase PostgreSQL database located in the eu-central-1 region.
I have systematically tried all three connection methods provided by Supabase, using the correct credentials (including the postgres.[project-ref] username format for pooler connections) and setting SSL: require with Ignore SSL Issues: OFF in the n8n Postgres credential settings. All attempts have failed:
Transaction Pooler Connection:
Host: aws-0-eu-central-1.pooler.supabase.com
Port: 6543
Result: Fails with error Couldn’t connect with these settings - self-signed certificate in certificate chain.
Direct Connection:
Host: db.fiytqolahyaophzrtdjb.supabase.co (This resolves to an IPv6 address)
Port: 5432
Result: Fails with error Couldn’t connect with these settings - connect ENETUNREACH [IPv6 Address] - Local (:::0). The n8n Cloud environment appears unable to reach the database host via IPv6.
Session Pooler Connection:
Host: aws-0-eu-central-1.pooler.supabase.com
Port: 5432
Result: Also fails to connect (likely the same SSL certificate error as the Transaction Pooler, though the exact message wasn’t captured for this specific attempt).
Important Note: The connection only works across all methods if I enable the insecure option Ignore SSL Issues (Insecure). This strongly suggests an issue with SSL certificate validation or network reachability specifically within the n8n Cloud environment when connecting to these Supabase endpoints.
Could you please investigate the SSL certificate validation capabilities (e.g., trusted CA certificates) and network connectivity (especially IPv6 reachability to db... host and SSL handshake to pooler... host) from your n8n Cloud infrastructure towards Supabase in the eu-central-1 region?
Resolving this secure connection issue is critical for my project.
Thank you for your previous response regarding the Supabase connection issue.
I understand the suggested solution involves adding certificates to the /opt/custom-certificates directory. However, I need to clarify that I am using n8n Cloud, not a self-hosted instance, so I do not have the ability to mount volumes or modify the container’s trust store directly.
Therefore, the previous suggestion is unfortunately not applicable to my situation. The connection problem from my n8n Cloud instance to Supabase Postgres (eu-central-1 region) persists when using secure settings (SSL: require and Ignore SSL Issues: OFF).
The only way I can currently establish a connection is by enabling the insecure Ignore SSL Issues (Insecure) option, which is not a viable long-term solution.
Could you please re-investigate this from the perspective of the n8n Cloud environment? Specifically, could you check the CA certificate trust store used by n8n Cloud instances and the network connectivity (including IPv6 routing and SSL handshakes) towards the Supabase endpoints (aws-0-eu-central-1.pooler.supabase.com and db.fiytqolahyaophzrtdjb.supabase.co) in the eu-central-1 region?
It seems the issue lies within the n8n Cloud infrastructure’s ability to securely connect to or validate certificates from these specific Supabase regional endpoints.
Well, I’m assuming that it’s not possible to trust custom certificates in the cloud instance, so your only option is to disable the certificate check (or use a self-hosted instance).
If you have a paid plan, you can reach out to the support team and maybe they can help you.