[HN Gopher] Show HN: Pico: An open-source Ngrok alternative buil...
       ___________________________________________________________________
        
       Show HN: Pico: An open-source Ngrok alternative built for
       production traffic
        
       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.
        
       Author : andydunstall
       Score  : 165 points
       Date   : 2024-05-14 14:44 UTC (8 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | kowlo wrote:
       | Is there a way to use this with a simple docker-compose, no
       | Kubernetes?
        
         | dmattia wrote:
         | Looks like there is from the instructions in the getting-
         | started guide:
         | https://github.com/andydunstall/pico/blob/main/docs/getting-...
        
           | resoluteteeth wrote:
           | The instructions there say that it will create a cluster with
           | three nodes, so while it is using docker compose I am
           | guessing it is still using kubernetes
        
             | andydunstall wrote:
             | That demo only uses docker compose: https://github.com/andy
             | dunstall/pico/blob/main/docs/demo/doc...
        
             | abuani wrote:
             | The compose file is in the demo folder, you don't need to
             | guess what it's going to do. https://github.com/andydunstal
             | l/pico/blob/main/docs/demo/doc... Looks like it's spinning
             | up three replicas of Pico
        
       | baq wrote:
       | Not to be confused with
       | https://en.m.wikipedia.org/wiki/Pico_(text_editor) - no comments
       | on the project itself but the name is a bit unfortunate.
        
         | andydunstall wrote:
         | Yeah sorry I started Pico before realising...
        
           | abuani wrote:
           | Could also rebrand as Piko....
        
             | andydunstall wrote:
             | Good idea - will do that!
        
               | hobo_mark wrote:
               | Or Pigo? it's written in go after all :D
        
           | tmountain wrote:
           | Smart to rename. Pico editor is ubiquitous.
        
         | keb_ wrote:
         | Also not to be confused with https://github.com/picosh
         | 
         | or https://github.com/alexeyraspopov/picocolors
         | 
         | or https://github.com/fergalwalsh/pico
        
           | xd1936 wrote:
           | Or PicoCSS https://github.com/picocss/pico
        
             | keb_ wrote:
             | Or the footballer:
             | https://en.wikipedia.org/wiki/Pico_(footballer)
        
       | dmattia wrote:
       | 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 wrote:
         | 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
        
       | NathanFlurry wrote:
       | 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 wrote:
         | 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.
        
       | sigmonsays wrote:
       | how do you access http services locally?
       | 
       | is there a socks5 proxy or something I can configure in my web
       | browser?
        
         | andydunstall wrote:
         | 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.c
         | om/andydunstall/pico/blob/main/docs/getting-...)
        
       | sipjca wrote:
       | 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 wrote:
         | 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 wrote:
       | Is there a helm chart? Didn't see one off the bat.
        
       | crims0n wrote:
       | As a hobbyist and programmer, I love the project. As an infosec
       | professional working in an enterprise environment... not so much.
        
       | v3ss0n wrote:
       | Check out ziti and zork projects, they are a lot more innovative
       | and ambitious https://github.com/openziti/ziti
        
       | mrbluecoat wrote:
       | > you can expose your services without opening a public port
       | 
       | But doesn't the Pico cluster have to expose a public port?
        
       ___________________________________________________________________
       (page generated 2024-05-14 23:00 UTC)