Skip to content
inetGeek

Node.js on Fly.io

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

JavaScript runtime used to run servers and build tooling outside the browser.

01.

What Node.js needs.

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

Persistent processes

Not documented

A long-running process is the point: WebSocket connections, in-memory caches and job queues all die with it. A host that only runs functions cannot keep one alive.

Max request duration

Not documented

Anything the process does inside a request — a large upload, a slow query, a streamed response — is bounded by this ceiling.

Docker deployment

Supported

Node apps routinely need a system binary the platform's buildpack does not ship. A Dockerfile is the escape hatch when they do.

Sources (1) →
  • Deploy a Fly.io app ↗

    “fly deploy builds, or gets, the Docker image for the app, and refreshes Machines with the latest changes. If there's a Dockerfile in the local working directory, use that Dockerfile for the build.”

    Read 2026-09-05 · official docs

Scales to zero

Supported

An always-on process bills while idle. Scaling to zero removes that cost and adds a cold start to the next request instead.

Sources (1) →
  • Automatically stop and start Machines · Fly Docs ↗

    “Use autostop/autostart to automatically start and stop or suspend existing Machines based on incoming requests. [...] you don't pay for their CPU and RAM when they're in a stopped or suspended state.”

    Read 2026-09-05 · official docs

The requirement and the reason it matters are ours. Every value beside them was read from Fly.io's own pages — expand a source to see the sentence it came from.

02.

What Fly.io documents.

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

The Basics covers everything you need to set up, run, and manage production Node.js apps on Fly.

Sources (1) →
03.

What it costs to run there.

Pricing model
Usage-based, no compute plan tiers
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
18 regions
Sources (2) →
  • Fly.io pricing ↗

    “Plans get complicated, so we just charge based on usage. Billing is based on the resources provisioned for your apps, pro-rated for the time they are provisioned.”

    Read 2026-09-05 · official docs

  • Fly.io regions ↗

    “You can host your apps in any of the following regions — including ams (Amsterdam, Netherlands), nrt (Tokyo, Japan) and syd (Sydney, Australia).”

    Read 2026-09-05 · official docs

04.

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.

Visit Fly.io documentation