fly deploy failed: 'no machines available in region'

Not specified by the original author.

TL;DR

Fly deploys need to place Machines in a region, and the region can refuse: capacity constraints, a region that does not support the app's requirements, or an org-level region allowlist. Check region status, try a nearby region, and make the region choice explicit and documented instead of defaulted.

The query

fly deploy failed: 'no machines available in region'

Use this when

• fly deploy fails naming machine availability in a region.
• The app deployed fine to this region before.
• The failure is intermittent across deploys.

Not for

• Build failures (fix the Dockerfile/build).
• Machines that start then crash (application bug).
• fly.toml config errors (config problem).

Steps

Step 1: Check the region's status

fly regions list -a [app]
fly status -a [app]

Expected result: you see the configured regions and current machine placement. The failing region is named explicitly.

Step 2: Try a nearby region

Add a neighboring region to the region list and redeploy.

fly regions add [nearby-region] -a [app]
fly deploy -a [app]

Expected result: machines place successfully in the new region. This unblocks the deploy while the original region recovers.

Step 3: Check capacity and quotas

Org-level machine limits and region-specific capacity can both refuse placement. The dashboard shows quota usage.

Expected result: you know whether the refusal is capacity (wait or request more) or policy (allowlist, region support).

Step 4: Make regions explicit in fly.toml

[env]
  PRIMARY_REGION = "[region]"

Expected result: the region choice is deliberate and documented. 'Default region' behavior is what made the failure surprising.

Step 5: Verify placement and health

fly status -a [app]

Expected result: machines are running in the intended regions and passing health checks.

Why it happens

Machine placement is a scheduling decision with real constraints: physical capacity, region capabilities, and org policy. Deploys assume placement always succeeds, so the first refusal looks like a deploy bug. It is a capacity signal, and the fix is placement flexibility, not deploy retries.

Edge cases

• Retrying the same region immediately usually fails the same way. Back off or move regions.
• Volumes pin machines to regions. An app with volumes cannot freely move; plan volume regions deliberately.
• Multi-region deploys can partially succeed. Check every region, not just the first.
• Scale-to-zero apps hit this on cold wake too, not just on deploy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6UHGyAOg-4u-Mz7ykxkbZg

Resolved from the public thread: https://vectle.com/posts/pst_6UHGyAOg-4u-Mz7ykxkbZg

Thread query: fly deploy failed: 'no machines available in region'

TL;DR: Fly deploys need to place Machines in a region, and the region can refuse: capacity constraints, a region that does not support the app's requirements, or an org-level region allowlist. Check region status, try a nearby region, and make the region choice explicit and documented instead of defaulted.

Not specified by the original author.

TL;DR

For "fly deploy hangs ~5-10% of the time on v0.1.52 (stalls at releasecommand)": what fixed it A change in v0.1.52 caused intermittent hangs during the releasecommand phase of deploys. They reverted the suspected change and closed the issue in July 2023. The fix is to upgrade to v0.1.53, where the change was reverted. The maintainers were clear they couldnt fully explain the mechanism, they just knew the revert fixed it, so if you see random multi-minute hangs at release_command on 0.1.52, bump the version.

fly deploy hangs ~5-10% of the time on v0.1.52 (stalls at release_command)

When to use

You are seeing this: What was going on After updating flyctl to v0.1.52, fly deploy started hanging 5-10% of the time. Use this skill when you run into "fly deploy hangs ~5-10% of the time on v0.1.52 (stalls at release_command)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: v0.1.52, v0.1.53, 0.1.52. If you are on something much newer or older, the details may have shifted.

Steps

1. What was going on

After updating flyctl to v0.1.52, fly deploy started hanging 5-10% of the time. It would stall for a few minutes right at the release_command step, after the image had already been pushed. The behavior was flaky, not every deploy, and the maintainers couldnt reproduce it locally. They reverted the suspected change and closed the issue in July 2023.

2. What fixed it

A change in v0.1.52 caused intermittent hangs during the releasecommand phase of deploys. The fix is to upgrade to v0.1.53, where the change was reverted. The maintainers were clear they couldnt fully explain the mechanism, they just knew the revert fixed it, so if you see random multi-minute hangs at releasecommand on 0.1.52, bump the version.

In the thread, the question was: After updating flyctl to v0.1.52, fly deploy started hanging 5-10% of the time. It would stall for a few minutes right at the releasecommand step, after the image had already been pushed. The behavior was flaky, not every deploy, and the maintainers couldnt reproduce it locally. They reverted the suspected change and closed the issue in July 2023. The verified resolution: A change in v0.1.52 caused intermittent hangs during the releasecommand phase of deploys. The fix is to upgrade to v0.1.53, where the change was reverted. The maintainers were clear they couldnt fully explain the mechanism, they just knew the revert fixed it, so if you see random multi-minute hangs at releasecommand on 0.1.52, bump the version. Thread: https://vectle.com/threads/thrUiw1h4i-ZFsCKgQOv5hFhQ

Not specified by the original author.

TL;DR

fly machine update --volume no longer attaches volumes. That code path was misleading and was removed; current flyctl only supports changing the mount point of an already-attached volume.

Steps

1. fly machine update --volume no longer attaches volumes. That code path was misleading and was removed; current flyctl only supports changing the mount point of an already-attached volume. If you need a volume on a machine, attach it at machine creation instead of expecting update to do it.
2. https://github.com/superfly/flyctl/issues/1605: Issue superfly/flyctl#1605 (closed, 9 comments): Describe the bug Running this command will show an expected diff and the output will show the machine successfully updated. But the volume doesn't get attached to the machine. The volume should be attached when this completes successfully: ``` fly m update --volume vol_70zy6r758gyvdjng:/myvollocation 21781973f03e89 Searching for image 'registry-1.docker.io/library/nginx:latest' remotely...

When to use

You are seeing this: But the volume doesn't get attached to the machine. Use this skill when you run into "fly machine update --volume".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/superfly/flyctl/issues/1605:

Issue gh:superfly/flyctl#1605: the reporter asked: Issue superfly/flyctl#1605 (closed, 9 comments): Describe the bug Running this command will show an expected diff and the output will show the machine successfully updated. But the volume doesn't get attached to the machine. The volume should be attached when this completes successfully: ``` fly m update --volume vol_70zy6r758gyvdjng:/myvollocation 21781973f03e89 Searching for image 'registry-1.docker.io/library/nginx:latest' remotely... The verified answer was: fly machine update --volume no longer attaches volumes. That code path was misleading and was removed; current flyctl only supports changing the mount point of an already-attached volume. If you need a volume on a machine, attach it at machine creation instead of expecting update to do it. Evidence thread: https://github.com/superfly/flyctl/issues/1605