---
image: true
author: nathan-flurry
published: "2025-06-24"
category: technical
keywords: ["cloudflare","containers","fly","firecracker"]
title: "Container Platform Comparison: Cloudflare Containers vs Rivet Containers vs Fly Machines"
description: "**Rivet is an open-source, self-hostable serverless alternative to Cloudflare Workers, Durable Objects, and Containers. Check out Rivet Containers and visit our GitHub.**"
---

export const imgCfArch = { src: "https://assets.rivet.dev/website/blog/2025-06-24-cloudflare-containers-vs-rivet-containers-vs-fly-machines/cf-arch.png", width: 3396, height: 1120, format: "png" };
export const imgRivetArchDirect = { src: "https://assets.rivet.dev/website/blog/2025-06-24-cloudflare-containers-vs-rivet-containers-vs-fly-machines/rivet-arch-direct.png", width: 2820, height: 1120, format: "png" };
export const imgRivetArchWorker = { src: "https://assets.rivet.dev/website/blog/2025-06-24-cloudflare-containers-vs-rivet-containers-vs-fly-machines/rivet-arch-worker.png", width: 3396, height: 1120, format: "png" };
export const imgFlyArch = { src: "https://assets.rivet.dev/website/blog/2025-06-24-cloudflare-containers-vs-rivet-containers-vs-fly-machines/fly-arch.png", width: 2820, height: 1120, format: "png" };

