Bubble agent for on-premises connectivity


I do work with systems that reside on-premises and most of the time, the infrastructure team doesn’t allow a specific server to be exposed on the internet. I need to integrate those on-prem systems with Bubble, but it’s quite challenging.

I was thinking if there’s a way to build a “Bubble agent” that would make the connectivity and pass the traffic to and from Bubble, similar to an “Atom” in Dell Boomi.

We could install this lightweight agent on the network and have it handled by the security/networking team.

What do you think?

Hey @barizon :wave:

Did you ever find a solution to this?

Looking to do the same thing and trying to find a solution. :blush:

Very vaguely remember someone said they setup a Raspberry Pi as an HTTP server, and let that forward the commands to local devices on the network… :man_shrugging:

Yeah, my client has a server on-premises that they will set up an agent on, just need to figure out how to do that. Trying to see if someone has to code the agent, or if there is a ‘no-code’ way to do that. Maybe a platform out there that does that for us to simplify the process. :blush:

1 Like

No need to do that. In an enterprise environment, ask for a VM, and they’ll provide it. You can install a reverse proxy that will do the job for you. However, with or without the VM or Raspberry Pi, you’ll need to puck a hole in the firewall for bi-directional communication. That’s where the problem is: by opening a firewall on enterprise systems data, you risk all the financial, suppliers, customers, and employees’ data to anyone over the internet. It’s too risky.

The idea is to create an agent using a protocol such as a websocket that opens a “bridge” between bubble and the enterprise service without needing a firewall.

A websocket agent that translates the API calls and delivers them to bubble using the standard 443 port is vital for anything on the enterprise. This way, we’d have a seamless integration with any enterprise service - whether hosted on the Cloud or on-premise, and Bubble would be not only a single player on point-to-point communication but transforming it into a hub for multiple systems in a single location, safe, secure, certified (SOC 2 compliant - which is a good start) HIPPA, and other certifications.

Bubble has a lot of potential, but first, it needs to mature in the enterprise and know-how enterprise security works to serve mission-critical applications. This is what Microsoft does with their PowerApps - and trust me: they charge way more than Bubble for a piece of crap of software. Boomi also has a low-code portion called Boomi Flow. It’s enterprise-grade software and also has its potential, but it is too expensive for mid-size companies. Large corporations use the service a lot, and it’s super interesting. Mendix is another sophisticated player in the enterprise game. I think Siemens bought it a few years ago and improved it a lot. I see some Microsoft approach with Bubble, and I’m worried about an acquisition - that would destroy Bubble.

Anyway, if you’re up to researching a websocket connector - or building a tunnel service, let’s talk. I didn’t dig deeper into this because I had to improvise with my solutions. Instead of opening the firewall, I adjusted the process to fetch data back on Bubble, using the API response with the data.

But I’d love to have something like this, especially for chat capabilities.


Look for Boomi or MuleSoft. These are iPaaS platforms and do exactly what you’re saying. Boomi is more “low-code” than MuleSoft, but both works on the enterprise. Also, for Boomi, you’ll need to open a firewall hole.

I also recommend an API Gateway, I did a lot of research on KONG HQ, but it can be expensive. If i’m not wrong, it costs about $65K / year for the most basic plan. This can easily double for more robust capabilities. The OpenSource solution can be used for tests and development environments, but I don’t recommend production for mission-critical operations due to security concerns.


Thanks! I will check those out. :raised_hands: