Fly.io pricing: what will a small app cost per month if it’s mostly idle?

Most Fly.io pricing questions from small teams boil down to one thing: “If my app is mostly idle, what do I actually pay every month?” The short version: you can keep a real, production-capable app online for a few dollars a month if it doesn’t see much traffic, and you only start paying “real money” when you keep CPUs hot or storage heavy.

This explainer walks through realistic cost scenarios for a small, mostly-idle app on Fly.io, including what changes if you scale-to-zero, use Postgres, or add object storage.

---

The quick overview

• What it is: Fly.io is a developer cloud where you run apps on Fly Machines—hardware-virtualized containers that start fast, bill by the second, and can scale down to zero.
• Who it is for: Developers and small teams who want global, low-latency apps and safe sandboxes (Sprites) without living inside Kubernetes or Terraform.
• Core pricing idea: You pay for the CPU, RAM, and storage your Machines (and databases) actually consume, plus bandwidth. If your app is idle most of the time, your bill is dominated by baseline memory + storage, and it’s usually small.

---

How Fly.io pricing works for a small, mostly-idle app

Under the hood, everything compute-related is a Machine. You pick:

• A CPU / RAM size (e.g., shared-cpu-1x with 256MB RAM)
• Whether it can scale to zero (auto-stop when idle, auto-start on traffic)
• Optional storage (local NVMe for stateful apps, managed Postgres, and/or Tigris object storage)
• Data transfer out to the internet

Then billing is:

• Per-second for Machines while they’re running
• Per-GB-month for storage (NVMe, Postgres volume, Tigris objects)
• Per-GB for outbound bandwidth

If you design your app to spend most of its time not doing work—low traffic, scale-to-zero where possible—you pay mostly for storage and a thin layer of memory.

The basic pricing levers

1. Compute size
   Choose a tiny Machine for a small app. “Shared CPU + 256–512MB RAM” is enough for many toy APIs, low-traffic SaaS MVPs, and small dashboards.

2. Scale-to-zero vs always-on

   • Always-on Machine: You pay 24/7 for RAM + CPU, even while idle. Nice for low-latency and background jobs.
   • Scale-to-zero Machine: Fly Proxy stops it when idle and restarts on demand. You pay only when it’s running (plus any storage).

3. Database / state

   • Managed Postgres: You’re paying for a dedicated VM with storage, 24/7.
   • SQLite + volume: Cheaper baseline, runs inside your app’s Machine using NVMe.
   • Tigris (object storage): S3-compatible; you pay per GB stored + bandwidth, usually pennies for small apps.

4. Traffic pattern
   Idle 99% of the time? Your CPU bill is tiny with scale-to-zero.
   Heavy bursts all day? CPU dominates, but that’s not “mostly idle” anymore.

---

Example: “Mostly idle” cost scenarios

These are back-of-the-napkin estimates so you can reason about your own usage. The exact numbers depend on current Fly.io prices, but the shape is accurate.

Scenario 1: Small always-on app, no database

Profile:

• 1 Machine, shared-cpu-1x, 256MB RAM
• Runs 24/7 in one region (e.g., iad)
• Low traffic (personal site, status page, tiny webhook service)
• No Postgres, no persistent NVMe volume
• A few GB/month of outbound data (logs, API responses, etc.)

Cost drivers:

• Compute (always-on): A 256MB shared CPU Machine running all month
• Bandwidth: Probably in the free tier or a couple of dollars

Rough monthly cost:

• Typically in the $2–$7/month range, depending on exact size and outbound bandwidth.
  This is the “just keep my little service up” budget.

Good choice if:

• You want instant responses, no cold starts
• You don’t want to think about scaling at all
• “Five bucks a month to never think about it” is fine

---

Scenario 2: Small HTTP API that scales to zero

Profile:

• 1 Machine, shared-cpu-1x, 256–512MB RAM
• Auto-stop after idle, auto-start when requests arrive
• Occasional traffic: a dashboard you open a few times a day, or webhook receiver that gets a handful of events per hour
• No database, or uses external service (e.g., external SaaS DB)

Cost drivers:

• Compute (scale-to-zero):
  • Only billed while the Machine is running
  • If total “active time” is an hour or two per day, you only pay for those hours
• Bandwidth: Typically minimal for small APIs

Rough monthly cost:

• Often under $2/month, sometimes close to $0.50–$1 if the app is truly idle most of the day and memory size is small.

Tradeoffs:

• First request after idle triggers a cold start (still fast, but not zero)
• Background jobs don’t run when the Machine is stopped (you’d want Cron Manager with per-job Machines for that)

Best for:

• Internal tools you rarely visit
• Personal APIs
• “I want it live, but not paying rent for silence”

---

Scenario 3: Small app + managed Postgres

This is where costs become more “real,” because databases don’t scale to zero yet—they’re actual VMs that stay on.

Profile:

• App Machine: shared-cpu-1x, 256–512MB RAM
• Fly Postgres: small cluster (single-node starter)
• Light traffic, but the DB is always on
• A few GB of data in the database

Cost drivers:

• App Machine:
  • Always-on: a few bucks/month
  • Or scale-to-zero: very low compute cost, but…
• Postgres cluster:
  • Base cost for the VM + storage 24/7, even if the app is idle
  • This is usually the main line item
• Storage:
  • DB volume (tens of GB or less for small apps is cheap)
• Bandwidth:
  • Mostly internal (private WireGuard network), which is free
  • Public egress (your HTTP responses) is small

Rough monthly cost:

• Expect a floor around $10–$20/month for “app + small managed Postgres” assuming the smallest practical sizes, plus whatever egress you push.

This is a fair deal if:

• You want Fly-managed backups and operational care for your DB
• You’d rather not run and patch Postgres yourself
• The app is small but real: side-project SaaS, small customer-facing tool, etc.

If you’re price-sensitive and can accept more DIY, you can:

• Run SQLite on NVMe inside your app Machines
• Or run your own Postgres Machine and micromanage it

---

Scenario 4: Mostly idle, but storing data in Tigris

If your app doesn’t need a relational database, or uses it minimally, you can lean on Tigris object storage for dirt-cheap data.

Profile:

• App Machine: scale-to-zero or small always-on
• Tigris bucket for blobs (user uploads, model weights, JSON blobs, etc.)
• Light reads/writes per day

Cost drivers:

• App Machine compute:
  • Same as Scenario 1 or 2
• Tigris storage:
  • Per GB per month, very low cost
  • You can store hundreds of gigabytes of data cost-effectively
• Tigris bandwidth:
  • You pay for egress when you serve that data out of the platform

Rough monthly cost:

• Tiny app + a few GB in Tigris: still in the $3–$10/month zone unless you’re pushing lots of bandwidth.
• The main way to raise the bill here is large public downloads or huge data sets.

This setup is perfect if:

• You want S3-like storage without wiring in another provider
• Your app is mostly static/JSON content with occasional writes
• You want to keep compute spend tiny but store lots of stuff

---

What actually happens to an “idle” Machine?

The main pricing question: does idle time cost me?

Always-on Machines

• A Machine that’s “up” but doing nothing still costs you, because RAM is reserved and CPU is available.
• You pay per-second for the full uptime.
• For the smallest sizes, that idle cost is measured in low single-digit dollars per month.

Useful when:

• Latency matters more than pennies
• You have long-lived connections or background workers

Scale-to-zero Machines

• Fly Proxy watches traffic and idleness.
• When a Machine is idle long enough (no connections, no requests), it’s stopped.
• You stop paying for CPU + RAM for that Machine until it’s started again.
• Storage (volumes, Postgres disks, Tigris) is still billed while Machines are stopped.

This is where a “mostly idle” app explodes with savings. If you only wake up the app a few minutes each day, compute spend becomes negligible.

---

Cost knobs you control from day one

Here’s how to keep your small-app bill predictable and low.

1. Pick a modest Machine size

You don’t need a VM the size of a small moon.

For small apps:

fly launch --vm-size shared-cpu-1x --memory 256

If you see OOMs or performance issues, bump memory to 512MB. Machines are flexible; you can change size later.

2. Use scale-to-zero for low-traffic HTTP apps