**Rivet is an open-source, self-hostable serverless alternative to Cloudflare Workers, Durable Objects, and Containers. Check out [Rivet Containers](/docs/actors) and [visit our GitHub](https://github.com/rivet-dev/engine).**

Cloudflare just launched [Cloudflare Containers](https://developers.cloudflare.com/containers/), a platform with many similarities to [Rivet Containers](/docs/actors) and [Fly Machines](https://fly.io/docs/machines).

These three platforms provide a flexible solution to quickly run on-demand containers across a globally distributed network. Common use cases for platforms like these include:

- Sandboxed code execution (especially for AI)
- Media processing (e.g. FFmpeg)
- Multiplayer game servers
- Browser automation
- Batch data processing
- Python notebooks and data science workflows
- Managed CI/CD

This post compares Cloudflare Containers, Rivet Containers, and Fly Machines. Each platform targets different use cases and makes distinct architectural trade-offs.

## Platform Architecture

### Open Source and Self-Hosting

Having your container platform be open-source and self-hostable is important. Each of these platforms provide unique features that are not easily portable to other platforms, so being able to run your workloads on any cloud or on-prem is important.

**Cloudflare Containers**

Cloudflare Containers operates as a closed-source platform, requiring exclusive use of Cloudflare's infrastructure.

**Rivet Containers**

Rivet is the only open-source & self-hostable option among the three. This architectural choice gives Rivet users the flexibility to run workloads across any cloud provider or on their own infrastructure.

**Fly Machines**

Fly Machines is also closed source and tied to Fly's hosted infrastructure, requiring users to commit exclusively to Fly's infrastructure.

### Routing & Orchestration

Each platform takes a different approach to routing based on different levels of control.

**Cloudflare Containers**

Cloudflare Containers takes a unique approach to containers tailored towards the existing Cloudflare Workers primitives.

Each container is managed by a [Cloudflare Durable Object](https://developers.cloudflare.com/durable-objects/) that handles the container lifecycle & routing requests.

In order to route a user's request to a container, the request takes the route of: Worker → Durable Object → Container. This leverages the existing patterns on the Cloudflare platform of using Durable Objects' statefulness & fetch handlers in order to route requests to the container.

<img src={imgCfArch.src} alt="Routing architecture for Cloudflare Containers" />

In practice, Cloudflare Containers are created via Cloudflare's JavaScript API that's tightly integrated with the Cloudflare Worker's runtime:

```ts worker.ts
// Convenience API around the Durable Objects + Containers API
import { Container, getRandom } from "@cloudflare/containers";

class Backend extends Container {  // Container is a subclass of DurableObject
  defaultPort = 8080;
  sleepAfter = "2h";
}

export default {
	async fetch(request: Request, env: Env): Promise<Response> {
		// `getRandom` is used for location-aware pseudo load balancing to containers
		const containerInstance = getRandom(env.BACKEND, 3);

		// Call the Container (i.e. Durable Object) fetch handler
		return containerInstance.fetch(request);
	},
};
```

See the [Container package](https://github.com/cloudflare/containers) in the above example for more details.

This pattern allows JavaScript written for Cloudflare Workers to run at every network hop (e.g. at the edge & on the container), which allows for complex patterns like on-the-fly image resizing, on-demand AI sandbox servers, and more.

Cloudflare Containers only supports HTTP & WebSockets — not UDP & TCP.

**Rivet Containers**

Rivet provides a flexible option for running containers with robust network configuration, datacenter configurations, and optional Cloudflare Container-like orchestration. Rivet Containers can be created via a simple HTTP API from any language, instead of the proprietary JavaScript API like Cloudflare Containers. Additionally — unlike Cloudflare Containers, Rivet Containers also supports TCP & UDP connections.

A simple Rivet Container has a very straightforward architecture: containers are created via a simple HTTP API, then requests are proxied through Rivet Guard (the load balancer) and sent directly to the container itself.

<img src={imgRivetArchDirect.src} alt="Rivet architecture showing request going directly to a container" />

This architecture is ideal for basic applications that need containers on demand without extra boilerplate code or complex routing.

In order to provide more complicated patterns, Rivet Functions (similar to Cloudflare Workers) & Rivet Workers (similar to Cloudflare Durable Objects) can be used in combination with Rivet Containers. For example, Rivet Functions and Rivet Workers can be used to dynamically route requests to containers like this:

<img src={imgRivetArchWorker.src} alt="Rivet architecture showing request going to Rivet Function then to a Rivet Worker" />

This provides similar benefits to Cloudflare Containers, but allows you to use any language (not just Cloudflare-flavored JavaScript) for Rivet Functions and Rivet Workers.

In practice, using Rivet Containers looks like this:

```ts server.ts
import { RivetClient } from "@rivet-gg/api";

const client = new RivetClient();

// This launches your container on Rivet's infrastructure
const { actor } = await client.actors.create({
  project: "your-project",
  environment: "prod",
  body: {
    // Tags help identify this specific container instance
    tags: { name: "my-container" },
    
    // buildTags determine which container code to run
    buildTags: { name: "my-container", current: "true" },

	// Network & resource configuration
    network: {
      ports: { http: { protocol: "https" } }
    },
    resources: { cpu: 1000, memory: 1024 }
  }
});

// Connect to the container
await fetch(actor.network.ports.http.url);
```

**Fly Machines**

Fly Machines take a similar approach to Rivet Containers. Containers can be spun up via the [Fly Machines HTTP API](https://docs.machines.dev/#tag/machines/post/apps/{app_name}/machines), then requests are routed via the Fly Proxy.

<img src={imgFlyArch.src} alt="Fly Machines architecture showing request going to a Fly Machine" />

### Sleeping

Platforms handle container sleep and wake behavior differently, affecting performance and resource utilization.

**Cloudflare Containers**

Cloudflare Containers implement sleep behavior using [`sleepAfter` configuration](https://github.com/cloudflare/containers/blob/91c30342fd68fc36285b5d899c04815215970498/README.md#properties). Containers automatically sleep when they receive no network requests (unless otherwise configured) and are awoken by the parent Durable Object as needed (usually by a network request).

**Rivet Containers**

Rivet doesn't rely on snapshotting & sleep/wake patterns. Instead, the platform optimizes for fast coldstart times & optimizing image caches to ensure that containers can be booted on demand rapidly.

The reasoning for this comes from the dynamic workloads that are run on top of Rivet. While Cloudflare Containers & Fly Machines are optimized for pre-initialized containers, Rivet is frequently used with workloads that require user-defined builds, custom environment variables, or resource constraints that cannot be pre-configured and snapshotted.

Additionally, most applications do not find cost savings in sleeping when compared to intelligent autoscaling systems, as seen on Rivet Containers.

**Fly Machines**

Similar to Cloudflare Containers, Fly Machines implements VM snapshot and resume capabilities for sub-second warm starts, with auto-wake functionality that enables scale-to-zero operations on incoming requests.

### Storage and Persistence

Storage capabilities vary significantly across these platforms based on use case.

**Cloudflare Containers**

Cloudflare Containers currently offers no persistent volume support. It's generally recommended to use the Durable Objects persistence APIs (either KV or SQLite) in order to provide persistent storage for Cloudflare Containers.

**Rivet Containers**

Rivet Containers do not provide persistent file system storage, but natively support a KV API for long-term storage. (Persistent file systems for Rivet Workers & Rivet Containers are currently experimental.)

**Fly Machines**

Fly Machines offers Fly Volumes, which provide persistent storage.

## Runtime

### Scaling Strategies

Each platform approaches scaling with different philosophies and capabilities that reflect their target use cases.

**Cloudflare Containers**

Cloudflare Containers currently requires defining a fixed instance count at deployment time, though [autoscaling is on the roadmap](https://developers.cloudflare.com/containers/scaling-and-routing/#autoscaling-and-routing-unreleased). This approach requires over-provisioning resources for the given load.

**Rivet Containers**

Rivet Containers can either be created on-demand using the [containers API](https://rivet.dev/docs/cloud/api/actors/create) or autoscale as needed. Request- & resource-based autoscaling works by leveraging a tight integration between Rivet Guard and Rivet Containers. This can be configured using [routes](https://rivet.dev/docs/cloud/api/routes/update).

**Fly Machines**

Fly Machines uses a fixed instance count defined at deployment with load balancing and wake-on-request functionality — similar to Cloudflare. Fly also provides a [metrics-based autoscaler](https://fly.io/docs/launch/autoscale-by-metric/) that you can deploy yourself.

### Networking Capabilities

Networking capabilities vary significantly across platforms.

**Cloudflare Containers**

Cloudflare Containers are limited to HTTP and WebSocket protocols.

**Rivet Containers**

Rivet supports TCP, UDP, HTTP, and WebSockets.

**Fly Machines**

Fly Machines also supports TCP, UDP, HTTP, and WebSockets.

## Infrastructure

### Geographic Coverage

Geographic location of containers' datacenters is important to either:

- Minimize latency to users
- Run in the same datacenter as your existing infrastructure (e.g. databases on AWS).

**Cloudflare Containers**

Similar to Durable Objects, Containers run in a subset of Cloudflare datacenters. It's unclear which datacenters support Containers at the moment. For hints, you can [view which Cloudflare datacenters support Durable Objects](https://where.durableobjects.live/).

**Rivet Containers**

When using Rivet Containers, the datacenters available depend on how it's deployed. For example:

- Rivet Cloud supports 8 regions
- Rivet Cloud supports creating dedicated clusters in your provider & datacenter of choice
- Self-hosting Rivet enables you to run Rivet Containers anywhere

This flexibility is particularly valuable for organizations that need to co-locate Rivet Containers with existing infrastructure or with specific compliance requirements.

**Fly Machines**

Fly Machines [supports 35 regions](https://fly.io/docs/reference/regions/), but cannot be co-located on common public clouds such as AWS.

### On-Premises and Co-location

Network latency is often the primary performance bottleneck for distributed applications, making the ability to run containers near existing infrastructure crucial for optimal performance.

**Cloudflare Containers**

Cloudflare Containers cannot run within customer datacenters, limiting deployment options to Cloudflare's global network. Additionally, Durable Objects and containers may not co-locate in the same region, potentially introducing latency for tightly coupled applications that depend on both services.

**Rivet Containers**

Rivet supports co-locating, enabling containers to run alongside existing infrastructure whether in public clouds, private datacenters, or hybrid environments. This capability is important for applications that require low-latency access to databases or other services that cannot be easily moved to edge locations.

**Fly Machines**

Fly Machines does not support on-prem datacenter deployment, requiring all workloads to run on Fly's infrastructure. While their global network provides good coverage, this limitation is problematic for organizations with existing infrastructure or strict data residency requirements.

### Hardware Options

Hardware capabilities and configurations vary significantly across platforms.

**Cloudflare Containers**

Cloudflare Containers is currently [capped at 40 GB of RAM and 20 vCPUs per account](https://developers.cloudflare.com/containers/platform-details/#limits) while in beta. Containers can be configured with a [maximum of 1/2 CPU core and 4 GB of RAM per container](https://developers.cloudflare.com/containers/platform-details/#instance-types).

**Rivet Containers**

Rivet Cloud currently supports up to 4 CPU cores & 8 GB of RAM. Completely custom hardware configurations are available on dedicated clusters or with self-hosting. There are no limits on CPU or RAM per-account.

**Fly Machines**

Fly Machines can be configured with [up to 16 CPU cores and 128 GB of RAM](https://fly.io/docs/about/pricing/#running-fly-machines). There are no limits on CPU or RAM per-account.

## Operations

### API and Integration

Each platform has different ways of interacting with containers.

**Cloudflare Containers**

Cloudflare Containers lacks a direct container HTTP API, instead requiring full investment in the Workers and Durable Objects ecosystem with proprietary APIs.

This tight integration means developers must adopt Cloudflare's entire development model, and applications are limited to JavaScript and WebAssembly runtimes. This can limit flexibility for teams using other languages or architectural patterns.

Similarly, traffic to Cloudflare Containers must be routed via the Cloudflare Workers platform — Containers cannot be exposed directly to the internet. This provides the benefit of being secure-by-default, but adds complexity to setting up applications.

**Rivet Containers**

Rivet provides a straightforward REST API for container management that can be used with any language.

Rivet Containers can be accessed either via a public endpoint or privately via other Rivet Functions, Workers, or Containers.

**Fly Machines**

Fly Machines also offers a [REST API for machine management](https://docs.machines.dev/).

Fly Machines can be accessed via the public internet or via a private network.

### Local Development

Local development varies significantly across each platform.

**Cloudflare Containers**

Cloudflare Containers leverages the `wrangler dev` command providing a similar environment locally to what you'd expect in production. Containers are automatically built when running `wrangler dev`, making local dev very simple.

**Rivet Containers**

Rivet allows you to run a [complete Rivet cluster locally in one command](https://rivet.dev/docs/cloud/self-hosting/single-container) or within your own Docker Compose. This enables you to:

- Work with full feature parity to what you'll get in production
- Use the full suite of monitoring tools provided with Rivet.
- Easily write integration tests for Rivet

**Fly Machines**

Fly Machines currently lacks a dedicated local development solution, which requires developers to test their application against Fly's servers. This complicates development setups, iteration speed, and integration testing.

### Deployment and Image Management

All three platforms handle container image management, though they differ in their deployment workflows and constraints.

**Cloudflare Containers**

Cloudflare Containers streamlines deployment through the familiar wrangler toolchain, supporting both `wrangler container push` for one-off image pushes and `wrangler deploy` for full deploys. Images are pushed and stored for you in the Cloudflare Registry. Cloudflare [limits image sizes to 2 GB](https://developers.cloudflare.com/containers/image-management/#registry-limits).

**Rivet Containers**

Rivet supports one-off image pushes with `rivet build publish` or full deploys with `rivet deploy`. Rivet provides image hosting for you with a 10 GB image limit.

**Fly Machines**

Fly also provides a registry for storing your images. The Fly [image size limit is 8 GB](https://community.fly.io/t/docker-image-size-limit-raised-from-2gb-to-8gb/14749).

### SSH Access

Remote access capabilities vary significantly across platforms, affecting debugging and administration workflows.

**Cloudflare Containers**

Cloudflare Containers does not provide SSH access, requiring developers to rely on logging and the Cloudflare dashboard for troubleshooting and administration.

**Rivet Containers**

Rivet supports full SSH access via an SSH daemon running within the container. This is opt-in and must be configured in your Dockerfile.

**Fly Machines**

Fly Machines enables partial SSH access via the `flyctl ssh console` command and SFTP via `flyctl ssh sftp`. However, this lacks common SSH functionality such as port forwarding.

### Rolling Deployments

Deployment strategies reflect each platform's approach to balancing availability, safety, and operational control.

**Cloudflare Containers**

Cloudflare Containers have an automatic rolling deploy.

_Note that Durable Objects currently deploy inconsistently with containers. Read more [here](https://developers.cloudflare.com/containers/beta-info/#atomic-code-updates-across-workers-and-containers) on caveats with synchronizing Durable Objects & Container versions._

**Rivet Containers**

Rivet offers flexibility on deployment options. By default, containers are upgraded immediately.

Upgrades can be controlled manually by using the upgrade API to selectively upgrade containers. This can be combined with actor tagging to build sophisticated deployment strategies — which are often important for stateful workloads like agents, batch jobs, game servers, and more.

**Fly Machines**

Fly Machines support [rolling, immediate, canary, and blue/green deployment strategies](https://fly.io/docs/launch/deploy/#deployment-strategy).

## Key Considerations

### Multi-Tenant Support

Multi-tenant capabilities are critical for sandboxed AI execution, user-generated content platforms, untrusted code execution, and user-defined functions. This requires allowing users to upload arbitrary Docker builds and run them on demand.

**Cloudflare Containers**

Cloudflare Containers is locked to run the build that you last deployed. It is not possible to run arbitrary user builds. This limitation significantly impacts use cases like AI-generated app hosting, code execution platforms, or SaaS applications serving multiple customers.

**Rivet Containers**

Rivet provides multi-tenant support with built-in tagging systems for container and build organization. This functionality enables clean separation of workloads, making it ideal for platforms that serve multiple customers or need to isolate different execution contexts securely.

**Fly Machines**

Fly Machines provides a flexible API for managing machines and their respective builds, allowing applications to serve multiple customers while maintaining appropriate separation and security boundaries.

### Database Co-location

Database proximity significantly impacts application performance, especially for data-intensive workloads.

**Cloudflare Containers**

Cloudflare Containers cannot co-locate with databases in customer-controlled datacenters, adding significant latency for many applications. This limitation is particularly problematic for applications using services specific to certain cloud providers or on-premises databases.

**Rivet Containers**

Rivet's hybrid clusters & self-hosting capabilities enable full co-location capabilities, allowing containers to run in the same datacenter as existing databases and infrastructure for optimal performance.

**Fly Machines**

Fly Machines cannot co-locate with databases in customer-controlled datacenters, potentially adding significant latency for applications that require high-speed database access. This requires all infrastructure to be hosted on Fly.io if co-location is required.

## Pricing

**Cloudflare Containers**

Cloudflare Containers use a usage-based model charging $0.000020 per vCPU-second for CPU time, $0.0000025 per GB-second for memory, and $0.00000007 per GB-second for ephemeral disk. Bandwidth egress is charged separately, though specific pricing details are not publicly disclosed. [See pricing](https://developers.cloudflare.com/containers/pricing/).

**Rivet Containers**

Rivet Cloud offers usage-based pricing where compute is billed at $0.00000001119 per core-millisecond. This single rate covers both CPU and memory usage. Bandwidth egress is charged at $0.05 per GB. [See pricing](/pricing).

Rivet can also be self-hosted on your own infra to leverage budget cloud providers such as Hetzner.

**Fly Machines**

Fly Machines use usage-based VM pricing based on machine sizes. Network bandwidth is metered separately, though basic usage includes a free allowance. [See pricing](https://fly.io/docs/about/pricing/).

**Cost Comparison**

For a container with 1 vCPU, 2 GB RAM, and 50 GB ephemeral storage:

| Platform                          | Monthly Cost | Hourly Cost  | CPU                                                 | Memory                                      | Storage                                      | Bandwidth                    |
| --------------------------------- | ------------ | ------------ | --------------------------------------------------- | ------------------------------------------- | -------------------------------------------- | ---------------------------- |
| **Cloudflare Containers**         | **$74.90**   | **$0.103**   | $52.56 (`$0.000020 × 2,628,000s`)                   | $13.14 (`$0.0000025 × 2 GB × 2,628,000s`)    | $9.20 (`$0.00000007 × 50 GB × 2,628,000 s`) | not yet published            |
| **Rivet Containers**              | **$29.40**   | **$0.0402**  | $29.38 (`$0.00000001119 × 1 000 ms × 2,628,000 s`)  | included                                    | included                                     | $0.05 / GB                   |
| **Fly Machines (performance-1x)** | **$31.00**   | **$0.0431**  | $52.61 (fixed VM rate)                              | included                                    | included                                     | $0.02–$0.12 / GB by region   |

**Sleeping & Cost Impact**

Calculations assume continuous 24/7 operation and does not factor in sleeping that Cloudflare & Fly provides. Most applications do not benefit from cost savings with sleeping compared to autoscaling, as seen with Rivet Containers.

## Conclusion

**Cloudflare Containers** is a strong platform if you're already heavily invested in the Cloudflare Workers ecosystem and can benefit from container sleeping.

**Rivet Containers** is a great choice if you need very flexible container configurations, open-source infrastructure, on-premise deployments, multi-tenant support, or want to co-locate with existing infrastructure.

**Fly Machines** is a strong choice for applications that need dozens of points of presence, don't require on-premise deployment, and require persistent storage.

_Mistakes happen, please message me on [X](https://x.com/NathanFlurry/) or [Bluesky](https://bsky.app/profile/nathanflurry.com) if you find any._

