Cloud Run alternatives when you want container/VM control (not just request-based serverless)

Most teams discover the limits of Cloud Run the hard way: you hit a scaling edge case, need to run a background task without an HTTP request, or want stronger isolation than “somewhere in a multi-tenant pool,” and suddenly the abstraction shows through. Cloud Run is great when you only care about request-based serverless and don’t want to think about machines. It’s not great when you actually do want container or VM control.

This guide walks through Cloud Run alternatives when you need more control over containers/VMs, while still keeping a “serverless-like” developer experience. We’ll look especially at platforms that give you fine-grained control over runtime, scheduling, and isolation—without forcing you into full Kubernetes brain.

---

The Quick Overview

• What It Is: A practical breakdown of Cloud Run alternatives that give you real container/VM control, including Fly.io Machines and Sprites, plus a tour of other options like Cloud Run Jobs, Cloud Run for Anthos, GCE, GKE, and a few non-GCP stacks.
• Who It Is For: Developers and teams who like the “scale-to-zero, pay-per-use” ergonomics of Cloud Run but need background jobs, stronger isolation, and more predictable control over how containers run.
• Core Problem Solved: Helping you choose a runtime that delivers Cloud Run–style simplicity and VM-level control, without falling into a full Kubernetes build-your-own-platform project.

---

Why you outgrow pure request-based serverless

Cloud Run is optimized for one thing: HTTP request in, container runs, response out. That’s perfect until you need:

• Long-running or stateful workloads
  Workers, queues, WebSockets, streaming, anything that shouldn’t be torn down between requests.
• Background jobs not tied to HTTP
  Cron-like jobs, data processing, AI agents, or “do work on a schedule or trigger” without an HTTP call as the initiator.
• Hard isolation and control
  Need to run untrusted or AI-generated code in real sandboxes, with private networks and no noisy neighbors.
• Custom networking and layout
  Private networking, regional placement, hybrid/multicloud, or multi-region “close to users” deployments.
• Run anything, not just HTTP handlers
  Daemons, TCP services, custom protocols, or specialized system services.

Once you need any of that, “just use Cloud Run” quietly turns into “also add GCE, maybe GKE, some Pub/Sub, Cloud Scheduler, and hope the glue holds.”

Let’s walk the main alternative patterns and then dig deep on Fly.io as a Cloud Run–style platform that still lets you treat VMs like real objects.

---

Fly.io Machines & Sprites: Cloud Run feel, VM control

Fly.io is a developer cloud built around Fly Machines—hardware-virtualized containers that start fast enough to handle HTTP requests and can scale into tens of thousands of instances. You still build containers, but you get explicit control of lifecycle, placement, and isolation.

If Cloud Run is “give us a container, we promise to run it on HTTP,” Fly Machines are “here’s a VM-like container you can boot, stop, fork, snapshot, and scale, with Anycast routing and private networking built in.”

The Quick Overview (Fly.io as an alternative)

• What It Is: A global developer cloud where everything runs on Fly Machines and Sprites: hardware-virtualized containers and hardware-isolated sandboxes that launch in under a second and can scale massively.
• Who It Is For: Teams that want Cloud Run–style elasticity and scale-to-zero economics, but with VM control, private networking, persistent volumes, and secure sandboxes for untrusted or AI-generated code.
• Core Problem Solved: You get “modern compute without the complexity”—run HTTP apps, background jobs, and sandboxes in real VMs, without Kubernetes/Terraform overhead.

---

How Fly.io compares to Cloud Run

At a high level:

Capability	Cloud Run	Fly.io Machines/Sprites
Startup model	Request-based container startup	Machine startup fast enough to serve HTTP directly
Control level	Container image + resource hints	Full Machine lifecycle: boot, stop, fork, snapshot
Workload types	Mostly HTTP request/response	HTTP, TCP, long-lived workers, cron, agents, sandboxes
Isolation	Multi-tenant container platform	Hardware-virtualized Machines, hardware-isolated Sprites
Networking	GCP-only, HTTP focus	Global Anycast via Fly Proxy, private WireGuard network, TCP/UDP
State	Stateless focus, integrate GCP databases	Local NVMe volumes + Tigris object storage + Fly Postgres
Triggers/jobs	HTTP-triggered, Cloud Run Jobs, Scheduler	Cron Manager + on-demand Machines + external triggers

You still get autoscaling and scale-to-zero behavior, but with knobs Cloud Run doesn’t expose.

---

How Fly Machines & Sprites work

Fly’s approach is: “Fork off VMs like they’re processes.” You run everything—apps, jobs, AI sandboxes—on Machines. They launch quickly enough to take live traffic, and you pay per second of CPU/memory use.

1. You deploy a container image

   • Use flyctl launch or flyctl deploy to turn a Docker image into one or more Machines.
   • Fly creates a fly.toml that defines regions, services, ports, and scaling behavior.

2. Fly Proxy routes traffic globally

   • Users hit a single Anycast IP.
   • Fly Proxy routes each request to the nearest healthy Machine (e.g., iad, ams, syd).
   • Machines can scale up/down and even to zero. When traffic arrives, they boot fast enough to serve HTTP.

3. Machines behave like controllable microVMs

   • You can start/stop/restart Machines explicitly with flyctl.
   • You can create one-off Machines for jobs, attach NVMe volumes, and put each job in its own isolated Machine.
   • For untrusted code, Sprites give you hardware-isolated sandboxes in under a second, with private networking and end-to-end encryption.

Under the hood, you get a memory-safe Rust/Go runtime, WireGuard-based private networking, and primitives that don’t suddenly vanish when your workload is spiky or distributed.

---

Example: Migrating a Cloud Run-style HTTP app

On Cloud Run you’d:

• Build a container
• Push to Artifact Registry
• gcloud run deploy and let GCP wire HTTP

On Fly:

# Initialize an app from your repo
flyctl launch --name my-app --region iad

# Edit fly.toml as needed, then deploy
flyctl deploy

fly.toml handles what Cloud Run hides:

[build]
  image = "ghcr.io/my-org/my-app:latest"

[env]
  PORT = "8080"

[[services]]
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"

  [[services.ports]]
    port = 80
  [[services.ports]]
    port = 443

Fly Proxy now sends HTTP traffic to your Machines. You can add regions later:

flyctl regions set iad ord lhr syd

Machines spin up near users, like Cloud Run regions, but you control where and how many.

---

Example: Background jobs without HTTP hacks

Cloud Run wants HTTP or Jobs glue. On Fly, you just run a different process in its own Machine.

Add a job process in fly.toml:

[processes]
  app = "bin/web-server"
  worker = "bin/job-runner"

Then use the Cron Manager pattern (production-hardened, documented) to run scheduled jobs in isolated Machines. High level:

• Store schedules in schedules.json
• Run a small scheduler app (on Fly) that calls the Machines API
• Each schedule triggers fly machine run --rm with the worker process

Each run gets its own fresh Machine, clean logs, and isolated environment. No “is this container still warm?” guessing, and no shared state between runs.

Pseudo-command the scheduler uses:

flyctl machine run \
  --app my-app \
  --region iad \
  --rm \
  --command "bin/job-runner process-daily-report"

You get Cloud Run Jobs–style behavior, but with full control over runtime, region, and resources.

---

Running untrusted or AI-generated code: meet Sprites

Cloud Run isn’t built for “run arbitrary third-party code safely.” You can fake it with containers and namespaces, but you’re still sharing a big multi-tenant runtime.

On Fly, you use Sprites:

• Hardware-isolated sandboxes, coming up in under a second.
• Each Sprite gets a private network, granular routing, and end-to-end encryption automatically.
• You can snapshot environments, persist state via NVMe and Tigris, and restore sandboxes.

This is what you reach for when you want to run user-submitted code, AI-generated tooling, or per-customer sandboxes with strong isolation—without building your own microVM platform.

---

Features & benefits breakdown (Fly.io vs Cloud Run expectations)

Core Feature	What It Does	Primary Benefit when leaving Cloud Run
Fly Machines	Hardware-virtualized containers that start fast and can be controlled like VMs	Keep serverless-like elasticity, gain real lifecycle control (boot, stop, fork, snapshot)
Sprites	Hardware-isolated sandboxes for untrusted/AI-generated code	Run arbitrary code in per-request sandboxes without building your own isolation layer
Global Anycast + region placement	Fly Proxy routes traffic to nearest healthy Machine in your chosen regions	Sub-100ms user experiences globally without managing edge/CDN stacks
Private networking	Per-app private networks over WireGuard with end-to-end encryption	Talk safely between services and databases without wrestling with VPC plumbing
Stateful primitives	Local NVMe, Fly Postgres, Tigris object storage	Run databases and stateful services alongside your compute, even when workloads are spiky
Cron Manager pattern	Isolated per-job Machines started on schedules	Robust, auditable scheduled jobs with clean logs and no container reuse surprises
Pay-per-use billing	CPU and memory billed to the second	Cloud Run-like economics without being locked to HTTP-only workloads

---

Other Cloud Run alternatives and how they compare

You might be weighing Fly.io against “just use more GCP” or other providers. Here’s how the landscape shakes out.

1. Cloud Run Jobs + GCE/GKE (stay in GCP)

What it is: Add Cloud Run Jobs, Cloud Scheduler, GCE, or GKE to fill the gaps.

• Pros:

  • Stay inside GCP; IAM/logging/monitoring integrated.
  • Cloud Run Jobs give you non-HTTP jobs, sort of.
  • GCE and GKE give you raw VMs and Kubernetes when you need ultimate control.

• Cons:

  • You’re now maintaining multiple primitives: Cloud Run, Jobs, Scheduler, GCE, maybe GKE.
  • GKE/Kubernetes complexity is non-trivial. You’re building a platform.
  • Global, Anycast-like behavior is DIY; multi-region is more configuration and cost.

When to choose it:
You’re heavily invested in GCP already, okay with Kubernetes or scripting around Jobs/GCE, and don’t need global edge-like latency for end users.

---

2. Cloud Run for Anthos / GKE Autopilot

What it is: Run Cloud Run–style workloads on Kubernetes (Anthos or GKE Autopilot).

• Pros:

  • More control over cluster, nodes, and networking than pure Cloud Run.
  • Still get some “managed” feel from Autopilot.

• Cons:

  • Anthropomorphizing Kubernetes doesn’t make it simple. You inherit cluster lifecycle, node pools, policy, and all the classic K8s footguns.
  • Still very GCP-centered; global multi-region remains on you.

When to choose it:
You already run Kubernetes, you want Cloud Run semantics for some services, and you’re comfortable owning cluster complexity.

---

3. Plain VMs (GCE, EC2, etc.)

What it is: Raw VMs with your own scripts, systemd services, or container runtime.

• Pros:

  • Maximum control: OS, kernel modules, networking, everything.
  • Easier to run anything: daemons, custom protocols, complex stateful services.

• Cons:

  • No built-in autoscaling or scale-to-zero; you must script it.
  • Harder to get global low-latency routing and multi-region out of the box.
  • You’re running a fleet, not a platform run-time.

When to choose it:
You need deep system-level control, maybe custom kernels or specialized hardware, and you accept platform engineering as part of the job.

---

4. Other “serverless containers” (e.g., AWS Fargate, Azure Container Apps, etc.)

These are broadly similar to Cloud Run: run containers serverlessly, mostly HTTP-first, glue in jobs and non-HTTP behavior via other managed services. The tradeoff template is the same:

• Pros:

  • Managed, pay-per-use containers.
  • Vendor-specific integrations (Lambda, queues, IAM, etc.).

• Cons:

  • Often HTTP or task-oriented.
  • Less control over lifecycle and isolation than real VMs.
  • Multi-region/global routing usually a separate problem.

When to choose them:
You’re already locked into that cloud and want Cloud Run-ish behavior under that brand logo.

---

5. DIY microVM or sandbox platforms

If what you really want is “Cloud Run, but for arbitrary untrusted code in strong sandboxes,” you might be looking at:

• Firecracker / microVM setups
• Docker-in-Docker with heavy isolation
• In-house sandboxing frameworks

Pros:

• Full control of isolation model and scheduling.
• Tailored to your exact workload.

Cons:

• You are now a platform team. Congrats?
• You own the isolation, networking, routing, storage, scheduling, observability.

When to choose it:
You’re at the scale (and funding) where building a platform is justified, or you have highly specialized isolation needs that no one else meets.

---

Ideal use cases for Fly.io as your Cloud Run alternative

• Best for latency-sensitive web apps: Because Fly Machines can run in many regions (“from Sydney to São Paulo”), and Fly Proxy handles global Anycast routing so users automatically hit the nearest Machines.
• Best for apps + jobs on one platform: Because you can run HTTP apps, workers, and scheduled jobs all as Machines with different processes, instead of stitching together Cloud Run, Jobs, Scheduler, and other services.
• Best for untrusted/AI-generated code execution: Because Sprites give you hardware-isolated sandboxes with per-sandbox private networking and—critically—start in under a second, so you can spin them up per request or per job.
• Best for teams wanting control without Kubernetes: Because you get VM-level primitives (Machines, volumes, networks) exposed directly through flyctl and the API, instead of YAMLing your way through deployments and CRDs.

---

Limitations & considerations (Fly.io and friends)

If you’re thinking of swapping from Cloud Run, it’s better to see the tradeoffs up front.

• You do define more explicitly than on Cloud Run:
  On Fly, you describe services, regions, and volumes in fly.toml instead of letting the platform decide everything. It’s not magic; it’s just how our apps work. This is a feature if you want control, but you’ll write a bit more config.

• Not a generic GCP replacement:
  Fly.io replaces Cloud Run-style compute and related networking/storage. It doesn’t aim to be a clone of every GCP product (BigQuery, Pub/Sub, etc.). You’ll still need a data warehouse, queues, and other bits from somewhere—Fly integrates well, but doesn’t pretend to be your everything-cloud.

• Kubernetes shops may have a mental model mismatch:
  There’s no kube API. You talk to Machines and Sprites directly. If your entire toolchain assumes kubectl and Pods, you’ll need to rethink how deployments and jobs are expressed.

---

Pricing and plans: comparing mental models

Cloud Run pricing is per-request/CPU/memory second, with some free tier and regional variability. Fly.io’s mental model is similar in spirit: pay for actual CPU and memory consumption, down to the second, plus storage and bandwidth.

Fly doesn’t segment into gimmicky marketing plans; instead, you choose resource sizes and optional support tiers. A rough comparison:

• Usage-based Machines/Sprites:

  • Billed per vCPU and GiB RAM, to the second.
  • If Machines are stopped (scale-to-zero, or cron jobs that only run for a minute), you don’t pay for idle compute.
  • Bandwidth and storage (NVMe, Tigris) are billed separately.

• Support / enterprise tiers (Fly.io-style “plans”):

  • Standard usage + community support: Best for solo devs and small teams just shipping apps and jobs without formal SLAs.
  • Enterprise support: Best for teams that need Single Sign-On, SOC2 Type 2 attestation, and guaranteed support response times—i.e., those who put production revenue on the line and want someone on the hook.

You can think of it as Cloud Run’s “only pay when your container is running,” extended to VM-like Machines, sandboxes, and storage primitives.

---

Frequently asked questions

Can Fly.io really replace Cloud Run for most workloads?

Short Answer: Yes, for most HTTP apps, APIs, background jobs, and sandboxed code execution, Fly Machines and Sprites can stand in for (and often surpass) Cloud Run.

Details:
If what you’re doing in Cloud Run is:

• HTTP APIs, web apps, webhooks
• Cron-like background jobs (plus Cloud Run Jobs/Scheduler)
• Worker-style processes behind Pub/Sub or queues
• Occasional “run this container for a bit, then stop”

Then Fly.io covers that with:

• Machines running web processes, scaled across regions.
• Cron Manager triggering per-job Machines.
• Worker processes for queues, each in their own Machines.
• One-off Machines via flyctl machine run or the API.

You gain VM lifecycle control and global placement while keeping autoscaling and pay-per-use economics. The main caveat is: you’ll still need to choose your databases/queues/analytics stack—Fly gives you building blocks (Fly Postgres, Tigris, etc.), not a monolithic “everything in one cloud” suite.

---

What if I just need more control inside GCP—should I jump to Fly.io?

Short Answer: If you’re deeply invested in GCP and just need more knobs, start with GCE or GKE; if you want Cloud Run simplicity with global, VM-level control and sandboxes, Fly.io is worth a serious look.

Details:
Staying in GCP is the path of least resistance when:

• Your security model, billing, and org policies are baked into GCP.
• You have existing GKE clusters or SREs comfortable with Kubernetes.
• Global latency isn’t a top priority, or you’ve already built around GCP networking.

Moving to Fly.io makes more sense when:

• You’re hitting Cloud Run limits (background jobs, WebSockets, untrusted code) and the GCP fix involves a small zoo of services.
• You want global Anycast and region placement without building your own edge/CDN/router story.
• You’re okay letting Fly handle the “platform engineering” layer so you can focus on app code, jobs, and sandboxes.

You don’t have to be a cloud guru to run on Fly; the primitives—Machines, Sprites, volumes, fly.toml—are directly exposed, well-documented, and optimized for people who’d rather ship than yak-shave Kubernetes.

---

Summary

When Cloud Run stops being enough, it’s usually because you need:

• Background jobs and workers that aren’t just HTTP.
• Stronger control over how containers/VMs start, stop, and scale.
• Safer execution of untrusted or AI-generated code.
• Global, low-latency routing and private networking.
• State that doesn’t freak out just because your workload is spiky or distributed.

You can patch those gaps with more GCP services, drop down to raw VMs, or build around Kubernetes. Or you can move to a platform that’s designed from the start to give you serverless-like elasticity with VM-level control.

Fly.io does that by running everything on Machines and Sprites—hardware-virtualized containers and hardware-isolated sandboxes that start fast, scale massively, and let you fork off VMs like they’re processes. You keep Cloud Run’s economic model, gain explicit control, and avoid turning your team into a platform engineering shop by accident.

---

Next Step

Get Started