Reaching on-premises systems: an outbound relay or a VPN?
Cloud integrations often need to reach a finance database or file server inside the city network. Comparing a site-to-site VPN, opened firewall ports and an outbound-only relay, with the questions to ask.
Many city systems live inside the network: the finance database, the file server where the bank drops its files, an internal API for the asset system. A cloud integration platform can't reach them on its own. Something has to connect the two.
There are three common ways to do it. Each has a place, and each asks different things of your network team.
Option 1: open a firewall port
The simplest approach on paper is to allow the vendor's addresses through your firewall to the internal system.
- Pros: quick to set up, nothing extra to run.
- Cons: an internal system is now reachable from the internet, even if only from listed addresses. Database ports in particular are a common target.
Most security teams resist this, for good reason. If you do it, limit it to a single host and port, require encryption, and review it regularly.
Option 2: a site-to-site VPN
A VPN creates an encrypted tunnel between your network and the vendor's.
- Pros: a well-understood pattern, encrypted, and familiar to network teams.
- Cons: it joins two networks at the network level. Without careful rules, the vendor side can reach more than it should. VPNs also need configuration on both ends, and can break when either side changes equipment.
A VPN is often the right answer for broad, long-term connections between two organizations. For an integration that needs one database and one folder, it can be more access than the job needs.
Option 3: an outbound-only relay
A relay is a small program that runs inside your network, near the systems it needs to reach. It connects out to the integration platform over HTTPS and asks for work. When a flow needs the finance database, the job goes to the relay, which runs it and sends back the result.
- Pros: no inbound ports to open. The relay reaches only the hosts your team lists on it.
- Cons: one more small thing to run and update on your network.
Because the relay only calls out, it works through most firewalls without changes. And because the allow-list lives on the relay, your team decides what it can reach, not the vendor.
Side by side
| Question | Open port | VPN | Outbound relay |
|---|---|---|---|
| Inbound firewall changes | Yes | Yes, for the tunnel | No |
| Scope of access | One host and port | Network level, unless restricted | Only the hosts you list |
| Who controls the scope | Your firewall | Both sides | Your relay settings |
| Setup effort | Low | Medium to high | Low |
| Extra software on your side | None | VPN equipment or service | A small relay program |
Questions for a relay
If you choose a relay, ask:
- Does it connect only outbound, over HTTPS?
- Where is the allow-list kept, and who controls it?
- Are jobs that wait for it encrypted, and deleted once done?
- What can it reach: databases, file servers, internal APIs?
- What does it run on: containers, Windows Server, or both?
- How is it authenticated, and can its token be revoked?
Questions for a VPN
If you choose a VPN, ask:
- Which of your hosts can the vendor side reach, exactly?
- Who on the vendor's side can use the tunnel?
- How are changes on either side coordinated?
- What happens to the integration when the tunnel drops?
Or keep it all inside
A fourth option is to run the integration platform itself on your own servers. Then internal systems are simply local, and only connections to cloud services go out. This suits agencies with strict network rules, or networks with no internet access at all.
A sensible default
For most integrations that need a handful of internal systems, an outbound relay with a tight allow-list is the least access that does the job. Use a VPN when you already have one with the vendor and the scope is well controlled. Avoid open ports unless there is no other option.
In SentraBridge
The SentraBridge Relay runs on your network as a container or on Windows Server. It connects out over HTTPS, reaches only the hosts on its own allow-list, and can carry database, file and internal API work. Jobs are encrypted while they wait and deleted as soon as they're done. SentraBridge can also be self-hosted entirely. See hosting options.