[BUG]: Env-Proxy not used by self-hosted activepieces ce instance

[kabepst]

Describe the bug
I wanted to quickly try out activepieces for my employe. However the environment I'm in requires us to use a proxy-server (squid) for outgoing connections. While I managed to configure the docker daemon & docker compose to use this proxy as usual, I can't find any way to get activepieces to use this proxy to sync pieces via it. I also didn't found anything about this within the docs and/or by google-search. Is a proxy even supported for outgoing connections by activepieces ?

To Reproduce
Steps to reproduce the behavior:
Please note: You will only be able to reproduce this within an environment where outgoing (internet) connections are restricted and can only be done via a proxy-server. You will also need to configure the docker host as described here:

• For the Docker-Client: https://docs.docker.com/network/proxy/#configure-the-docker-client
• For the Docker-Daemon: https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

1. Setup activepieces exactly as described here (docker compose variant): https://www.activepieces.com/docs/install/options/docker-compose
2. Start the containers with the provided command: docker compose -p activepieces up
3. Note the error in debug output in regard of sync:
   • 
4. Open the WebUI, setup the initial account and try to create a workflow from template. It stays "forever" (waited for 15 Minutes) within this loading screen:
   • 
5. However when reloading the page you will get an empty workflow without the things that should be within the template. You will also note that activpieces says that there are 0 triggers, pieces etc. available:
   • 

Expected behavior
I would expect the activepieces container to respect the provided proxy-config via the ~/.docker/config.json as described within the above Link (Docker-Client).

Additional context

• I was able to convince my network engineers to quickly open a direct connection for my testmachine for test purposes to test if anything works when activepieces can connect to internet directly and indeed then everything is working.
• I also double-checked the proxy-logs to make sure that none of the traffic is blocked there. None of the traffic is blocked there and I can't find any occurence of the used url for pieces-synchronisation within that log. This is another indicator for me that activepieces does not use/respect the provided proxy config (perhaps the os of the activepieces container does but not the app itself imho).
• I have several other containerized applications (mostly internal staff) based on various images (alpine, debian and ubuntu) where the above mentioned configuration does work without any issues.
• Let me know if there is anything else I can try out and/or what information else could help you to further analyze this. I'm happy to help where I can

[abuaboud]

Hi @kabepst,

We haven't tested it, and I am not familiar with Docker proxy. Do you know if we have to do something in Docker to support it? I still need to read about it.

Not sure if that helps. The two endpoints being used are:

• Listing one: https://cloud.activepieces.com/api/v1/pieces
• Piece example: https://cloud.activepieces.com/api/v1/pieces/@activepieces/piece-google-sheets

These endpoints just list the npm packages for pieces. There is a workaround to install each version manually, but then you will have to update each piece manually.

[kabepst]

Hi @abuaboud and thx for your fast reply up first :) I'm unsure if this is really a docker-related problem, but I will try to elaborate a bit more below. Please note up first that I'm not a developer, I'm a systems engineer guy, so sry if the dev-terms aren't the correct ones everytime :)

What I would want and/or need is a support for using a network proxy for outgoing connections for activepieces sync via cloud. How this has to be implemented is based on the techstack you are using. Based on that there are multiple options what you can do or how this can be implemented. I try to give an example based on the webbrowser Mozilla Firefox. Within Firefox you have 3 options how you can define a proxy:

1. You can tell firefox to use the os settings (windows for example). If the os has a network proxy configured, firefox will use it with the same settings for outgoing connections. In the context of docker this is normally achieved by the above mentioned ~/.docker/config.json (see this https://docs.docker.com/network/proxy/#configure-the-docker-client ) file. This file tells the container-os to use the configured network proxy for outgoing connections. It's the same as within a classic linux os installation providing the env-vars "http_proxy" and "https_proxy". But again: This only tells the container-os to use the mentioned proxy (so for example running an apt update within a ubuntu-based container). It's up to an application (based on the used techstack) to implement a method to detect if a proxy is configured and if so use it.
2. You can tell firefox to use (regardless what is configured within the os itself) to use a specific network proxy. You then provide firefox itself all the needed config options (server adress, supported protocols, port, auth etc.) instead of using those which are configured. In our usecase here this would mean that there would be an option within activepieces (for example additional vars within the .env file) in which you can provide the needed proxy configuration and activepieces then uses this information for outgoing connections to sync the pieces (or anything else that comes from internet/cloud).
3. The 3rd option isn't really important imho in this case but I want to note it so no one is suprised when checking this against the actual options within firefox: Last option is to tell firefox to automatically detect a proxy based on various (rfc standards if I remember right) protocol out there. The 2 most common are a specific DHCP-Option (see this for a quick explanation https://superuser.com/questions/382964/dhcp-option-252-what-is-it#:~:text=Option%20252%20provides%20a%20DHCP,know%20how%20to%20handle%20it). ) and/or a DNS-Entry called wpad.domain.tld in combination (both of them) with a so called WPAD/PAC-File. However imho this is way beyond what 99% of users will need and would perhaps be a lot of effort to implement which then no one will use anyway. That's why I mentioned i only write it here for "compliance" :D

However during testing I found out that option 2 is for some actions already implemented. For example the HTTP-Call action has an option to configure a network proxy to use:

So without any technical speaking/details and long story short: I'm looking for an option to do the exact same but in regard of the pieces-synchronisation and not a specific piece and/or action itself. I hope this clarify where I'm struggling and what I'm looking for :)