Container Instance Disk Limits Removed – Up to 20 GB per Custom Type

Cloudflare Containers now removes the previous 2 GB‑per‑GiB memory ceiling on disk for custom instance types, allowing any custom type to claim the full 20 GB disk limit. This change lets you size disk independently of memory, which matters for workloads that are disk‑heavy but memory‑light, such as large images, data sets, or build caches.

What changed for container instance disk limit

Earlier, a custom instance could not exceed a 2 GB disk allocation for each 1 GiB of memory. The platform also enforced a minimum of 3 GiB memory per vCPU. The new policy lifts the disk‑to‑memory ratio, keeping the 20 GB absolute disk cap but removing the proportional restriction. All other custom instance constraints remain unchanged.

Why the change matters to engineers and operators

AI, cloud, and DevOps teams often run containers that need more persistent storage than RAM. With the old limit, a 3 GiB container could only attach 6 GB of disk, forcing you to downsize images or split data across multiple containers. The new flexibility means you can keep a single container for tasks like model artifact caching, dataset staging, or CI build caches without hitting an artificial disk ceiling.

Practical implications

• Configuration simplicity: You can now declare the desired disk size directly in wrangler.jsonc or wrangler.toml without calculating a memory‑based ceiling. Example configuration:

  {
    "containers": [
      {
        "image": "./Dockerfile",
        "instance_type": {
          "vcpu": 1,
          "memory_mib": 3072,
          "disk_mb": 20000
        }
      }
    ]
  }
  

• Larger container images: The maximum image size now matches the allocated disk, so a 20 GB disk permits a 20 GB image, removing the need to trim layers for memory‑constrained instances.
• Resource planning: While disk can be maxed out regardless of memory, you still need to respect the minimum 3 GiB per vCPU rule. Planning should ensure that vCPU counts, memory, and disk are balanced for cost and performance.
• Operational monitoring: With more disk available, monitoring disk consumption becomes more critical to avoid unexpected exhaustion, especially for workloads that write large temporary files.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

Review any existing custom instance definitions that were constrained by the old ratio and adjust disk_mb to the size your workload actually needs, up to 20 GB. Validate that your CI/CD pipelines, image build processes, and runtime scripts can handle the larger disk footprint. Finally, update monitoring dashboards to track disk usage independently of memory, ensuring you catch any runaway storage consumption before it impacts service availability.