My app is idle most of the day—how can I make it “sleep” when unused but still wake up fast when traffic comes back?

Most apps don’t need a full-time fleet of Machines burning CPU 24/7. If your app is idle most of the day, you want it to “sleep” when nothing’s happening and wake up fast when traffic returns—without duct-taping your own scheduler on top. On Fly.io, that pattern is built into the platform: you combine Fly Proxy’s autostop/autostart with sensible region placement and (optionally) a metrics-based autoscaler.

Quick Answer: Use Fly Proxy’s autostop/autostart to scale your Machines to zero when idle, and configure autoscaling (via fly scale or fly-autoscaler) so a small pool of Machines can wake up quickly and handle the first burst of traffic, all while you pay only for CPU and memory while they’re actually running.

The Quick Overview

• What It Is: A way to run your app on Fly Machines that automatically shut down when idle and spin back up on demand, so you pay for usage instead of 24/7 uptime.
• Who It Is For: Teams with web apps, APIs, agents, or cron-style workers that sit idle for large chunks of the day but still need snappy response times when users show up.
• Core Problem Solved: You avoid paying for always-on capacity and skip Kubernetes/Terraform gymnastics, while still getting fast cold-start behavior and global low latency.

How It Works

At a high level, Fly Proxy sits in front of your app. It sees incoming traffic, decides which Machines to send it to, and can also decide when to stop Machines that have been idle. When the next request arrives, Fly Proxy can automatically start a stopped Machine in that app and region, then route the request to it.

Think of it as “lazy-loading” your compute: Machines start when traffic shows up and stop when it disappears.

The mechanics:

1. Autostop (sleep when idle):
   You tell Fly Proxy to stop Machines after they’ve been idle for a configurable period. No traffic, no process, no CPU bill.

2. Autostart (wake on request):
   When Fly Proxy sees a new request for an app with stopped Machines, it starts one (or more) Machines and holds the connection until the Machine is ready to serve. Machines are fast enough to start in time to handle HTTP requests.

3. Autoscale & warm capacity (stay responsive):
   If your traffic isn’t just “one lonely request an hour,” you can keep a small number of Machines hot, or let fly-autoscaler adjust counts based on metrics. That gives you fast responses even during bursts, without a giant pool of always-on Machines.

---

How It Works, Step by Step

1. Configure your app to use autostop/autostart

In your fly.toml, your app’s services are what Fly Proxy talks to. To enable automatic sleep/wake behavior, you configure autostop/autostart at the Machine level. The easiest way today is via flyctl when you create or update Machines.

A typical setup:

fly machines update <MACHINE_ID> \
  --autostop=5m \
  --autostart=true

• --autostop=5m tells Fly to stop the Machine after 5 minutes of no incoming traffic.
• --autostart=true tells Fly Proxy it can start this Machine automatically when new traffic arrives.

You can apply this to all Machines in an app with a small script, or by defining your app as a Machines app and letting fly deploy manage them. The result: Machines quietly power down when idle.

2. Make sure your app actually can sleep

One classic footgun: background work and long-lived connections that never go idle. If something is constantly poking your app, the Machine looks “busy” and never autostops.

Check for:

• Persistent DB connections from another app that doesn’t scale to zero.
  If your app talks to a database, make sure that app either:
  • Also scales to zero, or
  • Uses connection pooling and allows the app Machines to fully idle.
• Health checks hitting too often.
  Don’t point an external health checker at your app every 10 seconds unless you like paying for insomnia.
• Cron-style jobs running inside the web process.
  Move those to dedicated Machines or use Fly Cron Manager, so your web Machines can sleep.

Rule of thumb: if nothing is sending HTTP or TCP traffic through Fly Proxy, your Machine should be eligible to stop.

3. Handle cold starts sanely

Machines start fast enough to catch HTTP requests, but “fast enough” depends on what your app does on boot:

• Put big assets and models on a Fly Volume, not inside the image.
  That way, a restart doesn’t mean re-downloading or unpacking a multi-GB root filesystem. Mount a volume for large models or static blobs instead of baking them into the image.

• Keep startup paths lean.
  Avoid doing expensive migrations or multi-API fanout in your app’s boot path. Do that work in a dedicated migration Machine or one-off job.

• Test cold start time.
  From your laptop:

  fly scale count 0
  fly scale count 1
  

  Then hit your HTTP endpoint and see how long the first response takes. That’s your worst-case “wake up” latency.

If a single cold-start hit is fine for your use case—say, admin dashboards or internal tools—you may be done. If you’re latency-sensitive, keep reading.

4. Keep a small pool of Machines hot

For apps where first-request latency really matters, you probably don’t want all Machines asleep all the time. Instead, keep a tiny pool running—maybe 1 per active region—and let the rest scale to zero.

There are two common approaches:

Option A: Static minimum with per-region counts

Use fly scale to keep a fixed count per region and combine that with autostop:

# Example: keep 1 Machine in iad, allow others to scale via autostart
fly scale count 1 --region iad

Then configure additional Machines (for other regions or background work) with autostop/autostart. This is the “it works, okay?” tier: simple, predictable, no extra components.

Option B: fly-autoscaler + autostop/autostart (more robust)

If your traffic swings a lot and you don’t want a pile of idle Machines hanging around, you can deploy the fly-autoscaler app. It:

• Watches metrics for your app (CPU, concurrency, etc.).
• Adjusts the count of Machines per region based on rules you set.
• Plays nicely with autostop/autostart so you can keep a small fleet ready without wasting resources.

High-level flow:

1. Deploy fly-autoscaler as its own Fly app.
2. Configure it with your target app, thresholds, and min/max Machine counts.
3. Combine that with --autostop/--autostart on the Machines themselves.

This setup is ideal when traffic looks like “busy mornings, dead afternoons” and you don’t want to pay for a lunchtime army of stopped Machines.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Fly Proxy autostop/autostart	Automatically stops idle Machines and restarts them when traffic arrives.	Cut costs by scaling to zero while still waking on demand.
Fast-start Fly Machines	Boots hardware-virtualized containers quickly enough to serve HTTP.	Keeps cold-start latency low without complex warmup logic.
Metrics-based autoscaling	Uses fly-autoscaler + platform metrics to adjust Machine counts.	Matches capacity to real traffic instead of guessing.

---

Ideal Use Cases

• Best for bursty web apps and APIs:
  Because autostop/autostart lets you scale to zero during quiet hours, and a small pool of hot Machines plus fast starts keeps your p95 latency under control when traffic spikes.

• Best for agents, job runners, and review apps:
  Because each job or preview environment can get its own Machine, run, and then fully stop—no noisy neighbors, and you pay only for the seconds of CPU and RAM you actually burned.

---

Limitations & Considerations

• Cold-start latency still exists:
  A Machine can start quickly, but if you load a 10GB model on initialization or run complex migrations on boot, your “wake up” time will be slow. Offload heavy boot work, use volumes, and test cold-start behavior.

• Long-lived connections prevent sleep:
  If another service (or your own health checker) is constantly pinging the app, Machines won’t go idle and autostop won’t kick in. Make sure DB clients, polling loops, and uptime monitors are configured with this in mind.

---

Pricing & Plans

Fly.io billing is tied to actual resource usage:

• Compute: You pay for CPU and memory while a Machine is running, billed to the second. When autostop shuts the Machine down, compute billing stops.
• Storage: Volumes (NVMe) and object storage (Tigris) are billed separately, and continue to exist while your app “sleeps.” That’s what lets you keep large assets and state without paying for compute.

Most teams pair:

• A small always-on footprint (1–2 Machines in key regions), plus

• A large “elastic” layer of Machines that exist, but spend most of their time stopped and are started by Fly Proxy when needed.

• Lean / side-project setup: Best for solo devs or small teams running low-traffic apps that can tolerate occasional cold-start latency. Use autostop/autostart everywhere and a minimal number of Machines per region.

• Production / spiky-traffic setup: Best for teams with real SLAs and bursty workloads. Keep a small hot pool per region, use fly-autoscaler to add/remove Machines based on load, and rely on autostop to keep off-peak costs down.

(For exact pricing numbers, check the current tables on https://fly.io; they change more often than this article.)

---

Frequently Asked Questions

Will my users notice when the app “wakes up”?

Short Answer: Some might see a slower first request if all Machines are asleep, but you can largely hide this with one or two always-on Machines per region.

Details:
When a request hits an app with only stopped Machines, Fly Proxy has to:

1. Start a Machine.
2. Wait for it to be ready.
3. Forward the request.

If your app boots quickly and doesn’t do heavy work on startup, this might add a few hundred milliseconds. If you care about a crisp first response:

• Keep min_machines > 0 in busy regions using fly scale count.
• Move expensive initialization (migrations, huge model loads) out of the request path.
• Pre-warm Machines before a known busy period (e.g., daily batch window).

You can verify real behavior with synthetic checks: stop your Machines, hit the app, and measure. That’s your worst-case user experience.

What about my database—can it sleep too?

Short Answer: Yes, but you have to coordinate. If your app keeps a connection open to a DB that never scales to zero, the app Machine will never go idle.

Details:
The platform can scale both apps and databases, but it’s not magic: if any long-lived connection remains open through Fly Proxy, the Machine counts as “active.”

You have a few options:

• Use a Fly Postgres cluster where replicas can scale and your app uses pooled, short-lived connections.
• Allow the database to stay always-on, but make sure your app closes idle connections and doesn’t ping it on a tight loop.
• For lower-complexity setups, accept that the DB stays awake and focus on scaling the stateless parts (web/API) to zero.

The key is: if you want Machines to sleep, don’t attach anything to them that insists on talking every few seconds.

---

Summary

If your app is idle most of the day, you don’t need a 24/7 server bill. On Fly.io, you can let your app “sleep” by enabling autostop/autostart on Fly Machines so they shut down when idle and spin back up automatically on incoming traffic. Combine that with lean startup paths, volumes for heavy data, and—when needed—metrics-based autoscaling to keep a small pool hot, and you get a nice balance: low cost during quiet hours, responsive behavior when traffic returns, and none of the Kubernetes maintenance.

Next Step

Get Started](https://sprites.dev/)