How Cloudflare Containers Bridge the Gap Between Serverless and Traditional Deployments

Cloudflare has introduced a game-changing addition to their platform: Cloudflare Containers. This new offering fills a critical gap between lightweight serverless functions and traditional container infrastructure, bringing the best of both worlds to developers who need more computational power at the edge without sacrificing simplicity.

Unlike traditional container orchestration platforms that require complex management of infrastructure, Cloudflare Containers integrate seamlessly with Workers and Durable Objects, creating a powerful yet easy-to-use system for deploying applications that need more resources than what typical serverless functions can provide.

What Makes Cloudflare Containers Different?

Cloudflare Containers aren't just another container hosting service. They represent a unique approach that combines the flexibility of Docker containers with the simplicity and global distribution of Cloudflare's edge network. Here's what sets them apart:

No Kubernetes management - deploy containers with simple JavaScript
On-demand scaling - containers spin up where and when needed
Auto-sleep functionality - containers shut down when idle to optimize costs
Tight integration with Cloudflare Workers and Durable Objects
Global distribution across Cloudflare's edge network

This approach allows developers to run resource-intensive workloads like FFmpeg video processing at the edge without managing complex infrastructure. The containers are essentially managed by Durable Objects, which handle container lifecycle and communication.

Real-World Example: Building a Video Processing Application

Let's explore a practical implementation of Cloudflare Containers by building a simple application called "BetterEdit" that removes silences from video files using FFmpeg - something that wouldn't be possible with standard Workers due to their computational limitations.

The Container Implementation

Our container consists of a simple Bun server with two endpoints: a status endpoint for health checks and a process endpoint that handles the video processing logic.

The container is defined in a Dockerfile that uses Bun as the base image and installs FFmpeg to handle video processing:

DOCKERFILE

FROM oven/bun:latest

# Install FFmpeg
RUN apt-get update && apt-get install -y ffmpeg

# Copy application files
WORKDIR /app
COPY . .

# Install dependencies
RUN bun install

# Run the application
CMD ["bun", "run", "server.js"]

The Worker Implementation

The Worker code handles routing and container management. It's remarkably concise - just 23 lines of code that manage the entire container lifecycle and request routing:

TYPESCRIPT

export class BetterEditContainer extends Container {
  constructor(state, env) {
    super(state, env);
    this.port = 8080;
    this.sleepAfter = 300; // 5 minutes
  }

  async onStart() {
    console.log('Container starting');
  }

  async onStop() {
    console.log('Container stopping');
  }

  async onError(error) {
    console.error('Container error:', error);
  }
}

export default {
  async fetch(request, env) {
    const container = await env.CONTAINERS.get(getRandom());
    return container.fetch(request);
  }
};

The BetterEditContainer class extends the Container class (which is a Durable Object). It configures the container to use port 8080 and sets it to sleep after 5 minutes of inactivity to optimize costs. The fetch handler simply forwards requests to the container.

Configuration with Wrangler

The final piece is the Wrangler configuration file that ties everything together:

TOML

name = "betteredit"
src = "src/index.ts"

[container]
max_instances = 3
name = "betteredit"
class_name = "BetterEditContainer"
image = { dockerfile = "Dockerfile" }
instance_type = "c-4gb-1vcpu"

[durable_objects]
classes = [
  { name = "BetterEditContainer", class_name = "BetterEditContainer" }
]

[site]
assets_dir = "public"

[observability]
log_level = "debug"

This configuration specifies important parameters like the maximum number of container instances (3), the container class name, the Docker image to use, and the instance type (c-4gb-1vcpu, which provides 4GB of RAM and 1 virtual CPU).

The deployment process builds and pushes the container image to Cloudflare's infrastructure

Monitoring and Managing Containers

Cloudflare provides comprehensive monitoring tools for your containers through their dashboard. You can view active instances, resource usage, and logs in real-time.

The Cloudflare dashboard showing the active container instance with monitoring metrics

The dashboard provides visibility into important metrics like memory usage, CPU load, and instance status. You can also drill down into individual container instances to view detailed metrics and logs.

Current Limitations and Pricing

As Cloudflare Containers are currently in beta, there are some limitations to be aware of:

40GB memory limit across all concurrent container instances
20 virtual CPUs across all concurrent container instances
100GB storage limit across all container instances
Maximum image size of 2GB
Total image storage per account of 50GB

Regarding pricing, Cloudflare includes 25GB-hours per month with paid Workers plans. Beyond that, additional usage is billed per GB-second for memory, per vCPU-second for compute, and per GB for storage. While exact pricing comparisons are difficult, some analyses suggest Cloudflare Containers may be more expensive than alternatives like Fly.io or Rivet for long-running workloads.

However, the pricing model makes sense for bursty workloads where containers can sleep when not in use, potentially making it very cost-effective for certain use cases.

When to Choose Cloudflare Containers

Cloudflare Containers are particularly well-suited for specific scenarios:

When you need to run resource-intensive workloads that won't fit in Workers
For applications that benefit from tight integration with Cloudflare's ecosystem
When you want the simplicity of serverless with the power of containers
For bursty workloads where containers can sleep when not in use
When you need global distribution without managing complex infrastructure

Conclusion

Cloudflare Containers represent an exciting evolution in the cloud computing landscape, bridging the gap between lightweight serverless functions and traditional container infrastructure. By combining the power of Docker containers with the simplicity and global distribution of Cloudflare's edge network, they enable developers to build more complex applications without sacrificing developer experience.

While still in beta with some limitations, Cloudflare Containers show tremendous promise for applications that need more computational resources than Workers can provide but don't want the complexity of managing Kubernetes clusters. As the platform matures, we can expect to see even more powerful capabilities and optimizations.

Whether you're processing videos with FFmpeg, running machine learning models, or handling other resource-intensive tasks, Cloudflare Containers provide a compelling option for deploying your applications at the edge with minimal operational overhead.

How Cloudflare Containers Bridge the Gap Between Serverless Functions and Traditional Container Deployments