Network Services

Fly's Network Services

Fly has public and private network services available. The public network services connect applications to the wider public internet, while the private network services allow application instances to communicate with other application instances within the Fly private network.

Public Network Services

IP addresses

Fly applications have dedicated IP addresses. Each application starts with two addresses — one IPv6 and one IPv4. IPv6 addresses are free, global IPv4 addresses are billed monthly.

Anycast

We announce global IP blocks from all of our datacenters over BGP, otherwise known as anycast. Anycast is a core internet routing mechanism that connects clients to the "nearest" server advertising a block of IPs. You can read all about it on Wikipedia.

Connection handlers

The handlers config setting specifies which middleware applies to incoming TCP connections. Use these to convert TCP connections into something your application can handle.

TLS

The TLS middleware terminates TLS using Fly managed application certificates, then forwards a plaintext connection to the application process. This is useful for running TCP services and offloading TLS to the Fly proxy.

For performance purposes, the Fly proxy will terminate TLS on the host a client connects to, and then forward the connection to the nearest available application instance.

Note: the TLS handler includes ALPN negotiation for HTTP/2. When possible, applications will connect to these kinds of Fly services using HTTP/2, and we will forward an unencrypted HTTP/2 connection (h2c) to the application process.

HTTP

Many applications have limited HTTP support, the HTTP middleware normalizes HTTP connections and sends HTTP 1.1 requests to the application process. This is roughly how nginx and other reverse proxies work, and allows your application to globally accept modern HTTP protocols (like HTTP/2) without extra complexity.

If your application stack has good HTTP/2 support (like Go), you will get better performance accepting TCP connections directly, and using the TLS handler to terminate SSL. Your application does need to understand h2c for this to work, however.

The HTTP handler adds a number of standard HTTP headers to requests, and a few Fly specific headers for convenience:

TCP pass through

If you don't specify handlers, we just forward TCP to your application as is. This is useful if you want to handle TLS termination yourself, for example.

Proxy protocol

The proxy_proto handler adds information about the original connection, including client IP + port and server IP + port (from the client's perspective). Most applications need additional logic to accept the proxy protocol, either using a prebuilt library or implementing the proxy protocol directly.

Private Network Services

As well as the connectivity with the wider internet, Fly also supports private networking in the form of the 6PN private networking option and the Wireguard option.

6PN Private Networking

The 6PN Private Networking option allows Fly instances to communicate with each other over Fly's private network. For example, this can allow a customer-facing web application to talk to an application backend and database.

Each instance in an organization's applications now gets an additional IPV6 address, fly-local-6pn, within Fly's private network. Applications that bind their listeners to this address will only be reachable by apps within the organization.

With this new IPV6 address also comes the ability to look up a new name resolver at address fdaa::3 which can not only resolve external addresses (using 8.8.8.8) but can also resolve .internal addresses. This name resolver is automatically added to any application's 'resolv.conf' file giving it the ability to look up other app instances within the organization.

.internal addresses

A typical .internal address is composed of a region qualifier, followed by the app name followed by .internal.

The simplest regional qualifier is a region name. iad.appname.internal will return IPv6 internal address (or addresses) of the instances of app appname in the iad region. This form of .internal address can be used in applications that look up the address of a host. Rather than returning a list of addresses, it will return the first address.

The regional qualifier global will return the IPv6 internal addresses for all instances of the app in every region.

As well, as being able to query and lookup addresses, there's a TXT record associated with regions.appname.internal which will list the regions that appname is deployed in.

Finally, You can discover all the apps in the organization by requesting the TXT records associated with _apps.internal. This will contain a comma-separated list of the application names.

Examples of retrieving this information are in the fly-examples/privatenet repository.