Deployment strategy on fly.io

Found this interesting.

I was used to similar services that used a single file named docker-compose.yaml to set up multiple services (I built a free Docker Compose generator if you need to write one of those).

On Fly.io, independently deployed services are usually separate Fly Apps. Each app has its own fly.toml, image or Dockerfile, Machines, secrets, and deployment lifecycle.

Also see my Docker tutorials.

Apps in the same organization can communicate over Fly.io’s private IPv6 network, called 6PN. The DNS name for an app is:

my-app.internal

The name resolves to the private addresses of the app’s started Machines. Connect to the port where the service listens:

http://my-app.internal:8080

For direct 6PN connections, the service must listen on its private address, available as fly-local-6pn, rather than only on 127.0.0.1.

The raw .internal address bypasses Fly Proxy. If you need proxy features such as load balancing and autostart/autostop for a private service, use Flycast instead.

One Fly App can also run multiple process groups from the same image. Use separate apps when services need independent code, configuration, scaling, secrets, or deployments; use process groups when they are parts of the same release.