Hi everyone,
I'm trying to securely connect n8n Cloud to an external database by whitelisting n8n's outbound IP addresses on our database's firewall rules.
I found the list of IPs published in the documentation (https://docs.n8n.io/manage-cloud/cloud-ip/), but the page mentions that "Cloud IP addresses change without warning".
Could anyone clarify what this actually means in practice?
- When changes occur, do they happen **within the existing list** (i.e. n8n uses a subset of these IPs at any given time, but the full list remains stable)?
- Or can the list itself change, meaning new IPs could be added or existing ones removed without notice?
Understanding this would help us decide whether whitelisting the full published list is a reliable long-term solution, or whether we should consider an alternative approach.
Thanks in advance for any insight!
1 Like
Hi @Claire_Girardeau Welcome!
Let me clarify, what they mean is that, the list of IPs is not static as they can remove some of those and add new IPs without any warning or message, so if you are thinking to whitelist some and use those as a long term, that would result in not guaranteed for being stable long enough, as even n8n refers to use very strong and stable auth and transport protocols so that their cloud IPs would not restrict you in case of any connectivity error, even the n8n API is domain based. So yeah in practice they mean that do not consider your n8n instance IP will be static and would not change even for the servers they interact with.
For a long-term solution, have you considered routing your n8n Cloud traffic through a static IP proxy?
The idea is: instead of whitelisting n8n’s rotating IPs on your database firewall, you put a proxy with a fixed IP in between. Your database only needs to whitelist that one stable proxy IP.
Just an Idea 
maybe it helps!
welcome to the n8n community @Claire_Girardeau
I’d treat the published IP list as a supported integration mechanism, but not as a contractual network boundary. So the real design question is whether your security model accepts a control that depends on external operational updates. If yes, whitelisting the full published list can be a valid managed process. If not, then the architecture probably needs a different trust boundary. In other words, this is less about whether the list works technically, and more about whether your team is comfortable owning the review, change management, and incident handling that come with it.