How do I sign up and deploy my first app on Fly.io from a Dockerfile?

If you’ve already got a Dockerfile, you’re about 10 minutes away from seeing your app running on Fly.io’s global platform. You’ll sign up, install the CLI, point Fly at your Dockerfile, and let Fly Machines do the rest—routing, regions, certificates, logs, the whole boring-but-critical stack.

Quick Answer: You sign up with GitHub, install flyctl, run fly launch in the directory with your Dockerfile to create a Fly app and config, then deploy with fly deploy. Fly.io builds your image, runs it on Fly Machines close to your users, and wires up networking automatically.

---

The Quick Overview

• What It Is: A pragmatic path to take any Dockerfile-backed app and get it running on Fly.io’s global Fly Machines platform with a couple of CLI commands.
• Who It Is For: Developers who already containerize their apps (Dockerfile in repo) and want low-latency, “serverless-feeling” deployments without adopting Kubernetes or writing Terraform.
• Core Problem Solved: Turning a local Docker image into a globally reachable, production-grade deployment with minimal configuration and no cluster surgery.

---

How It Works

At a high level, the flow looks like this:

1. Create a Fly.io account and authenticate flyctl.
2. Point flyctl at your project directory; it detects your Dockerfile and scaffolds a fly.toml.
3. Deploy; Fly.io builds your Docker image, schedules Machines in chosen regions, wires up Fly Proxy, and gives you an HTTPS endpoint.

Under the hood, Fly.io doesn’t run “mystery containers.” It runs Fly Machines: hardware-virtualized containers that launch fast enough to serve HTTP requests and can scale up and down to match demand. When you deploy from a Dockerfile, Fly.io either builds the image remotely or uses an existing image, then runs it on Machines pinned to regions you choose.

Step 1: Sign up for Fly.io

You have two main ways to sign up:

• With GitHub (recommended):

  1. Go to https://fly.io.
  2. Click Get Started.
  3. Sign in with GitHub and authorize Fly.io.

• With email (also fine):

  1. Go to https://fly.io/user/personal_access_tokens.
  2. Create an account and log in.

Either path gets you an account and access to Fly’s dashboard and API.

Step 2: Install the Fly CLI (flyctl)

flyctl is your main tool. Install it from your terminal.

macOS (Homebrew):

brew install flyctl

Linux (script):

curl -L https://fly.io/install.sh | sh
# You may need to add ~/.fly/bin to your PATH

Windows (PowerShell):

iwr https://fly.io/install.ps1 -useb | iex

Verify installation:

fly version

You should see a version string, not an error.

Step 3: Log in from the CLI

Authenticate flyctl with your Fly.io account:

fly auth login

This opens a browser window; confirm the login. If your environment is headless, you can use:

fly auth login --access-token <YOUR_FLY_API_TOKEN>

Your API token comes from https://fly.io/user/personal_access_tokens.

Step 4: Prepare Your App Directory and Dockerfile

Go to the directory that contains your app and its Dockerfile:

cd /path/to/your/app
ls
# Expect to see Dockerfile, source files, etc.

Constraints worth knowing up front:

• The Dockerfile must be named Dockerfile by default (or you’ll specify it manually).
• Your Dockerfile’s CMD or ENTRYPOINT should start the server process and bind to a port inside the container (commonly 8080).
• Don’t bind to 0.0.0.0:80 inside the Dockerfile because Fly Proxy maps external ports to your internal port. Inside the container, just listen on 0.0.0.0:<internal-port>.

Step 5: Launch a Fly App from Your Dockerfile

Now the fun part: turning a plain Dockerfile into a Fly app.

From your project directory:

fly launch

fly launch will:

• Detect your Dockerfile.
• Ask you for:
  • App name (must be globally unique on Fly.io).
  • Primary region (where Fly will place your first Machine, e.g. iad, lhr, syd).
• Generate a fly.toml configuration file.
• Optionally suggest a deployment right away.

When prompted:

• When it asks to tweak settings, answer y if you want to set region, org, etc.

• If you’re not ready to deploy yet, you can pass --no-deploy:

  fly launch --no-deploy
  

You should end up with a fly.toml in your repo:

cat fly.toml

Expect something like:

app = "your-app-name"

[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0

Key bits:

• app: your global app identifier.
• [build] dockerfile: points at your Dockerfile.
• [http_service] internal_port: container port your app listens on (adjust this if your app uses a different port).

Change internal_port if needed:

[http_service]
  internal_port = 3000
  ...

Then make sure your app listens on that port internally.

Step 6: Deploy Your App

Once fly.toml looks right, deploy:

fly deploy

What happens during fly deploy:

1. flyctl sends your app and Dockerfile to Fly’s remote builder (unless you’ve configured a registry).
2. Fly builds your Docker image.
3. Fly Machines are created/updated in your chosen region(s).
4. Fly Proxy starts routing traffic to your Machines.
5. Logs stream in the terminal as the Machines boot.

First deploy might take a minute or two depending on image size. Subsequent deploys are typically faster due to layer caching.

When it completes, you’ll see a URL like:

https://your-app-name.fly.dev

Open it in a browser or curl it:

curl https://your-app-name.fly.dev

You should see your app’s response. If not, check logs:

fly logs

Look for:

• Port mismatches (listening on 3000 but internal_port is 8080).
• Crashes due to missing environment variables.
• Startup commands failing.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Dockerfile-based deploys	Builds and runs your existing Dockerfile on Fly Machines.	No need to rewrite your app for a new runtime; reuse your current images.
Global Fly Machines platform	Runs hardware-virtualized containers in 18 regions, near your users.	Sub-100ms latency for users “from Sydney to São Paulo” without extra setup.
Scale-to-zero with auto-start	Stops idle Machines and restarts them on incoming requests.	Pay only for CPU and memory you actually use, billed by the second.

---

Ideal Use Cases

• Best for “I already have a Dockerfile, just run it”: Because fly launch detects the Dockerfile, generates fly.toml, and turns it into a Fly app without you touching Kubernetes, Helm, or Terraform.
• Best for low-latency APIs and web apps: Because Fly Machines run in regions you pick, behind Fly Proxy, with automatic TLS and regional placement, so you get global performance with minimal knobs.

---

Limitations & Considerations

• Stateful services need extra setup: Fly Machines can attach NVMe volumes or use managed Postgres (or object storage via Tigris), but that’s not auto-wired by fly launch. For databases or persistent storage, plan separate apps/volumes and follow the data-side docs.
• Not all Dockerfiles are created equal: Very large images, long-running compile steps, or weird init processes can slow deploys or cause startup issues. Keep images lean (multi-stage builds, minimal base images) and ensure the main process runs in the foreground.

---

Pricing & Plans

Fly.io pricing is usage-based: you pay for the CPU, RAM, storage, and traffic your Machines actually use, down to the second. Scale-to-zero means idle Machines can stop, so you’re not renting always-on instances just to keep a dev app alive.

The typical mental model:

• Hobby / Small Projects: Best for solo devs or small internal tools needing a few Machines, modest CPU/RAM, and occasional traffic. Good for prototypes, personal APIs, and side projects.
• Team / Production Workloads: Best for teams needing multiple apps, higher capacity, and reliability features like Single Sign-On, guaranteed support response times, and SOC2 Type 2–aligned operations.

For current numbers and tiers, check https://fly.io/docs/about/pricing/.

---

Frequently Asked Questions

Do I have to use GitHub or can I deploy purely from a Dockerfile?

Short Answer: You can deploy purely from a Dockerfile on your local machine; GitHub is optional.

Details: flyctl doesn’t require a GitHub repo to deploy. It only needs a directory containing a Dockerfile and your source. Running:

fly launch
fly deploy

from that directory is enough. If you want CI/CD from GitHub later, you can add a workflow that runs flyctl deploy using a FLY_API_TOKEN secret. But the core “sign up and deploy from a Dockerfile” flow works from any local directory, Git-backed or not.

---

Can I use an existing Docker image instead of building from my Dockerfile?

Short Answer: Yes. Point fly.toml at your image instead of a Dockerfile.

Details: If you already push your image to a registry (Docker Hub, GHCR, etc.), you can skip remote builds. In fly.toml, use:

[build]
  image = "ghcr.io/your-org/your-image:tag"

Then run:

fly deploy --ha=false

(or just fly deploy). Fly.io will pull that image into your Fly Machines instead of rebuilding it. You still configure internal_port, regions, and services in fly.toml.

---

Summary

Signing up and deploying your first app on Fly.io from a Dockerfile is intentionally boring—in the good way. You:

1. Sign up and install flyctl.
2. Run fly launch in your app directory to generate fly.toml.
3. Run fly deploy to build your image and boot Fly Machines in your chosen region.
4. Hit the https://your-app-name.fly.dev URL and watch your container live on the edge.

No Kubernetes clusters to nurture, no hand-rolled load balancers, and you still get low-latency, globally distributed compute with clean primitives you can reason about.

---

Next Step

Get your Dockerfile-powered app running on Fly Machines in a few minutes: fly launch in your project directory, edit fly.toml if needed, then fly deploy when you’re happy.

Get Started