How can I deploy a Docker container without setting up Kubernetes or managing servers?

Most teams just want to get a Docker container online, close to users, without spending a week wiring up Kubernetes or babysitting VMs. You want docker build, push, deploy, done—not “install Helm,” “learn Ingress,” and “why is etcd sad again?”

Quick Answer: Fly.io lets you deploy a Docker container as a hardware-virtualized VM (a Fly Machine) with a few CLI commands—no Kubernetes, no server provisioning. You get global routing, auto-scaling, and private networking out of the box, and you only pay for the CPU and RAM your container actually uses.

The Quick Overview

• What It Is: A developer cloud that runs your Docker containers as fast-starting VMs (Fly Machines) close to users, with built-in routing, storage, and isolation.
• Who It Is For: Developers who want to deploy containers globally without running Kubernetes, managing servers, or hand-rolling networking and scaling.
• Core Problem Solved: Ship containers to production—anywhere in the world—without taking on the complexity of a full cluster or DIY infrastructure.

How It Works

Instead of you standing up servers or a Kubernetes cluster, Fly.io takes your Docker image, runs it as a Fly Machine, and automatically wires it to Fly Proxy (the global Anycast entrypoint). You ship a container; Fly handles:

• Region placement (e.g., iad, lhr, syd)
• Anycast routing and load balancing
• Scale up/down, including scale-to-zero
• Private networking between your services
• Persistent and object storage when you need it

At a high level:

1. Build & Configure:

   • Point Fly.io at your Dockerfile (local or remote).
   • flyctl launch generates a fly.toml with your app’s config (ports, regions, scaling).

2. Deploy & Run:

   • fly deploy builds (or pulls) your Docker image and starts Fly Machines.
   • Fly Proxy sends traffic to your Machines, wherever they’re running.

3. Scale & Evolve:

   • Add regions, tweak concurrency, or scale to zero with config changes.
   • Attach NVMe, Postgres, or Tigris object storage for stateful workloads.

Under the hood, Machines are hardware-virtualized containers that start fast enough to serve HTTP traffic on demand. You get VM-level isolation with container ergonomics.

1. Build and configure your app

You can start from any directory with a Dockerfile:

cd my-app
flyctl launch

flyctl launch will:

• Detect your Dockerfile or suggest one.
• Create an app name (e.g., my-app-fly).
• Generate a fly.toml with sane defaults.

A minimal fly.toml might look like:

app = "my-app-fly"
primary_region = "iad"

[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 0
  processes = ["app"]

Key bits:

• primary_region: where your first Machines live.
• internal_port: where your container listens.
• auto_stop_machines / auto_start_machines: scale-to-zero behavior.

2. Deploy your Docker container

From the same directory:

fly deploy

Fly.io will:

• Build your Docker image (local builder or remote, using --remote-only if needed).
• Push it to Fly’s registry.
• Start Machines from that image.

You can watch logs:

fly logs

And hit your app via the autogenerated hostname:

fly open
# or check the URL printed after deploy

No servers to SSH into, no kube manifests, no load balancer creation wizard. The platform handles the boring parts.

3. Scale and go global

Need more capacity or lower latency in another region? You can spread Machines around the world without a cluster redesign.

Add a region:

fly regions add lhr

Scale up Machines:

fly scale count 3

Fly Proxy will route users to the nearest healthy Machine. For simple HTTP services, that’s honestly most of what you need.

If you like everything declarative, you can keep it in fly.toml instead:

[vm]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 256

[http_service.concurrency]
  type = "requests"
  hard_limit = 50
  soft_limit = 40

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Fly Machines	Run your Docker image as fast-starting, hardware-virtualized VMs that can start/stop on demand.	Get serverless-like elasticity without running Kubernetes or maintaining VMs.
Fly Proxy & Global Regions	Anycast routing from a single hostname to Machines in up to 18 regions.	Users hit the closest instance automatically—sub-100ms experiences without DIY edge routing.
Sprites (Secure Sandboxes)	Hardware-isolated sandboxes, spun up in under a second, for running untrusted or AI-generated code.	Safely execute dynamic or user-submitted code without sharing runtimes or risking noisy neighbors.

Ideal Use Cases

• Best for “I have a Docker container, just run it”: Because Fly.io can deploy a Docker image anywhere in the world from the command line with a few commands—no cluster setup, no IAM maze, no YAML graveyard.
• Best for globally distributed apps without an SRE team: Because region placement, routing, and auto-scaling are built in. You focus on your app logic; Fly Machines handle the geography and scaling.

Other good fits:

• Per-PR review apps using GitHub Actions and short-lived Machines.
• Cron jobs using Fly’s Cron Manager, where each run gets an isolated Machine.
• AI agents or tools that need to run untrusted code in Sprites, with private networking between your main app and the sandbox.

Limitations & Considerations

• Not a “just push code” PaaS: You still build a Docker image (or let flyctl generate a Dockerfile). If you refuse to touch containers, this will feel low-level. On the other hand, it’s transparent: Docker images, predictable Linux-based VMs, no magic.
• You’re in charge of app-level behavior: Fly.io won’t stop you from running stateful processes without storage or binding to the wrong port. The platform takes care of infrastructure; you still need to handle healthy shutdown, readiness, and connection pooling like a grown-up service.

Other things to know:

• Persistent storage (NVMe volumes) is per-region; design for that if you need disks.
• UDP and exotic networking have constraints—HTTP/TCP is first-class.
• For very high throughput, you’ll want to tune concurrency and Machine sizes instead of just “add more replicas and hope.”

Pricing & Plans

Fly.io charges per CPU-second, GB-second of RAM, storage, and bandwidth. Machines only bill while they’re running; when they’re stopped (via scale-to-zero or manual), you’re not paying for idle CPU/RAM.

Typical small web service:

• 1 shared vCPU, 256–512 MB RAM
• Ran in 1–3 regions
• Bills down to the second; good fit for spiky or low-duty-cycle workloads.

Plans are mostly about org features rather than separate runtimes:

• Usage-Based (default): Best for solo devs and small teams needing a straightforward “pay for what you actually use” model without committing to fixed capacity.
• Business / Enterprise tiers: Best for teams that need SSO, guaranteed support response times, SOC2 Type 2 assurances, and organizational controls in addition to the same Machines/Sprites primitives.

You don’t choose a “serverless plan” vs “VM plan”—everything runs on Machines. Plans simply layer governance and support on top.

Frequently Asked Questions

Do I need Kubernetes to deploy a Docker container on Fly.io?

Short Answer: No. Fly.io replaces the need for you to run Kubernetes at all.

Details: You bring a Dockerfile or image; Fly.io schedules and runs it as a Machine. Scaling, health checks, region placement, and routing are handled by the platform. There’s no control plane for you to manage, no cluster upgrades, and no kubectl–shaped learning curve. For many teams, Fly.io is the “we never had to learn Kubernetes” path.

Can I run multiple services and databases, or is this just for a single container?

Short Answer: You can run full stacks: multiple apps, background workers, cron, and databases.

Details: Each thing runs as its own Machines app:

• Web/API service in one app.
• Background workers in another (maybe scaled differently).
• Postgres via fly postgres create or as your own Docker image.
• Object storage via Tigris for global, durable blobs.

Everything shares a private, encrypted network. You can SSH into Machines for debugging, snapshot volumes, and use Cron Manager for scheduled jobs. It behaves like a sharp, minimal cloud, not a toy one-container host.

Summary

If your question is “How can I deploy a Docker container without setting up Kubernetes or managing servers?”, the practical answer is: treat Fly.io as your container runtime in the cloud. You:

• Build or point at a Docker image.
• Run flyctl launch + fly deploy.
• Let Fly Machines and Fly Proxy handle global routing, scaling, and isolation.

You keep the operational clarity of Docker and Linux VMs, skip the cluster ops, and get hardware-isolated sandboxes (Sprites) when you need to run untrusted code. It’s production-grade compute without the Kubernetes-shaped tax.

Next Step

Get Started