How can I stop paying for staging/preview environments when nobody is using them?

Most teams don’t mind paying for staging and preview environments—right up until a quiet weekend invoice lands and you realize you’ve been keeping dozens of idle services happily burning money. The good news: you can keep all the benefits of rich staging/preview setups and only pay when someone is actually hitting them.

Quick Answer: Use Fly Machines with autostop/autostart and metric-based autoscaling so staging and preview environments scale to zero when idle, then spin up on-demand in under a second when a request comes in. You get full-stack, production-like environments without the always-on price tag.

The Quick Overview

• What It Is: A way to run staging and preview environments on Fly.io so they shut down automatically when nobody is using them and start again automatically on the next request.
• Who It Is For: Engineering teams with multiple services, feature branches, or AI agents that need realistic environments (databases, queues, APIs) but don’t want to pay for 24/7 capacity.
• Core Problem Solved: Staging/preview environments sit idle most of the time, yet traditional cloud setups bill them like production. This approach makes them behave like “serverless VMs” that only cost you when they’re doing work.

How It Works

On Fly.io, everything runs on Fly Machines: hardware-virtualized containers that can start in under a second and bill you only for CPU and memory while they’re running. Autostop/autostart and metric-based autoscaling sit on top of that:

• Autostop shuts down Machines after an idle timeout (no connections, no requests).
• Autostart lets Fly Proxy start those Machines again when a new request comes in.
• Autoscaling (via the fly-autoscaler app) controls how many Machines you keep “ready to wake up” in each region so you don’t pay for a pile of parked capacity.

Put together, your staging and preview environments run like this:

1. Deploy staging/preview to Machines
   Each environment (staging or per-PR preview) is one or more Machines, ideally with their own app on Fly. They look and behave like production, but you tell them they’re allowed to sleep.

2. Enable autostop/autostart
   You annotate the services in fly.toml so Fly Proxy can stop Machines after they’re idle and automatically start them when traffic returns. No requests = no running Machines = no compute cost.

3. Add autoscaling for “warm” capacity (optional but smart)
   For bigger teams or highly shared staging, you run the fly-autoscaler app. It watches metrics and keeps a small, configurable pool of Machines per region ready to start instantly when Fly Proxy sees traffic. You get fast responses without paying for a full cluster.

1. Deploy staging/preview to Machines

Typical pattern:

• Production app: myapp
• Staging app: myapp-staging
• Per-PR previews: myapp-pr-123, myapp-pr-124, etc., created via CI.

Create a staging app:

fly apps create myapp-staging
fly launch --name myapp-staging --copy-config --no-deploy

Then deploy:

fly deploy --app myapp-staging

For preview environments, your CI can do something like:

APP_NAME="myapp-pr-${PR_NUMBER}"
fly apps create "$APP_NAME" || true
fly deploy --app "$APP_NAME" --remote-only

Each preview app gets its own Machines, logs, secrets, private networking, and optional database.

2. Enable autostop/autostart

In fly.toml for staging/preview, configure your service:

[services]
  [[services.ports]]
    handlers = ["http"]
    port = 80

  [services.concurrency]
    type = "connections"
    hard_limit = 25
    soft_limit = 20

  [vm]
    memory = "512mb"
    cpu_kind = "shared"
    cpus = 1

[auto_stop]
  enabled = true
  delay = "15m"

[auto_start]
  enabled = true

Key pieces:

• auto_stop.enabled = true shuts Machines down after delay of no traffic.
• auto_start.enabled = true lets Fly Proxy wake them up on incoming requests.

Behavior:

• Engineers hit staging.myapp.com during business hours. Machines run, scale, and behave like normal.
• After 15 minutes of silence, Machines stop. Billing for CPU and RAM stops too.
• Next morning, first HTTP request hits Fly Proxy. Machines autostart in under a second and serve the request.

For most staging/preview setups, this alone cuts costs dramatically.

3. Add autoscaling for “warm” capacity

If staging is frequently hit by multiple teams and slow first-hit latency is annoying, you can keep a fixed pool of Machines per region “parked but ready” using the fly-autoscaler app.

High-level:

• fly-autoscaler watches metrics (like concurrent connections or queue depth).
• It ensures a small number of stopped Machines are always available to autostart instantly.
• You avoid both “oops, nothing is ready” and “oops, we kept 20 idle Machines all weekend.”

You:

1. Deploy fly-autoscaler once:

   fly launch --name myapp-autoscaler
   fly deploy --app myapp-autoscaler
   

2. Configure it to manage your staging/preview app:

   • Point it at myapp-staging.
   • Set desired min/max counts per region (e.g., 1 warm Machine in iad, 1 in lhr).

