Deploying on Fly.io

Fly.io runs your app in Firecracker microVMs — real virtual machines, not shared serverless sandboxes — in datacenters you choose. You get containers with global placement and a CLI that feels like Docker met Terraform.

If Railway is “Heroku reborn”, Fly is “what if I wanted a tiny VM in Tokyo and another in Frankfurt without hiring a platform team?”

Fly Machines

A Machine is one VM running one image of your app. You can run multiple Machines per app for redundancy and scale.

Machines boot fast. Fly can stop them when idle and start them on traffic. That is scale-to-zero — you pay for compute only when the Machine runs.

Your app ships as an OCI image. Fly builds from a Dockerfile or a buildpack. The same container runs locally and in production.

Example — launch an app from the current directory:

fly launch

Fly detects your stack, generates fly.toml, builds the image, and picks a default region. You get a *.fly.dev URL.

Regions

Fly lets you pin Machines to regions — three-letter codes like iad (Virginia), ams (Amsterdam), nrt (Tokyo).

Multi-region is a first-class story. Run two Machines in iad and one in lhr for UK users. Fly’s Anycast network routes requests to the nearest healthy Machine.

You pay for running Machines. More regions means more copies unless you use autoscaling rules carefully.

My advice: start in one region near your users. Add regions when latency data says you need them, not because the map looks cool.

fly.toml

fly.toml is your app’s config file. It lives in the repo.

Typical pieces:

app = "my-api"
primary_region = "iad"

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

auto_stop_machines and auto_start_machines enable scale-to-zero for HTTP services. min_machines_running = 0 means no idle bill when traffic is zero.

You also declare env vars, mounts for persistent volumes, and process groups if one repo runs web plus worker processes.

Deploy changes with:

fly deploy

Fly Postgres

Fly Postgres is Postgres running on Fly Machines — managed by Fly, but still Postgres you can connect to with any client.

It is not Aurora. You choose region, size, and replica count. Backups and failover exist, but you should read Fly’s docs on HA expectations for your tier.

For many indie apps, Fly Postgres plus an app Machine in the same region is enough. Low latency, one vendor, one invoice.

You can also attach external Postgres — Supabase, Neon, RDS — if you prefer a specialist database host.

Scale-to-zero

Scale-to-zero is Fly’s answer to “why am I paying for a server that gets ten requests a day?”

When traffic stops, Machines stop. The first request after idle triggers a cold start — usually a few hundred milliseconds to a couple seconds depending on image size.

Good for:

• Side projects
• Internal tools
• APIs with quiet nights

Bad for:

• WebSockets that must stay connected
• Strict latency SLAs on the first request after idle
• Apps that cannot tolerate occasional cold starts

Configure autoscaling in fly.toml and watch the Fly dashboard for Machine state.

When Fly.io fits

Pick Fly when:

• You want containers and region control without managing raw VPSes
• Global users need low latency and you can replicate Machines
• Scale-to-zero keeps side projects cheap
• You outgrew serverless but do not want a full Kubernetes cluster

StackPlan recommends Fly for APIs, small SaaS backends, and apps that need a persistent process near users in Europe or Asia.

When to skip it

Use a VPS or Railway when:

• You want the cheapest always-on box and will tune it yourself
• Fly’s pricing math at steady 24/7 load beats your budget
• You need managed Postgres with less ops thinking than Fly Postgres

Fly rewards teams comfortable reading fly.toml and watching Machine counts. The payoff is flexible, geographically aware compute without AWS-shaped complexity.

Once you know that model fits, the real task is sizing Machines and regions against your traffic — not copying someone else’s fly.toml and hoping.