andydunstall

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

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

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

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

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

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

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

Good idea - will do that!

Yeah sorry I started Pico before realising...

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