Just want to add more info here:
wsgrok is a local tunneling tool similar to ngrok, but it uses websocket and protobuf to perform reverse proxying over TLS between the server domain and the agent running on your local machine. you can pin the region closest to you or your target server, and wsgrok currently supports 4 regions across the US, with plans to add 4 more in India, Spain, Finland, and Taiwan.
some services offer native data transmission over encrypted channels like SSH tunneling. one of the advantages of those services is that you don't need to download a binary, but the downside is that you can't inspect the traffic. that's why wsgrok takes the same approach as ngrok because I think inspecting request and response data is very important in development. I know trust is critical for this kind of service, which is why I plan to open source it so users can install it on their own servers or build the agent from source.
I'm using this service myself to develop our commercial products. We've got to eat our own dog food :)
Not being able to add “one more domain” is an issue, but how does wsgrok ensure the domain link remains consistent after each server restart? That seems like a bigger problem since you’d otherwise have to update the domain across workflows every time the application restarts.
Can you elaborate on that? The subdomain in wsgrok is static. However, you can bind it to any local port of your choice when running a client. You don't need to update the domain across your workflows if you create a dedicated subdomain for each one.
Just want to add more info here: wsgrok is a local tunneling tool similar to ngrok, but it uses websocket and protobuf to perform reverse proxying over TLS between the server domain and the agent running on your local machine. you can pin the region closest to you or your target server, and wsgrok currently supports 4 regions across the US, with plans to add 4 more in India, Spain, Finland, and Taiwan.
some services offer native data transmission over encrypted channels like SSH tunneling. one of the advantages of those services is that you don't need to download a binary, but the downside is that you can't inspect the traffic. that's why wsgrok takes the same approach as ngrok because I think inspecting request and response data is very important in development. I know trust is critical for this kind of service, which is why I plan to open source it so users can install it on their own servers or build the agent from source.
I'm using this service myself to develop our commercial products. We've got to eat our own dog food :)
Not being able to add “one more domain” is an issue, but how does wsgrok ensure the domain link remains consistent after each server restart? That seems like a bigger problem since you’d otherwise have to update the domain across workflows every time the application restarts.
Can you elaborate on that? The subdomain in wsgrok is static. However, you can bind it to any local port of your choice when running a client. You don't need to update the domain across your workflows if you create a dedicated subdomain for each one.