Outbound connections and IP addresses

When a pipeline calls an API, fetches a file over SFTP, or reads a mailbox, that connection leaves Flovello from whichever machine happened to run the pipeline. That machine's IP address is not stable, and it is not something you can build against.

If the system on the other end grants access based on the caller's IP address, the integration will work right up until it doesn't — usually at an hour nobody is watching.

Why the addresses change

Flovello runs on elastic cloud infrastructure. Workers start and stop as load changes, hosts are replaced on every deploy, and execution capacity can move between machines, zones, and providers without any change to your pipeline. Each of those events can hand execution a different outbound address.

We deliberately keep this freedom. It is what lets us add capacity when pipelines queue up, replace a failing host in seconds, and move infrastructure without a migration window. Publishing a fixed list of addresses would trade all of that away, so we do not publish one, and any address you observe today is an accident of scheduling rather than a promise.

Execution stays within the European Union, as described in our terms of service. Within that boundary, the address can be anything, at any time, without notice.

The direction of the connection decides the answer

"Should I allowlist Flovello?" has two different answers depending on which way the connection travels.

Flovello connects to your system

This covers most integrations: HTTP request, the FTP nodes such as Get FTP file and Find FTP files, and the email nodes that read a mailbox over IMAP such as Find emails.

Here your server sees an incoming connection and decides whether to accept it. If that decision is based on a source-IP allowlist, the pipeline breaks whenever our address changes.

Hostname allowlisting is not a workaround for this case. A firewall evaluating an inbound connection has only the source address to go on; matching it against a name would require a reverse-DNS lookup, which we do not publish stable records for and which few firewalls perform on inbound rules anyway. If your server restricts by address, it restricts by address — there is no naming trick that survives it.

The fix is to stop treating the network address as proof of identity and let the caller prove who it is instead:

API tokens or OAuth2 for HTTP integrations. Wire OAuth2 client credentials into the credentials pin of HTTP request, or set an Authorization header with Make HTTP headers and Add HTTP header.
A dedicated account per integration, scoped to only the paths, mailboxes, or directories the pipeline actually touches. If a credential leaks, you revoke one account instead of auditing everything.
Transport security everywhere — HTTPS rather than HTTP, SFTP or FTPS rather than plain FTP, IMAP over TLS. An allowlist was never confidentiality; TLS is.
A signature over the payload when the receiving system supports it, so the request proves its own integrity regardless of where it came from.

Each of these is stronger than an IP allowlist even when the addresses are stable. An address says a packet came from a particular network; a credential says who sent it.

Your system connects to Flovello

This is the reverse case: something on your side calls a Receive HTTP trigger URL, or reaches the Flovello app or API.

If your outbound firewall requires an explicit rule, allowlist the hostname, not an IP address. Outbound rules are the one place where name-based allowlisting genuinely works — enterprise firewalls resolve FQDN objects, or inspect the TLS SNI, and our public endpoints sit behind stable hostnames whose backing addresses rotate underneath them. Pin the address instead and you are back to the same breakage, just on your own side of the wire.

Authentication still belongs at the application layer: each pipeline's Receive HTTP endpoints share a trigger secret, sent as Authorization: Bearer <secret>. You can find, rotate, and disable it under the pipeline's Settings tab.

When you genuinely need a fixed address

Some systems leave you no choice. Bank SFTP endpoints, ERP systems behind a corporate firewall, and legacy partner APIs are often governed by policies you cannot negotiate away, and "use a token instead" is not on the table.

That case is solvable, but not by allowlisting the shared platform — it needs execution to run somewhere with an address you control. Talk to us and describe the system you need to reach and the constraint you are working under. Dedicated execution arrangements are handled case by case, and we would much rather scope one with you up front than have you discover the limitation from a failed run.