Fly.io vs Vercel: best setup for Next.js when you also need background jobs, websockets, and Postgres

Most teams building with Next.js eventually hit the same wall: Vercel is great for the marketing site and simple APIs, but now you need real background jobs, long‑lived WebSockets, and a serious Postgres database. The question isn’t “Fly.io vs Vercel, which one is better?” so much as “what’s the best setup for Next.js when your app stops being just a web page and starts being a system?”

Quick Answer: Use Vercel for what it’s great at—static assets, edge routing, and builds—and run your “real infrastructure” on Fly.io: background jobs on Fly Machines, WebSockets on long‑lived app processes, and Postgres on Fly.io’s managed clusters. Or, if you want one platform, run the whole Next.js app directly on Fly.io and keep everything close to your data.

---

Quick Answer: A product explainer for the best combined (or all‑in‑one) setup to run Next.js on Fly.io when you also need durable background jobs, WebSockets, and Postgres—without duct‑taping three different stacks yourself.

The Quick Overview

• What It Is: A pragmatic setup pattern for running Next.js plus background jobs, WebSockets, and Postgres using Fly.io (optionally with Vercel in front).
• Who It Is For: Teams who’ve outgrown a pure “serverless” model on Vercel and now need durable workers, long‑lived connections, and stateful storage without inheriting Kubernetes.
• Core Problem Solved: You get a consistent runtime for your app, jobs, and database—running close together—so you don’t end up debugging cold starts, dropped sockets, or latency between your API and Postgres.

How It Works

You have two main architectures that actually work in production:

1. Hybrid: Vercel + Fly.io (most common for existing apps)

   • Next.js front‑end and basic APIs stay on Vercel.
   • Heavy lifting—background jobs, WebSockets, and Postgres—run on Fly.io.
   • You call Fly.io services from Vercel via private-ish APIs (or move API routes over time).

2. All‑in on Fly.io (simpler once you’re ready)

   • You deploy the entire Next.js app on Fly Machines.
   • Background workers are just separate Machines running the same image with a different command.
   • WebSockets terminate directly on long‑lived app processes.
   • Postgres runs on Fly.io’s managed clusters in the same region(s).

Under the hood, Fly.io gives you:

• Fly Machines: hardware‑virtualized containers that launch fast enough to serve HTTP, but can also run as long‑lived processes for WebSockets and workers.
• Fly Proxy: global anycast routing that sends users to the closest region where your app is running.
• Postgres on Fly.io: region‑local Postgres with optional replicas in other regions.
• Private networking: all your Machines and Postgres clusters share a WireGuard‑backed private network.

So you pick where Next.js renders, put Postgres in the same region, and add background/WS processes as extra Machines.

1. Hybrid: Vercel for UI, Fly.io for jobs/WebSockets/Postgres

Flow:

1. User hits yourapp.com → Vercel serves the Next.js app.
2. Background work (emails, queue processing, AI tasks) is triggered via a Fly.io API endpoint or a queue (e.g., Redis, SQS‑style, or Postgres‑backed job table) living on Fly.io.
3. WebSocket connections go directly to Fly.io (e.g., wss://realtime.yourapp.com), where long‑lived Machines keep connections open.
4. Both jobs and WebSockets talk to Postgres on Fly.io over the private network.

This setup is good when:

• You already like Vercel for previews / builds.
• You don’t want to move the whole app yet.
• You need long‑lived processes and a “real” database right now.

2. All‑in on Fly.io: Next.js + jobs + Postgres in one cluster

Flow:

1. User hits yourapp.com → DNS points at Fly.io; Fly Proxy sends traffic to the closest region running your Next.js app.
2. Next.js server components, API routes, and WebSockets run as long‑lived Machines.
3. Background workers are dedicated Machines started with a different process command (e.g., node worker.js).
4. All of these talk to a region‑local Postgres cluster on Fly.io.

You get:

• One platform, one deployment path (fly deploy).
• No split brain between “serverless” and “real servers.”
• Low latency between app and database.

3. Background jobs on Fly Machines

Core pattern:

1. Build an image that includes both your web app and worker code.
2. Create a dedicated Fly app for workers (or separate process group in the same app).
3. Use Cron Manager, queues, or your own scheduler to start Machines per job or keep a pool running.

Example fly.toml (single app with web and worker processes):

[processes]
web = "node server.js"
worker = "node worker.js"

[[services]]
  processes = ["web"]
  internal_port = 3000
  protocol = "tcp"
  [services.concurrency]
    type = "requests"
    hard_limit = 50
    soft_limit = 40

You can then scale workers separately:

fly scale count worker=3

Each worker runs isolated on its own Machine—no noisy neighbors, and logs per process.

4. WebSockets on long‑lived Machines

Unlike many “serverless” setups, Machines can stay up as long as you want. That means:

• You bind your Next.js server to a TCP port (e.g., 3000).
• WebSocket upgrade happens normally (ws/wss).
• Connections can stay open for hours.

Simple config for a WebSocket‑capable service:

[[services]]
  processes = ["web"]
  internal_port = 3000
  protocol = "tcp"

  [services.ports]
    port = 443
    handlers = ["tls", "http"]

  [services.tcp_checks]
    interval = "15s"
    timeout = "2s"

Fly Proxy doesn’t mess with frames; once the upgrade is done, it’s a straight TCP tunnel to your Machine.

5. Postgres close to your Next.js app

Fly.io has first‑class Postgres clusters:

fly pg create --name myapp-db --regions iad --initial-cluster-size 1

Then connect from your app using the private hostname:

DATABASE_URL=postgres://postgres:password@myapp-db.internal:5432

You can place your app and jobs in iad to live next to this database:

fly launch --name myapp --region iad

If you truly need multi‑region reads, you can add replicas, but the simplest, safest production pattern is:

• One primary Postgres region.
• App and background jobs also primarily in that region.
• Optionally, static assets cached closer to users via Vercel or a CDN.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Fly Machines for jobs & WebSockets	Run long‑lived or on‑demand containers that start fast and can stay alive	Reliable background jobs and WebSockets without fighting cold starts
Managed Postgres on Fly.io	Region‑local Postgres clusters on the same private network as your app	Low‑latency queries and simpler networking, no DIY database hosting
Hybrid Vercel + Fly.io architecture	Keep Vercel for Next.js UI and move heavy/backend work to Fly.io	Best of both worlds, minimal migration risk, and clear responsibility

Ideal Use Cases

• Best for “Next.js + real‑time + jobs”: Because Fly Machines can hold WebSocket connections open, run queues and schedulers, and talk directly to Postgres with low latency.
• Best for “growing SaaS that started on Vercel”: Because you can keep the front‑end on Vercel and slowly move background APIs, job queues, and databases to Fly.io without a big bang rewrite.

Fly.io vs Vercel for this stack

This is what usually matters in practice when you’re deciding:

Background jobs

• Vercel:

  • Meant for short‑lived serverless functions and cron jobs.
  • No built‑in “run this process for hours, consuming a queue.”
  • Workarounds: third‑party job platforms or external workers.

• Fly.io:

  • Run dedicated worker Machines as long as you want.
  • Use Cron Manager for scheduled jobs, or a queue for event‑driven jobs.
  • Pay by CPU/memory usage per second, so idle workers don’t burn a hole in your wallet if you scale them down.

Verdict: For background jobs, Fly.io is the natural fit. Vercel is fine for lightweight scheduled HTTP calls; not great for durable processing.

WebSockets

• Vercel:

  • Edge/runtime is not designed for long‑lived connections by default; typically you end up pushing WebSockets to a third‑party provider.
  • Good for HTTP, less great for “thousands of open sockets for hours.”

• Fly.io:

  • Machines handle normal TCP and HTTP upgrade.
  • You can scale the number of Machines based on concurrent connection needs.
  • Global anycast means you can put WebSocket endpoints in a couple of regions close to users.

Verdict: If real‑time is core (chat, dashboards, collaborative UIs), run WebSockets on Fly.io.

Postgres

• Vercel:

  • Partner ecosystem (Neon, PlanetScale, etc.) but the database is always “somewhere else.”
  • You choose region, networking, and connection strategy yourself.

• Fly.io:

  • Postgres clusters are first‑class.
  • App and DB run inside the same private network, same or nearby regions.
  • Easier to reason about latency and failure modes.

Verdict: When the database is central (which is most SaaS), having it managed and co‑located with your compute on Fly.io is a big sanity win.

Operational complexity

• Vercel:

  • Extremely simple for front‑ends and small APIs.
  • Complexity appears when you bolt on external workers, socket providers, and DBs.

• Fly.io:

  • Feels like having your own fast, programmable data center.
  • You’ll manage fly.toml, Machines, and Postgres, but you avoid Kubernetes and Terraform to get there.
  • SSH into Machines for debugging when needed.

Verdict: If you’re already juggling three or more services to fill gaps in Vercel, you’re probably better off centralizing the heavy lifting on Fly.io.

Limitations & Considerations

• Multi‑region write patterns: Running Postgres in more than one write region is hard mode anywhere. On Fly.io, the production‑ready path is “one primary region, optional read replicas.” Design around that unless you’re deeply comfortable with distributed data.
• Hybrid complexity: Splitting responsibility between Vercel and Fly.io means you now have two deploys, two sets of logs, and cross‑service observability to care about. It’s still simpler than gluing five SaaS backends together, but it’s not zero‑ops.

Pricing & Plans

There isn’t a rigid “plan” mapping between Vercel and Fly.io; they bill very differently:

• Vercel: Priced around requests, bandwidth, and feature tiers (hobby vs pro vs enterprise), plus limits on function execution, build minutes, etc.
• Fly.io: You pay per‑resource:
  • CPU and RAM for Machines, to the second.
  • Storage for NVMe and Tigris (object storage).
  • Postgres cluster size and replicas.

Two common patterns:

• “UI on Vercel, backend on Fly.io”: Best for teams who want Vercel’s DX for front‑end and preview deployments, but need Fly.io for background jobs, sockets, and a close‑by Postgres.
• “All‑in Fly.io”: Best for teams who want one bill and one operational model for Next.js, workers, and Postgres, and are comfortable wiring up their own CI/CD (GitHub Actions + fly deploy).

You can run small hobby‑scale apps on Fly.io for a few dollars a month by sizing Machines conservatively and leaning on scale‑to‑zero for workers.

Frequently Asked Questions

Can I keep my Next.js front‑end on Vercel and move only jobs/Postgres to Fly.io?

Short Answer: Yes, that’s a very common setup.

Details:
Keep your current Vercel setup for all UI routes and simple APIs. Create one or more Fly apps for:

• A job runner (HTTP endpoint that enqueues tasks + worker processes that consume them).
• A WebSocket gateway app (if you need real‑time).
• A Postgres cluster.

From Vercel, you call Fly APIs using HTTPS. Put your Fly apps on a private network with Postgres and keep them in the same primary region (e.g., iad). Over time, you can migrate heavier API routes from Vercel to Fly.io if they start to look more like backend services than “SSR helpers.”

Should I just move the whole Next.js app to Fly.io instead of staying hybrid?

Short Answer: If you’re already rebuilding your backend and want fewer moving parts, yes. Otherwise, start hybrid and migrate gradually.

Details:
Running Next.js on Fly.io works well: build a Docker image, expose port 3000, and let Fly Proxy handle global routing. Everything—server components, API routes, WebSockets, and workers—becomes just different processes or apps running as Machines. You:

• Deploy with fly deploy.
• Use Fly Postgres in the same region.
• Scale per process type (web, worker, etc.).

If you already get a lot of value from Vercel’s workflows (preview deployments, team collaboration, built‑in analytics), hybrid lets you keep those while moving only the bits Vercel isn’t built for. When the split brain gets annoying, that’s your sign to go all‑in on Fly.io.

Summary

If your Next.js app is just a website, Vercel alone is fantastic. When it turns into an actual system—with background jobs, WebSockets, and a serious Postgres behind it—you need infrastructure that treats long‑lived processes and databases as first‑class citizens.

The pragmatic path is:

• Hybrid for most teams today: Next.js on Vercel, jobs/WebSockets/Postgres on Fly.io.
• All‑in Fly.io when you’re ready to simplify: Next.js, workers, and Postgres all running as Fly Machines in the same region(s).

You get global performance, real isolation per job or connection, and Postgres close enough that you stop thinking about “database region” every time you write a query.

Next Step

Get Started