Now Fly Proxy + fly-autoscaler combine to:

• Let Machines stop when idle.
• Keep just enough capacity “near-warm” to handle real-world usage.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Autostop/Autostart for Machines	Stops Machines after a configurable idle timeout and restarts them when requests arrive.	You stop paying for staging/preview compute when nobody is using it, with automatic wake-up when traffic returns.
Per-Environment Apps on Fly	Lets you give each staging or preview environment its own Fly app and Machines.	Clean isolation per branch/feature with separate logs, secrets, and private networks—no noisy neighbors between previews.
Metric-Based Autoscaling (fly-autoscaler)	Keeps a fixed pool of Machines per region ready-to-start based on load.	Staging feels fast and responsive during the day without needing a permanently-on cluster.

Ideal Use Cases

• Best for staging environments that are quiet at night and on weekends: Because autostop/autostart can scale Machines to zero outside working hours, so you only pay for actual engineering usage.
• Best for per-PR preview environments: Because each preview can be a full app with its own Machines and database that scale to zero when a PR goes stale, instead of paying for a farm of zombie branches.

Limitations & Considerations

• Cold-start latency on first request: When all Machines are stopped, the first request has to wait for Machines to start (typically under a second, but not zero). For customer-facing “staging-turned-beta” environments, use fly-autoscaler or a small always-on pool to hide this.
• Background jobs and long-lived connections: Autostop relies on idleness. If your staging app runs long background tasks or maintains WebSocket connections, those Machines won’t be considered idle. Move batch work to separate job Machines with their own schedules or shorter lifetimes.

Pricing & Plans

Fly.io pricing is usage-based: you pay for CPUs, memory, storage, and bandwidth while Machines are running, down to the second. When Machines autostop, compute charges stop.

Two common patterns for staging/preview:

• Lean Staging Setup:
  A single shared staging app (myapp-staging) with small Machines (e.g., shared-cpu-1x, 512MB–1GB RAM) in 1–2 regions. Autostop/autostart handles nights and weekends.
  • Best for small teams needing a reliable staging environment without heavy concurrency.
• Rich Preview + Staging Setup:
  One shared staging app plus per-PR preview apps with their own small Machines and Tigris object storage or a tiny Postgres cluster. Use autostop/autostart everywhere and fly-autoscaler on shared staging.
  • Best for teams needing per-branch testing, product demos, and QA environments that mirror production without a huge, always-on bill.

Exact costs depend on your chosen CPU/memory sizes and how often your team actually hits staging/preview. The whole point here is that when you’re not hitting them, they aren’t running.

Frequently Asked Questions

Will autostop/autostart break my CI or automated tests?

Short Answer: No, as long as your tests can tolerate a short warm-up period or you ping the app before running heavy tests.

Details:
CI and automated tests behave like any other client:

• If a preview app is stopped, the first test request will trigger autostart. Add a small retry or initial health check if you want to be robust.

• For test suites that are sensitive to startup time, add a pre-step in CI:

  fly apps restart myapp-pr-${PR_NUMBER}
  # or
  curl -f https://myapp-pr-${PR_NUMBER}.fly.dev/healthz
  

Once Machines are running, your tests see a normal, fully alive environment. After the test suite finishes and the idle timer expires, Machines stop again and costs go back to zero.

What happens to my data when Machines stop?

Short Answer: Data on attached volumes, Postgres, and Tigris stays put. Stopping a Machine is not the same as deleting it.

Details:

• Local NVMe volumes: If you attach a volume (for Postgres, caches, etc.), its data persists when the Machine stops. When the Machine starts again, it reattaches the same volume.
• Fly Postgres: Postgres runs on Machines too, but you can configure it with its own policies. For staging/preview, you might:
  • Use a small Postgres cluster that stays on.
  • Snapshot/restore from production for realistic data.
• Tigris object storage: Objects live independently of your Machines. Stopping a Machine doesn’t touch your buckets.

Stopping Machines is a power save, not an rm -rf /. You only lose ephemeral in-memory state, which is exactly what you want for cheap, safe staging.

Summary

You don’t have to choose between “real” staging/preview environments and a sane cloud bill. On Fly.io, you run staging and per-PR previews on Fly Machines, enable autostop/autostart so they scale to zero when idle, and optionally add fly-autoscaler to keep a small pool of Machines ready during busy hours.

The result:

• Full-stack, production-like environments per branch or team.
• Clean isolation with per-app networking, logs, and storage.
• Compute billing that tracks real usage, not the calendar.

You get to keep all your staging and preview toys without paying for them to idle 24/7.

Next Step

Get Started