Hey @Alejandro_Sophila, you can make this work with the single VPS. Personally, I would just replace Caddy with boringproxy unless you need/want special features provided by Caddy (it has many useful features that boringproxy is lacking). In this case, for the services running directly on the VPS, in boringproxy when adding the tunnels you would use the following settings:
Tunnel Port set to whatever port the service is running on
Client Name set to No Client
TLS Termination set to Server HTTPS
If you decide to leave Caddy in place, you’ll need to run boringproxy behind it. Note that others have run into issues with running other reverse proxies behind boringproxy. I feel like there are still some bugs with this setup. See here. I think you’ll need to use several options when running the server, including -allow-http, -behind-proxy, -http-port, -https-port.
Only obvious thing is that TLS Termination needs to be Server HTTPS. Looks like you’re sending a webhook? Can you try a simpler setup that doesn’t involve a 3rd party, just to make sure you have everything up and running? Something like a basic webserver (python3 -m http.server).
Allow External TCP shouldn’t affect what you’re doing. That just sets up the SSH tunnel so services can connect directly to the port without going through boringproxy.
You mean replacing nginx with boringproxy? Definitely tradeoffs. nginx has way more features, and is much more likely to be secure. boringproxy is still in beta. It’s more likely to crash or have other random issues. Even though it’s written in Go which is safer than C (which nginx is written in), I would still say boringproxy is more likely that nginx to have vulnerabilities that could allow your server to be hacked.