Overview
A lot of the time your applications are made to be public and shared with the world. Sometimes you need to be more careful. When you deploy your apps on Fly.io, you get a private network for your organization. This lets your applications in other continents contact each other like they were in the same room. Sometimes you need a middle ground between fully public apps and fully private apps. Flycast addresses are private but global IPv6 addresses inside your private network that go through the Fly Proxy, so you get all of the load management and Machine waking powers that you get for free with public apps. This blueprint covers what Flycast is, when and why you’d want to use it, and shows you how to deploy a small private HTTP service that you can connect to over Flycast.What is Flycast?
Before we get started, let’s talk about Flycast and when you would want to use it. In general we can split every kind of Fly App into two categories: public apps and private apps. A public app is what you’d expose to the public Internet for your users. These are usually hardened apps that allow users to do some things, but have access limitations that prevent them from stepping outside their bounds. These are mostly programs that listen over HTTP for browsers to interact with. Your users connect to a public app through the platform router via the .fly.dev domain or whatever other domain you’ve set up. A private app is something internal, like a database server or a worker queue. These are things that run in the background and help you get things done, but are intentionally designed to NOT be exposed to the public Internet. You wouldn’t want to expose your Postgres or Valkey servers to anyone, would you? However, with a fully private app, all connections go directly to the Machines via their .internal addresses, so you have to keep them running 24/7 to maintain connectivity. This is fine for services like database engines where you want them to be running all the time, but what about an admin panel? You want your admin panel to be separate from your main app so that users can ever get into it, even by accident, but you also want it to shut down when it’s not in use. Flycast exists for this middle category of apps. With Flycast, your apps are only visible over your organization’s private network, but any traffic to them goes through the proxy so they can turn on when you need them and turn off when you don’t. This allows your administrative panels to be physically separate so that users can’t access them. When you want to connect to an app via Flycast, you connect toappname.flycast.
Security note
Just a heads-up. In general, it’s a bad idea to assume that network access barriers like Flycast or NAT are security layers. At best, this is an obfuscation layer that makes it more difficult for attackers to get into private applications. Flycast is not a replacement for authentication in your private applications. With Flycast, you don’t know who a request is coming from, but you do know that it’s coming from something or someone in your private network. One of the biggest platform features that uses Flycast out of the box is Managed Postgres. Even though Flycast addresses are local to your private network, Managed Postgres still configures usernames and passwords for your database.Goal
We’ll show Flycast off by deploying a small HTTP service that’s only reachable from inside your organization’s private network. The classic example is an internal admin panel: a service you and your apps need to reach, but that should never be exposed to the public internet. Flycast also lets the platform turn the service off when nobody’s using it, so you’re not paying to keep an idle admin panel running. For this walkthrough we’ll use the publicnginxdemos/hello image as a stand-in for any private HTTP service. It’s a tiny container that responds to HTTP requests with the server’s hostname and address, which makes it easy to confirm that traffic is reaching the right Machine over Flycast.
Prerequisites
To get started, you need to do the following:- sign up or sign in to Fly.io
- install flyctl (the Fly CLI)
Steps
Create a new folder on your computer calledflycast-demo and open a terminal in it. We don’t need any source code for this walkthrough. We’ll launch the app directly from a public Docker image with the --flycast flag, which tells Fly Launch to allocate a private IPv6 address instead of public ones. We’ll also pass --no-deploy so we can adjust one setting before the first deploy:
<appname>.flycast). When fly launch asks if you want to tweak the settings, you can accept the defaults.
The --internal-port 80 flag tells Fly Launch that our app listens on port 80 (the default for the nginxdemos/hello image). Fly Launch defaults to port 8080, so without this flag the Fly Proxy wouldn’t be able to reach the app. You could also set internal_port = 80 in fly.toml directly in the next step; the flag is just a shortcut so you don’t have to edit the file twice.
Open the generated fly.toml in your editor, find the [http_service] block, and change force_https to false:
force_https by default, which makes the proxy return a 301 redirect from HTTP to HTTPS. That’s a good default for public apps, but Flycast addresses don’t have public TLS certificates, so the redirect would just break plain HTTP requests from inside your private network.
Now deploy the app:
fly ips list:
fly machine run, giving it enough memory to install a few packages with apt:
flycast-demo. Let’s look up its .flycast address with nslookup flycast-demo.flycast:
time command to see how long the first request takes: