# Next.js on Fly.io

Canonical: https://inetgeek.com/stacks/nextjs-on-fly-io/

Fly.io publishes its own guide for deploying Next.js.

React framework with file-based routing, server components and a build step that produces both static and server-rendered output.

## What Next.js needs

Every host claims to run Next.js, so the claim on its own decides nothing. These are the things Next.js requires from the platform underneath it, and what Fly.io publishes about each. Fly.io documents 3 of the 6.

| Requirement | Fly.io | Why it matters |
| --- | --- | --- |
| Max request duration | Not documented | Server components and route handlers run per request. The wall-clock ceiling decides whether a slow upstream API or a model response can finish at all. |
| Streaming response limit | No duration or size ceiling documented. Streaming works, but Fly Proxy buffers responses before compressing them, so progressive server-side rendering needs Content-Encoding: none set on those responses. | The App Router streams the dynamic parts of a page as they resolve. A host that buffers the whole response first removes the benefit. |
| Edge network | Limited | Middleware runs on every matched request before the cache is consulted. Where it executes decides how much latency it adds. |
| Build allowance | Not documented | A large Next.js app prerenders at build time, so the build allowance is a recurring cost rather than a one-off. |
| Git deployment | Limited | The Next.js workflow assumes a push builds and ships. A host without git-triggered deploys means wiring CI yourself before the first deploy, which is most of the setup cost. |
| Concurrent builds | Not documented | Next.js builds are slow enough that queueing is felt. One build at a time is workable alone and becomes the bottleneck the moment two people merge in the same hour. |

- Streaming response limit source: https://fly.io/docs/reference/content-encoding/
- Edge network source: https://fly.io/docs/reference/architecture/
- Git deployment source: https://fly.io/docs/launch/continuous-deployment-with-github-actions/

## What Fly.io documents

> You can deploy your Next.js app on Fly with minimal effort, our CLI will do the heavy lifting.

Source: https://fly.io/docs/js/frameworks/nextjs/

### Next.js features on Fly.io

- **image_optimization**: Supported — Fetch failure when optimizing images [...] Warning: For production Image Optimization with Next.js, the optional 'sharp' package is strongly recommended. Run 'npm i sharp', and Next.js will use it automatically for Image Optimization. [...] Follow the instructions in the message, and then redeploy: ([source](https://fly.io/docs/js/frameworks/nextjs/))

## What it costs to run there

|  | Fly.io |
| --- | --- |
| Pricing model | Usage-based, no compute plan tiers; billing is pro-rated for the time resources are provisioned. |
| When you exceed a cap | No plan cap to exceed — Fly bills per second for provisioned resources. The only documented enforcement is unspecified automated scaling limits, which surface as an error message (platform-wide, all plans) |
| Regions | 17 regions |

- Pricing model source: https://fly.io/docs/about/pricing/
- When you exceed a cap source: https://fly.io/docs/about/pricing/
- Regions source: https://docs.fly.io/reference/regions/

## Whether it suits you

Workloads that ship as Docker images and need placement in particular regions. Billing is purely usage-based with no plan tiers, which suits spiky or region-pinned traffic better than a flat monthly fee.

Consider something else if: You want a predictable flat bill rather than charges that track the resources provisioned for each app.

Written by Palash Bagchi on 2026-09-05. This is a recommendation, not a sourced fact — it carries no citation because it is an opinion.

## Related

- Best hosting for Next.js: https://inetgeek.com/stacks/nextjs/
- Fly.io: https://inetgeek.com/hosting/fly-io/