Configure autoscaling in fly.toml for Machines that handle synchronous HTTP:

[http_service]
  internal_port = 8080
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 0
  max_machines_running = 1

• min_machines_running = 0 lets your app scale to zero when idle.
• First request after idle might wait for the Machine to spin up (still fast, but noticeable if you’re watching).

3. Separate “always-on” from “per-job” work

If you have scheduled jobs or heavy background tasks, don’t make your main web Machine sit around waiting.

Use Cron Manager or GitHub Actions to spin up one-off Machines per job. Then you pay by the second for exactly how long the job runs, and they shut down when finished.

That keeps your always-on footprint tiny (or zero).

4. Be intentional about databases

Relational databases are the biggest jump from “hobby pricing” to “real infra.”

Options, ranked from cheapest to most “please just handle this”:

1. SQLite in NVMe volume (cheapest, most DIY)

   • Great for single-region, small apps
   • You manage backups/snapshots, but cost stays close to “just app Machine + volume”

2. Self-managed Postgres Machine (cheap if you babysit it)

   • You run Postgres on a Machine you control
   • You manage HA, upgrades, backups

3. Fly Postgres (more expensive base, least friction)

   • Managed config, upgrades, backup patterns
   • Your bill is dominated by the DB, not the app Machines

If you’re truly cost-sensitive and mostly “toy plus learning,” start with SQLite + volume and move up when you hit real constraints.

---

Quick sanity checks for “what will my app cost?”

Answer these to get a decent estimate:

1. How many Machines are running 24/7, and with what size?

   • If the answer is “one tiny Machine” → think in the $2–$7 range
   • If it’s “none, they all scale to zero” → compute is going to be very cheap

2. Do I have a managed database (Fly Postgres)?

   • Yes → expect at least $10–$20/month baseline
   • No → you’re probably in small side-project territory

3. How much data do I store?

   • Under 10GB across volumes + Tigris → storage isn’t moving the needle
   • Hundreds of GB → storage might matter, but Tigris is built to make that cost-effective

4. Am I pushing serious outbound traffic?

   • Static sites with a few thousand pageviews → mostly in free/cheap egress
   • Video, large binary downloads, or AI model streaming → bandwidth can dominate

If you’re still unsure, deploy the app, let it run for a week, and watch usage in the Fly dashboard. Billing is transparent down to Machines, volumes, and bandwidth, so you can see exactly what’s doing damage.

---

Limitations & considerations to keep in mind

• Databases don’t scale to zero (yet):
  Managed Postgres is always on. That’s good for latency and reliability, but it sets a minimum monthly cost.

• Cold starts exist:
  Scale-to-zero Machines restart on demand. They’re quick, but not instant. For user-facing apps where the first request must be snappy, keep at least one Machine warm.

• Per-region duplication:
  If you deploy in multiple regions, you’re paying for Machines in each one. Global low latency is awesome, but it’s not free.

• Background work vs idle:
  If you’re running cron-like tasks inside your main Machine, it’s never truly idle. Move scheduled jobs to isolated Machines if you want your web app to scale to zero.

---

Summary: what a mostly idle app actually costs

For the URL slug you’re thinking about—“fly-io-pricing-what-will-a-small-app-cost-per-month-if-it-s-mostly-idle”—the realistic answer looks like this:

• Static or lightweight HTTP app, no managed DB, scale-to-zero:
  Often under $2/month, sometimes close to $1 for truly infrequent use.

• Small always-on app, one tiny Machine, light traffic:
  Typically in the $2–$7/month zone.

• Small app plus Fly-managed Postgres:
  Baseline around $10–$20/month, dominated by the database, not the app.

The big levers are: Machine size, always-on vs scale-to-zero, and whether you’re paying for a full-time database. For a small, mostly idle app, you can absolutely live in “coffee money” territory—especially if you lean on scale-to-zero, SQLite or Tigris, and keep Machines small.

---

Next step

If you want to see a real number instead of back-of-the-napkin math, deploy your app on Fly.io, enable scale-to-zero where it makes sense, and watch the usage graphs over a week. You’ll get a concrete, workload-specific answer instead of guessing.

Next Step

Get Started