Closed AX-AMote closed 2 weeks ago
Hi @AX-AMote . We could do something optional. The reverse proxy is just here to redirect calls to the correct services, e.g: every call made to the path /api/ is redirected to the backend, otherwise to the front end. Both are express js servers in production mode. The backend is listening internally on the post 3000, the front end on the port 8000
ok perfect! Good to know! Is there any way to provide an example where the frontend container is on 8000 and the backend is on 3000 without the reverse proxy? I should then be able to connect directly to the service listening on port 8000 for front end access. Then I can put my own reverse proxy in front of the service and expose the WebUI by creating a routing rule pointing to port 8000 which can then talk to the back-end service on 3000 but remain safely within the private network.
@freedbygrace Yes, I managed a proxy free configuration.
Full example with CORS, etc... https://github.com/SquirrelCorporation/SquirrelServersManager/compare/test-changing-ports?expand=1
Just wondering if having a deployment available that does not include a reverse proxy?
I can definitely see the rationale in including a reverse proxy in order to help users get started faster, but it actually makes deployment more difficult.
If somebody already has a reverse proxy at the edge of their network handling SSL termination etc, then another reverse proxy makes this service two reverse proxy layers in and messes up the flow and complexity.
Some use Traefik, NGINx Proxy Manager, Zoraxy, HAProxy, Caddy, NGinX, OPNSense Plugins, etc.
I will gladly contribute my docker-compose.yml file after constructed to the repo if you can guide me on how to deploy without the included NGINx?