Deploying Fly.io: your Rails app, at the edge.: what should I watch out for? (#1)

Fly Machines auto-stop is amazing for staging and terrible for hot prod paths. Set `min_machines_running = 1` (or more) on the web service or watch your p95 spike on cold starts.

Deploying Fly.io: your Rails app, at the edge.: what should I watch out for? (#2)

Volumes are pinned to a single Machine. Never store user uploads on a Fly Volume in prod — use Tigris (S3-compatible, Fly-native) or a normal S3 bucket.

Deploying Fly.io: your Rails app, at the edge.: what should I watch out for? (#3)

The default Postgres is unmanaged HA on Fly Machines — you're the DBA. For anything critical, budget for backups (WAL-G / Litestream) or use Fly Managed Postgres / an external provider.

Deploying Fly.io: your Rails app, at the edge.: what should I watch out for? (#4)

`fly ssh console` opens a shell in a fresh Machine, not the running one — anything you write to disk is thrown away. Use `fly console` (Rails) for a proper Rails console.

// cloud · fly.io

Fly.io: your Rails app, at the edge.

Firecracker microVMs in 30+ regions with a Heroku-ish CLI. Rails' unofficial second home, and the best story for global read replicas we've seen.

Fly.io takes your Docker image, boots it as a Firecracker microVM inside their global anycast network, and gives you a private 6PN mesh, managed Postgres, and one-command deploys. The whole config is a fly.tomlthat fits on a laptop screen — and multi-region reads are a first-class feature, not a slide deck.

30+

regions

~300 ms

cold-start (Machines)

shared-cpu-2x · 1 GB

typical prod VM

01 / 04

One Dockerfile, one fly.toml

Rails 7+ ships a production Dockerfile out of the box. `fly launch` reads it, generates a `fly.toml`, provisions Postgres, and does the first deploy. Subsequent `fly deploy` runs are content-addressable image builds + rolling Machine restarts.

toml
# fly.toml
app = "my-rails-app"
primary_region = "iad"

[build]

[env]
  RAILS_LOG_TO_STDOUT = "true"
  RAILS_SERVE_STATIC_FILES = "true"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 1

[[vm]]
  size = "shared-cpu-2x"
  memory = "1gb"

02 / 04

Postgres, close to the app

`fly postgres create` gives you an HA Postgres cluster on Fly Machines in the same region as your app — no cross-region latency on the hot path. For real HA, scale to 3 nodes; for global reads, add read replicas in secondary regions and let Rails route with `connects_to`.

03 / 04

Multi-region reads (the killer feature)

Deploy the same app to `iad`, `fra`, and `nrt`, add Postgres read replicas next to each, and Fly Replay lets writes bounce to the primary region in a single HTTP hop. It's the closest thing to 'globally distributed Rails' that a small team can actually run.

04 / 04

Background jobs on Machines

Run Sidekiq or Solid Queue as a separate process group in `fly.toml`. Machines auto-stop when idle (great for staging), and you can size the worker VMs independently of web — a real cost win vs one-size dynos.

Gotchas we learned the hard way

!Fly Machines auto-stop is amazing for staging and terrible for hot prod paths. Set `min_machines_running = 1` (or more) on the web service or watch your p95 spike on cold starts.
!Volumes are pinned to a single Machine. Never store user uploads on a Fly Volume in prod — use Tigris (S3-compatible, Fly-native) or a normal S3 bucket.
!The default Postgres is unmanaged HA on Fly Machines — you're the DBA. For anything critical, budget for backups (WAL-G / Litestream) or use Fly Managed Postgres / an external provider.
!`fly ssh console` opens a shell in a fresh Machine, not the running one — anything you write to disk is thrown away. Use `fly console` (Rails) for a proper Rails console.