flyctl now uses by default

Today we released flyctl 0.0479, which defaults to using whenever it needs to work with the Machines API. This improves performance and reliability when working with Machines and Apps V2 apps.

Previously, flyctl used user-mode wireguard to work with the internal Machines API. This works great in a lot of cases. User-mode networking does have some performance implications relative to system networking.

In cursory testing of this change we saw 300-1000ms+ improvements in flyctl command runtime with using Some of that is time saved from establishing the wireguard connection, and some is the overhead of using user-mode networking. The difference is probably not noticeable for longer running commands like fly deploy. For other commands like fly status or fly machine list it will be. is our public proxy to the internal Machines API that runs in every region. Developers connecting to regions that do not have wireguard gateways may see additional performance improvements.

The user-mode wireguard access to the internal Machines API is still available! Set the environment variable FLY_FLAPS_BASE_URL=peer to continue using the internal Machines API over user-mode wireguard. For example, FLY_FLAPS_BASE_URL=peer fly machines list will establish a wireguard connection and use the internal Machines API to get the list of machines.

Let us know if you notice any performance changes or if you run into issues!


Nice. Next step, a golang sdk for Machines / Apps v2? (:


Not yet as such. That said, lots of flyctl code is importable if you want :wink:


We ended up just writing our own go SDK for Fly Machines and Fly Apps! Referenced the flyctl project which was helpful.


You should write about in the official machines documentation, i think 99% of users would want to use this endpoint instead of the proxy network


This is a great idea, and we made this change in our docs.