You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Siren tries to connect to the beacon/validator client side. That's very unfortunate, because it requires exposing the two nodes to outside access.
A better model would be to allow running Siren in it's own container on a remote host, connecting itself directly to the two lighthouse nodes. Only the HTTP port needs to be exposed to the outside (which can be behind a VPN or whatnot).
The benefit is that I could have separate containers for the beacon client, validator client and siren, each running in the same (locked down) docker network. That would prevent any traffic from the outside reaching them, but it would permit unfettered access across one another.
The text was updated successfully, but these errors were encountered:
Yep, this has been discussed (internally) for a while now.
I believe its on our roadmap to introduce a backend to manage the connection for this reason. As we've got some external users also wanting this, we can aim to prioritize this.
Currently Siren tries to connect to the beacon/validator client side. That's very unfortunate, because it requires exposing the two nodes to outside access.
A better model would be to allow running Siren in it's own container on a remote host, connecting itself directly to the two lighthouse nodes. Only the HTTP port needs to be exposed to the outside (which can be behind a VPN or whatnot).
The benefit is that I could have separate containers for the beacon client, validator client and siren, each running in the same (locked down) docker network. That would prevent any traffic from the outside reaching them, but it would permit unfettered access across one another.
The text was updated successfully, but these errors were encountered: