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

As commented below, Pico is already a well established name for a text editor so I've renamed to Piko: https://github.com/andydunstall/piko

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

zrok is a similar capability (though it can potentially do a lot more). OpenZiti is definitely a more complex project. In fact, zrok was built on top of OpenZiti.

We did this as Ziti provides a platform to develop secure by default, distributed applications quicker, which is why zrok has been built by only 1 developer across about 18 months and is almost feature parity with Ngrok (which has been developed by many people for almost 10 years).

No they does what you already did and not really complex to setup.

I worked on a minimal self-hosted ziti for Docker here https://github.com/openziti/ziti/tree/release-next/quickstar... and minimal self-hosted zrok (includes ziti) for Docker here https://docs.zrok.io/docs/guides/self-hosting/docker/

...so, basically:

wget https://get.openziti.io/dock/all-in-one/compose.yml docker compose up

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

Tunneling in general, or more specifically, bypassing the firewall and exposing a host on a trusted network segment to the public internet.

Agreed, thats why for production workloads it should be done with hardening and auth. Ngrok does that, as does Cloudflare. The version my company created does that too - https://blog.openziti.io/zrok-frontdoor

This is something I’ve worried about, but I’m not very knowledgeable. Say I have a service that’s receives traffic only from a trusted network segment and is behind a firewall, but I need to access the service for debugging purposes. Is there a canonical way to do this other than pushing logs out to some accessible location?

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

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

Post GPL3 Apple replaced GNU Nano (itself a Pico clone) with UW Pico. A step backwards perhaps, but nano is a symlink to pico. I'd steer clear of anything that looks/sounds like 'pico' including 'piko' which doesn't seem to clear anything up.

Ahh, what different worlds we all live in, unknowingly! :-)

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-...)

That demo only uses docker compose: https://github.com/andydunstall/pico/blob/main/docs/demo/doc...

Yeah sorry I started Pico before realising...

Could also rebrand as Piko....

Good idea - will do that!

Or Pigo? it's written in go after all :D

Smart to rename. Pico editor is ubiquitous.