top | item 40355744

Show HN: Pico: An open-source Ngrok alternative built for production traffic

244 points| andydunstall | 1 year ago |github.com

Pico is an open-source alternative to Ngrok. Unlike most other open-source tunnelling solutions, Pico is designed to serve production traffic and be simple to host (particularly on Kubernetes).

Upstream services connect to Pico and register endpoints. Pico will then route requests for an endpoint to a registered upstream service via its outbound-only connection. This means you can expose your services without opening a public port.

Pico runs as a cluster of nodes in order to be fault tolerant, scale horizontally and support zero downtime deployments. It is also easy to host, such as a Kubernetes Deployment or StatefulSet behind a HTTP load balancer.

55 comments

order

NathanFlurry|1 year ago

This is very cool! Trying to get it added to awesome-tunneling: https://github.com/anderspitman/awesome-tunneling/pull/149

Related -- we also built a simple (but not production-grade) tunneling solution just for devving on our open-source project (multiplayer game server management).

We recently ran in to an issue where we need devs to be able to have a public IP with vanilla TCP+TLS sockets to hack on some parts of our software. I tried Ngrok TCP endpoints, but didn't feel comfortable requiring our maintainers to pay for SaaS just to be able to hack around with our software. Cloudflare Tunnels is awesome if you know what you're doing, but too complicated to set up.

It works by automating a Terraform plan to (a) set up a remote VM, (b) set up SSH keys, and (c) create a container that uses reverse SSH tunneling to expose a port on the host. We get the benefit of a dedicated IP + any port + no 3rd party vendors for $2.50/mo in your own cloud. All you need is a Linode access token, arguably faster and cheaper than any other reverse tunneling software.

Source: https://github.com/rivet-gg/rivet/tree/main/infra/dev-tunnel

Setup guide: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...

apitman|1 year ago

This is a good candidate for the list. Most solutions don't really differentiate themselves much, but being designed for production environments is certainly unique amongst the open source options.

I'll try to get this merged today.

marssaxman|1 year ago

Why on earth would you reuse such a long-established name? Pico has been around for 35 years and many distros include it by default (or symlink `pico` to nano, anyway).

andydunstall|1 year ago

I didn't know there was already a long-established project called Pico :)

As someone suggested below, I'll rename to 'Piko'

crims0n|1 year ago

As a hobbyist and programmer, I love the project. As an infosec professional working in an enterprise environment... not so much.

andydunstall|1 year ago

Could you elaborate? Do you mean tunnelling generally or this implementation?

dmattia|1 year ago

Say I have a pico cluster with a few service nodes and a few upstream clients register themselves, and then I deploy a new version of the service nodes where all existing service nodes are taken down and replaced.

Can the client still talk to the service nodes? Is this over the same tunnel, or does the agent need to create a new tunnel? What happens to requests that are sent from a proxy-client to the service nodes during this transition?

Or at a much higher level: Can I deploy new service nodes without downtime?

andydunstall|1 year ago

When Pico server nodes are replaced, the upstreams will automatically reconnect to a new node, then that node will propagate the new routing information to the other nodes in the cluster

So if you have a single upstream for an endpoint, when the upstream reconnects there may be a second where it isn't connected but will recover quickly (planning to add retries in the future to handle this more gracefully)

Similarly if a server node fails the upstream can reconnect

v3ss0n|1 year ago

Check out ziti and zork projects, they are a lot more innovative and ambitious https://github.com/openziti/ziti

andydunstall|1 year ago

Yep I checked out overlay networks, its definitely a very cool project. However it also seems pretty complex to host. I think they are different use cases

PLG88|1 year ago

mispelling, zrok - https://zrok.io/. Its open source and has a free SaaS (or paid if you want).

chickenfish|1 year ago

I used a similar alternative to ngrok a few years ago - frp(https://github.com/fatedier/frp). What are the advantages compared of piko and frp?

andydunstall|1 year ago

From what I could see of FRP, it only runs a single server node so isn't suitable for production traffic (which needs to be fault tolerant, scale horizontally, support zero downtime deployments...)

Piko is also designed to be easier to host, so can be hosted behind a HTTP load balancer. That does mean Piko is currently limited to HTTP only, but that seemed a worthwhile tradeoff to make it easier to host

sipjca|1 year ago

Love this! Have been doing something similar with HAProxy + Cloudflare Tunnels, but would love to move off it at somepoint. Super curious to give it a run soon. Thanks for sharing!

illiac786|1 year ago

I have been considering cloudflare a bit, but it’s basically a mitm no?They decrypt your entire traffic then. It’s a lot of trust to put in cloudflare…

nodesocket|1 year ago

Is there a helm chart? Didn’t see one off the bat.

andydunstall|1 year ago

Not yet (still quite a new project), its on the list to add one

ArkimPhiri|1 year ago

I felt like it took me more time to set up Ngrok when I was trying my app. let me pico to see how the experience will be

sigmonsays|1 year ago

how do you access http services locally?

is there a socks5 proxy or something I can configure in my web browser?

andydunstall|1 year ago

Not sure I follow

Pico is a reverse proxy, so the upstream services open outbound-only connections to Pico, then proxy clients send HTTP requests to Pico which are then routed to the upstream services

So as long as your browser can access Pico it should work like any other proxy

(Theres a getting started guide if that helps: https://github.com/andydunstall/pico/blob/main/docs/getting-...)

mrbluecoat|1 year ago

> you can expose your services without opening a public port

But doesn't the Pico cluster have to expose a public port?

andydunstall|1 year ago

Few things:

- If your trying to access a customer network (such as for BYOC), exposing a public port in the customer network is likely a no-go (or would require complex networking to setup VPC peering etc)

- The Pico 'proxy' port doesn't need to be public (and in most cases won't be), such as you can only expose to clients in the same network (which is one of the benifits of self-hosting)

- The Pico 'upstream' port (that upstream services connect to) will usually need to be public, but that can use TLS and has JWT authentication