Promo Image

Container Platform Comparison: Cloudflare Containers vs Rivet Containers vs Fly Machines

Rivet is an open-source, self-hostable serverless alternative to Cloudflare Workers, Durable Objects, and Containers. Check out Rivet Containers and visit our GitHub.

Cloudflare just launched Cloudflare Containers, a platform with many similarities to Rivet Containers and Fly 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 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.

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:

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 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.

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:

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:

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, then requests are routed via the Fly Proxy.

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. 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. This approach requires over-provisioning resources for the given load.

Rivet Containers

Rivet Containers can either be created on-demand using the containers API 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.

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 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.

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, 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 while in beta. Containers can be configured with a maximum of 1/2 CPU core and 4 GB of RAM per container.

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. 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.

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 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.

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.

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 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.


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.

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.

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.

Cost Comparison

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

PlatformMonthly CostHourly CostCPUMemoryStorageBandwidth
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)includedincluded$0.05 / GB
Fly Machines (performance-1x)$31.00$0.0431$52.61 (fixed VM rate)includedincluded$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 or Bluesky if you find any.