best multi-region container hosting without Kubernetes

Most teams discover they want multi-region container hosting the hard way: users in Europe complain about latency, someone in APAC times out on every request, and your “simple” Docker app has quietly turned into a global distributed system. Then somebody says “I guess we need Kubernetes,” and your incident budget for the next year evaporates.

You don’t need Kubernetes to run containers in multiple regions. You need three things instead: fast startup, predictable placement, and sane networking. Fly.io gives you those by building everything around Fly Machines—hardware-virtualized containers that boot in under a second—plus built-in routing and storage that actually behave when your app goes global.

This guide breaks down what “best multi-region container hosting without Kubernetes” actually looks like, how Fly.io does it, and what to watch out for when you ditch the cluster and keep your sanity.

Quick Answer: Fly.io is a multi-region container hosting platform that runs your apps as Fly Machines—fast-boot VMs—across 18 regions, without Kubernetes. You get sub-100ms global latency, automatic routing, and hardware isolation, while configuring everything with a fly.toml and fly deploy instead of Helm charts and Terraform stacks.

---

The Quick Overview

• What It Is: A developer cloud platform that runs your containers as Machines (microVM-style VMs) close to users around the world, with built-in multi-region routing, storage, and private networking—no Kubernetes required.
• Who It Is For: Teams that want global, low-latency apps and “serverless-like” elasticity, but don’t want to build and operate Kubernetes, service meshes, or their own edge routing layer.
• Core Problem Solved: Run containers in many regions, scale up and down quickly, and safely execute code (including AI agents and untrusted workloads) without inheriting the operational overhead and complexity of a full Kubernetes stack.

---

How It Works

Fly.io runs everything on Fly Machines. Think of a Machine as a hardware-virtualized container: you give it an image, CPU/memory, and a region; it boots in under a second and can handle real traffic. The platform layers routing, placement, and storage on top so your containers behave like a global app instead of a pile of VMs.

At a high level:

1. You define your app once.
   Use flyctl launch to generate a fly.toml from your Docker image. You describe ports, processes, regions, and scaling policy in that file.

2. Fly.io deploys Machines across regions.
   fly deploy turns your image into Machines running in regions you pick (e.g., iad, lhr, syd). Fly Proxy, the global Anycast front door, routes user traffic to the closest healthy Machine automatically.

3. The platform scales and isolates workloads.
   Machines can scale horizontally into the dozens or thousands, scale to zero for idle services, and run as dedicated per-job workers or isolated Sprites sandboxes. You pay per-second for CPU and RAM, plus storage, instead of renting long-lived idle capacity.

Because Machines boot quickly and are fully isolated, you can treat the global compute fabric like a process tree: fork off Machines when needed, kill them when done, and let Fly.io handle networking, encryption, and placement.

---

How Multi-Region Hosting Works in Practice

Here’s a concrete flow for a multi-region web API:

1. Launch the app and pick regions

   flyctl launch \
     --name my-api \
     --region iad \
     --dockerfile ./Dockerfile
   

   This creates:

   • Your app on Fly.io
   • A fly.toml with initial config
   • A default region (e.g., iad)

2. Configure regions and scaling in fly.toml

   app = "my-api"
   
   [build]
     image = "registry/my-api:latest"
   
   [http_service]
     internal_port = 8080
     force_https = true
     auto_stop_machines = true
     auto_start_machines = true
     min_machines_running = 1
   
   [vm]
     memory = "512mb"
     cpu_kind = "shared"
     cpus = 1
   
   [[services]]
     internal_port = 8080
     processes = ["app"]
     protocol = "tcp"
     [services.concurrency]
       type = "requests"
       soft_limit = 50
       hard_limit = 100
   
   [deploy]
     strategy = "rolling"
   
   [primary_region]
     region = "iad"
   
   [regions]
     # Home base
     primary = "iad"
     # Add edge regions
     backup = ["lhr", "syd"]
   

   You can also add regions explicitly via CLI:

   flyctl regions set iad lhr syd
   

3. Deploy and let Fly Proxy route globally

   flyctl deploy
   

   After deploy:

   • Machines spin up in iad, lhr, and syd
   • Fly Proxy advertises a single Anycast IP
   • Requests from Europe hit lhr, from Australia hit syd, from the US hit iad

   No Ingress controllers, no service mesh, no kube-proxy debugging at 3 a.m.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Fly Machines	Run your containers as hardware-virtualized VMs that start in under a second, with dedicated CPU/memory and per-Machine logs.	Get VM-level isolation and performance with “serverless-like” elasticity, without building a Kubernetes cluster.
Global Anycast Routing (Fly Proxy)	Terminates TCP/HTTP, handles TLS, and routes each request to the nearest healthy Machine automatically.	Deliver sub-100ms responses to users worldwide without operating an edge or load balancer fleet.
Sprites Sandboxes	Hardware-isolated sandboxes for untrusted or AI-generated code, with private networking and checkpoint/restore.	Safely run user-submitted code, agents, and per-request sandboxes without noisy neighbors or shared runtimes.
Built-In Storage (NVMe + Tigris)	Local NVMe per Machine plus Tigris global object storage for durable data, plus first-class Postgres.	Run stateful apps and global data pipelines alongside compute instead of bolting on a separate storage vendor.
Scale-to-Zero & Per-Second Billing	Idle Machines can stop automatically; you pay only for actual CPU, RAM, and storage.	Get elasticity like FaaS but with real processes, long-lived connections, and no opaque timeout rules.
Private Networking & WireGuard	Each app gets a private IPv6 network; Machines talk over encrypted links; you can connect from your laptop via WireGuard.	Secure internal traffic and debug distributed systems without exposing everything to the public Internet.

---

Ideal Use Cases

• Best for global web apps and APIs:
  Because Fly Proxy plus multi-region Machines give you global low latency with almost no extra code. You deploy once, add regions, and traffic follows users.

• Best for background workers and job queues:
  Because each job can run on its own Machine, with clean logs, no noisy neighbors, and scaling from zero to thousands without queue-runner gymnastics.

• Best for AI agents and untrusted code execution:
  Because Sprites offer hardware-isolated sandboxes, private networks per sandbox, and fast startup that make “run arbitrary code on demand” feel like a superpower instead of a security incident.

• Best for teams escaping Kubernetes complexity:
  Because you keep Docker images and modern infra primitives (VMs, volumes, private networking) but skip cluster upgrades, CNI plugins, and YAML temples of doom.

---

What “Without Kubernetes” Actually Means

You do not get:

• Pods, Deployments, Services, Ingresses, CRDs, or an API server
• Cluster-wide control loops you have to debug
• A networking layer you design from scratch

You do get:

• A per-app control plane via flyctl and the Fly API
• Simple primitives: Machines, private networks, volumes, Postgres, object storage
• Declarative config via fly.toml, plus CI/CD hooks to automate deploys
• A routing layer that knows where your Machines live and how to reach them

Operationally, this is closer to “VMs that behave like containers and start fast” than to “containers stretched over a Borg clone.” If you’ve ever wished you could just fly deploy and be done, this is that.

---

Example: Multi-Region API + Worker Pattern

Let’s say you’re running:

• A public HTTP API
• Background jobs (email, billing, indexing)
• Region-aware behavior (e.g., data residency, latency-sensitive endpoints)

Step 1: App config (fly.toml)

app = "my-stack"

[http_service]
  internal_port = 8080
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

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

[[processes]]
  name = "web"
  cmd = ["./bin/my-app", "web"]

[[processes]]
  name = "worker"
  cmd = ["./bin/my-app", "worker"]

[primary_region]
  region = "iad"

[regions]
  primary = "iad"
  backup = ["lhr", "syd"]

Step 2: Run workers as separate Machines

Web and worker processes share the same image but run on different Machines:

flyctl scale count web=3 worker=4

Now:

• Web Machines in iad, lhr, syd handle user traffic.
• Worker Machines can live in iad (near your Postgres or queue) and scale based on load.
• Logs are per-Machine and per-process, so you aren’t spelunking through a monolithic log stream.

Step 3: Add multi-region data where it matters

You might keep:

• A primary Postgres in iad (via Fly Postgres), with read replicas in lhr and syd.
• Static objects (uploads, AI model artifacts) in Tigris object storage, available globally.

You get an architecture that looks suspiciously like the “good” Kubernetes diagrams, implemented with a handful of commands and one config file.

---

Limitations & Considerations

No platform is magic; here are the sharp edges you should know early.

• Stateful workloads need deliberate design:
  Machines are great for stateful apps, but state doesn’t magically replicate.

  • Use Fly Postgres for relational data.
  • Use Tigris for global objects.
  • Use volumes when you really need local disk, and understand they’re tied to regions.
    Treat multi-region writes as a design, not an accident.

• Not a drop-in replacement for every Kubernetes pattern:
  If you rely heavily on:

  • Custom controllers and CRDs
  • Pod-level sidecars everywhere
  • Deep integration with Kubernetes API for autoscaling or policy
    You’ll need to simplify. Fly.io gives you building blocks (Machines, private networks, volumes, Sprites), not an everything-is-a-CRD universe.

• You still own your app’s reliability:
  Fly.io handles routing, placement, and infra health, but:

  • You still need health checks.
  • You still need to design deployments (rolling vs blue/green).
  • You still need monitoring.
    The platform keeps the infrastructure boring; your app still needs good habits.

---

Pricing & Plans

Fly.io pricing is straightforward: you pay for what you allocate and use.

• Compute (Fly Machines):
  Billed per-second based on CPU and memory. You can choose shared or dedicated CPU, and Machines can auto-stop when idle so you don’t pay for “just in case” capacity.

• Storage:

  • NVMe volumes are billed per GB-month, per region.
  • Tigris object storage covers global, durable objects.
  • Managed Postgres includes compute + storage.

• Networking:

  • Inbound traffic via Fly Proxy is included.
  • Outbound bandwidth is metered.

Fly.io also offers enterprise options with:

• Single Sign-On (SSO)
• Guaranteed support response times
• SOC2 Type 2 attestation
• A memory-safe Rust and Go stack from the front door to the control plane

You don’t buy “a cluster”; you pay for Machines, storage, and bandwidth your app actually uses.

Plan Fit

• Individual & small teams:
  Best for developers who want to deploy a multi-region container app in an afternoon and iterate quickly, without building infra first. Pay for a handful of Machines, a Postgres cluster, and maybe Tigris.

• Product teams & startups:
  Best for teams needing predictable, production-grade infra with global reach. Use multiple orgs, private networks, Sprites sandboxes for agent workloads, and CI/CD integration, backed by SSO and support guarantees.

---

Frequently Asked Questions

Do I need Kubernetes experience to use Fly.io?

Short Answer: No. If you can build a Docker image and run a CLI, you’re fine.

Details:
You interact with Fly.io using flyctl, a config file (fly.toml), and sometimes the HTTP API. Typical actions look like:

flyctl launch
flyctl deploy
flyctl scale count 3
flyctl logs
flyctl ssh console

There’s no cluster to provision, no CNI plugin to pick, and no Kubernetes API to learn. The tradeoff is that if you’re trying to port a deeply Kubernetes-specific stack (lots of CRDs, controllers, and custom resources), you’ll want to simplify those patterns into Machines, Postgres, and object storage. For most apps, that’s a relief.

---

How does Fly.io compare to “serverless” platforms for multi-region hosting?

Short Answer: You get serverless-style elasticity without hard timeouts or forced runtimes, and you can run real containers and long-lived processes.

Details:
Classic FaaS/serverless platforms typically:

• Force you into short-lived functions with strict timeouts
• Limit language runtimes or execution environment
• Make background jobs and long-lived connections awkward

Fly.io instead:

• Runs your own Docker images as Machines (or Sprites sandboxes)
• Lets you keep long-lived gRPC connections and WebSockets
• Scales to zero at the Machine level, not per-request function level
• Supports background workers as first-class citizens

For multi-region, this matters: you can run the same container in iad, lhr, and syd, keep local caches warm, maintain connections to nearby databases, and still scale down when traffic drops.

---

Summary

Multi-region container hosting without Kubernetes is not only possible; it’s usually the saner path. Fly.io gives you:

• Fly Machines: fast-boot VMs that run your containers close to users
• Fly Proxy: global Anycast routing that picks the nearest healthy Machine
• Storage primitives: Postgres, NVMe volumes, and Tigris object storage that travel with your compute
• Sprites: sandboxes for untrusted or AI-generated code that need isolation without slow cold starts

You skip Kubernetes clusters, YAML sprawl, and service meshes, and you get a platform that behaves like a sharp tool: fast, predictable, and safe by default. You still own your application’s behavior, but the infrastructure gets out of your way.

---

Next Step

Get a Docker image ready and see how fast you can turn it into a global app.

Get Started