---
title: Containers Changelog
image: https://developers.cloudflare.com/cf-twitter-card.png
---

> Documentation Index  
> Fetch the complete documentation index at: https://developers.cloudflare.com/changelog/llms.txt  
> Use this file to discover all available pages before exploring further.

[Skip to content](#%5Ftop) 

# Changelog

New updates and improvements at Cloudflare.

[ Subscribe to RSS ](https://developers.cloudflare.com/changelog/rss/index.xml) [ View RSS feeds ](https://developers.cloudflare.com/fundamentals/new-features/available-rss-feeds/) 

Containers

![hero image](https://developers.cloudflare.com/_astro/hero.CVYJHPAd_26AMqX.svg) 

Apr 21, 2026
1. ### [Container logs page now includes relevant Worker and Durable Object logs](https://developers.cloudflare.com/changelog/post/2026-04-21-correlated-worker-durable-object-logs/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
The Container logs page now displays related [Worker](https://developers.cloudflare.com/workers/) and [Durable Object](https://developers.cloudflare.com/durable-objects/) logs alongside container logs. This co-locates all relevant log events for a container application in one place, making it easier to trace requests and debug issues.  
![Container logs page showing Worker and Durable Object logs alongside container logs](https://developers.cloudflare.com/_astro/container-worker-logs.BBQ7NRse_1cLVb3.webp)  
You can filter to a single source when you need to isolate Container, Worker, or Durable Object output.  
For information on configuring container logging, refer to [How do Container logs work?](https://developers.cloudflare.com/containers/faq/#how-do-container-logs-work).

Apr 13, 2026
1. ### [Containers and Sandboxes are now generally available](https://developers.cloudflare.com/changelog/post/2026-04-13-containers-sandbox-ga/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
Cloudflare [Containers](https://developers.cloudflare.com/containers/) and [Sandboxes](https://developers.cloudflare.com/sandbox/) are now generally available.  
Containers let you run more workloads on the Workers platform, including resource-intensive applications, different languages, and CLI tools that need full Linux environments.  
Since the initial launch of Containers, there have been significant improvements to Containers' performance, stability, and feature set. Some highlights include:  
   * [Higher limits](https://developers.cloudflare.com/changelog/post/2026-02-25-higher-container-resource-limits/) allow you to run thousands of containers concurrently.  
   * [Active-CPU pricing](https://developers.cloudflare.com/changelog/post/2025-11-21-new-cpu-pricing/) means that you only pay for used CPU cycles.  
   * [Easy connections to Workers and other bindings](https://developers.cloudflare.com/changelog/post/2026-03-26-outbound-workers/) via hostnames help you extend your Containers with additional functionality.  
   * [Docker Hub support](https://developers.cloudflare.com/changelog/post/2026-03-24-docker-hub-images/) makes it easy to use your existing images and registries.  
   * [SSH support](https://developers.cloudflare.com/changelog/post/2026-03-12-ssh-support/) helps you access and debug issues in live containers.  
The [Sandbox SDK](https://developers.cloudflare.com/sandbox/) provides isolated environments for running untrusted code securely, with a simple TypeScript API for executing commands, managing files, and exposing services. This makes it easier to secure and manage your agents at scale. Some additions since launch include:  
   * [Live preview URLs](https://developers.cloudflare.com/changelog/post/2025-08-05-sandbox-sdk-major-update/) so agents can run long-lived services and verify in-flight changes.  
   * [Persistent code interpreters](https://developers.cloudflare.com/changelog/post/2025-08-05-sandbox-sdk-major-update/) for Python, JavaScript, and TypeScript, with rich structured outputs.  
   * [Interactive PTY terminals](https://developers.cloudflare.com/changelog/post/2026-02-09-pty-terminal-support/) for real browser-based terminal access with multiple isolated shells per sandbox.  
   * [Backup and restore APIs](https://developers.cloudflare.com/changelog/post/2026-02-23-sandbox-backup-restore-api/) to snapshot a workspace and quickly restore an agent's coding session without repeating expensive setup steps.  
   * [Real-time filesystem watching](https://developers.cloudflare.com/changelog/post/2026-03-03-sandbox-watch-file-events/) so apps and agents can react immediately to file changes inside a sandbox.  
For more information, refer to [Containers](https://developers.cloudflare.com/containers/) and [Sandbox SDK](https://developers.cloudflare.com/sandbox/) documentation.

Apr 13, 2026
1. ### [Secure credential injection and dynamic egress policies for Sandboxes](https://developers.cloudflare.com/changelog/post/2026-04-13-sandbox-outbound-workers-tls-auth/)  
[ Containers ](https://developers.cloudflare.com/containers/)[ Agents ](https://developers.cloudflare.com/agents/)  
Outbound Workers for [Sandboxes](https://developers.cloudflare.com/sandbox/) and [Containers](https://developers.cloudflare.com/containers/) now support zero-trust credential injection, TLS interception, allow/deny lists, and dynamic per-instance egress policies. These features give platforms running agentic workloads full control over what leaves the sandbox, without exposing secrets to untrusted workloads, like user-generated code or coding agents.  
#### Credential injection  
Because outbound handlers run in the Workers runtime, outside the sandbox, they can hold secrets the sandbox never sees. A sandboxed workload can make a plain request, and credentials are transparently attached before a request is forwarded upstream.  
For instance, you could run an agent in a sandbox and ensure that any requests it makes to Github are authenticated. But it will never be able to access the credentials:  
TypeScript  
```  
export class MySandbox extends Sandbox {}  
MySandbox.outboundByHost = {  
  "github.com": (request: Request, env: Env, ctx: OutboundHandlerContext) => {  
    const requestWithAuth = new Request(request);  
    requestWithAuth.headers.set("x-auth-token", env.SECRET);  
    return fetch(requestWithAuth);  
  },  
};  
```  
You can easily inject unique credentials for different instances by using `ctx.containerId`:  
TypeScript  
```  
MySandbox.outboundByHost = {  
  "my-internal-vcs.dev": async (  
    request: Request,  
    env: Env,  
    ctx: OutboundHandlerContext,  
  ) => {  
    const authKey = await env.KEYS.get(ctx.containerId);  
    const requestWithAuth = new Request(request);  
    requestWithAuth.headers.set("x-auth-token", authKey);  
    return fetch(requestWithAuth);  
  },  
};  
```  
No token is ever passed into the sandbox. You can rotate secrets in the Worker environment and every request will pick them up immediately.  
#### TLS interception  
Outbound Workers now intercept HTTPS traffic. A unique ephemeral certificate authority (CA) and private key are created for each sandbox instance. The CA is placed into the sandbox and trusted by default. The ephemeral private key never leaves the container runtime sidecar process and is never shared across instances.  
With TLS interception active, outbound Workers can act as a transparent proxy for both HTTP and HTTPS traffic.  
#### Allow and deny hosts  
Easily filter outbound traffic with `allowedHosts` and `deniedHosts`. When `allowedHosts` is set, it becomes a deny-by-default allowlist. Both properties support glob patterns.  
TypeScript  
```  
export class MySandbox extends Sandbox {  
  allowedHosts = ["github.com", "npmjs.org"];  
}  
```  
#### Dynamic outbound handlers  
Define named outbound handlers then apply or remove them at runtime using `setOutboundHandler()` or `setOutboundByHost()`. This lets you change egress policy for a running sandbox without restarting it.  
TypeScript  
```  
export class MySandbox extends Sandbox {}  
MySandbox.outboundHandlers = {  
  allowHosts: async (req: Request, env: Env, ctx: OutboundHandlerContext ) => {  
    const url = new URL(req.url);  
    if (ctx.params.allowedHostnames.includes(url.hostname)) {  
      return fetch(req);  
    }  
    return new Response(null, { status: 403 });  
  },  
  noHttp: async () => {  
    return new Response(null, { status: 403 });  
  },  
};  
```  
Apply handlers programmatically from your Worker:  
TypeScript  
```  
const sandbox = getSandbox(env.Sandbox, userId);  
// Open network for setup  
await sandbox.setOutboundHandler("allowHosts", {  
  allowedHostnames: ["github.com", "npmjs.org"],  
});  
await sandbox.exec("npm install");  
// Lock down after setup  
await sandbox.setOutboundHandler("noHttp");  
```  
Handlers accept `params`, so you can customize behavior per instance without defining separate handler functions.  
#### Get started  
Upgrade to `@cloudflare/containers@0.3.0` or `@cloudflare/sandbox@0.8.9` to use these features.  
For more details, refer to [Sandbox outbound traffic](https://developers.cloudflare.com/sandbox/guides/outbound-traffic/) and [Container outbound traffic](https://developers.cloudflare.com/containers/platform-details/outbound-traffic/).

Apr 05, 2026
1. ### [Control where your Containers run with regional and jurisdictional placement](https://developers.cloudflare.com/changelog/post/2026-04-05-regional-placement/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
You can now specify placement constraints to control where your [Containers](https://developers.cloudflare.com/containers/) run.  
| Constraint   | Values                 | Use case              |  
| ------------ | ---------------------- | --------------------- |  
| regions      | ENAM, WNAM, EEUR, WEUR | Geographic placement  |  
| jurisdiction | eu, fedramp            | Compliance boundaries |  
Use `regions` to limit placement to specific geographic areas. Use `jurisdiction` to restrict containers to compliance boundaries — `eu` maps to European regions (EEUR, WEUR) and `fedramp` maps to North American regions (ENAM, WNAM).  
Refer to [Containers placement](https://developers.cloudflare.com/containers/platform-details/placement/) for more details.

Mar 26, 2026
1. ### [Easily connect Containers and Sandboxes to Workers](https://developers.cloudflare.com/changelog/post/2026-03-26-outbound-workers/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
[Containers](https://developers.cloudflare.com/containers/) and [Sandboxes](https://developers.cloudflare.com/sandbox/) now support connecting directly to Workers over HTTP. This allows you to call Workers functions and [bindings](https://developers.cloudflare.com/workers/runtime-apis/bindings/), like [KV](https://developers.cloudflare.com/kv) or [R2](https://developers.cloudflare.com/r2/), from within the container at specific hostnames.  
#### Run Worker code  
Define an `outbound` handler to capture any HTTP request or use `outboundByHost` to capture requests to individual hostnames and IPs.  
JavaScript  
```  
export class MyApp extends Sandbox {}  
MyApp.outbound = async (request, env, ctx) => {  
  // you can run arbitrary functions defined in your Worker on any HTTP request  
  return await someWorkersFunction(request.body);  
};  
MyApp.outboundByHost = {  
  "my.worker": async (request, env, ctx) => {  
    return await anotherFunction(request.body);  
  },  
};  
```  
In this example, requests from the container to `http://my.worker` will run the function defined within `outboundByHost`, and any other HTTP requests will run the `outbound` handler. These handlers run entirely inside the Workers runtime, outside of the container sandbox.  
#### Access Workers bindings  
Each handler has access to `env`, so it can call any binding set in [Wrangler config](https://developers.cloudflare.com/workers/wrangler/configuration/#bindings). Code inside the container makes a standard HTTP request to that hostname and the outbound Worker translates it into a binding call.  
JavaScript  
```  
export class MyApp extends Sandbox {}  
MyApp.outboundByHost = {  
  "my.kv": async (request, env, ctx) => {  
    const key = new URL(request.url).pathname.slice(1);  
    const value = await env.KV.get(key);  
    return new Response(value ?? "", { status: value ? 200 : 404 });  
  },  
  "my.r2": async (request, env, ctx) => {  
    const key = new URL(request.url).pathname.slice(1);  
    const object = await env.BUCKET.get(key);  
    return new Response(object?.body ?? "", { status: object ? 200 : 404 });  
  },  
};  
```  
Now, from inside the container sandbox, `curl http://my.kv/some-key` will access [Workers KV](https://developers.cloudflare.com/kv) and `curl http://my.r2/some-object` will access [R2](https://developers.cloudflare.com/r2/).  
#### Access Durable Object state  
Use `ctx.containerId` to reference the container's automatically provisioned [Durable Object](https://developers.cloudflare.com/durable-objects).  
JavaScript  
```  
export class MyContainer extends Container {}  
MyContainer.outboundByHost = {  
  "get-state.do": async (request, env, ctx) => {  
    const id = env.MY_CONTAINER.idFromString(ctx.containerId);  
    const stub = env.MY_CONTAINER.get(id);  
    return stub.getStateForKey(request.body);  
  },  
};  
```  
This provides an easy way to associate state with any container instance, and includes a [built-in SQLite database](https://developers.cloudflare.com/durable-objects/get-started/#2-write-a-durable-object-class-using-sql-api).  
#### Get Started Today  
Upgrade to `@cloudflare/containers` version 0.2.0 or later, or `@cloudflare/sandbox` version 0.8.0 or later to use outbound Workers.  
Refer to [Containers outbound traffic](https://developers.cloudflare.com/containers/platform-details/outbound-traffic/) and [Sandboxes outbound traffic](https://developers.cloudflare.com/sandbox/guides/outbound-traffic/) for more details and examples.

Mar 24, 2026
1. ### [Use Docker Hub images with Containers](https://developers.cloudflare.com/changelog/post/2026-03-24-docker-hub-images/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
Containers now support [Docker Hub ↗](https://hub.docker.com/) images. You can use a fully qualified Docker Hub image reference in your [Wrangler configuration ↗](https://developers.cloudflare.com/workers/wrangler/configuration/#containers) instead of first pushing the image to Cloudflare Registry.  
   * [  wrangler.jsonc ](#tab-panel-756)  
   * [  wrangler.toml ](#tab-panel-757)  
JSONC  
```  
{  
  "containers": [  
    {  
      // Example: docker.io/cloudflare/sandbox:0.7.18  
      "image": "docker.io/<NAMESPACE>/<REPOSITORY>:<TAG>",  
    },  
  ],  
}  
```  
TOML  
```  
[[containers]]  
image = "docker.io/<NAMESPACE>/<REPOSITORY>:<TAG>"  
```  
Containers also support private Docker Hub images. To configure credentials, refer to [Use private Docker Hub images](https://developers.cloudflare.com/containers/platform-details/image-management/#use-private-docker-hub-images).  
For more information, refer to [Image management](https://developers.cloudflare.com/containers/platform-details/image-management/).

Mar 12, 2026
1. ### [SSH into running Container instances](https://developers.cloudflare.com/changelog/post/2026-03-12-ssh-support/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
You can now SSH into running Container instances using Wrangler. This is useful for debugging, inspecting running processes, or executing one-off commands inside a Container.  
To connect, enable `wrangler_ssh` in your Container configuration and add your `ssh-ed25519` public key to `authorized_keys`:  
   * [  wrangler.jsonc ](#tab-panel-758)  
   * [  wrangler.toml ](#tab-panel-759)  
JSONC  
```  
{  
  "containers": [  
    {  
      "wrangler_ssh": {  
        "enabled": true  
      },  
      "authorized_keys": [  
        {  
          "name": "<NAME>",  
          "public_key": "<YOUR_PUBLIC_KEY_HERE>"  
        }  
      ]  
    }  
  ]  
}  
```  
TOML  
```  
[[containers]]  
[containers.wrangler_ssh]  
enabled = true  
[[containers.authorized_keys]]  
name = "<NAME>"  
public_key = "<YOUR_PUBLIC_KEY_HERE>"  
```  
Then connect with:  
Terminal window  
```  
wrangler containers ssh <INSTANCE_ID>  
```  
You can also run a single command without opening an interactive shell:  
Terminal window  
```  
wrangler containers ssh <INSTANCE_ID> -- ls -al  
```  
Use `wrangler containers instances <APPLICATION>` to find the instance ID for a running Container.  
For more information, refer to the [SSH documentation](https://developers.cloudflare.com/containers/ssh/).

Mar 12, 2026
1. ### [List Container instances with \`wrangler containers instances\`](https://developers.cloudflare.com/changelog/post/2026-03-12-wrangler-containers-instances/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
A new [wrangler containers instances](https://developers.cloudflare.com/workers/wrangler/commands/containers/#containers-instances) command lists all instances for a given Container application. This mirrors the instances view in the Cloudflare dashboard.  
The command displays each instance's ID, name, state, location, version, and creation time:  
Terminal window  
```  
wrangler containers instances <APPLICATION_ID>  
```  
Use the `--json` flag for machine-readable output, which is also the default format in non-interactive environments such as CI pipelines.  
For the full list of options, refer to the [containers instances command reference](https://developers.cloudflare.com/workers/wrangler/commands/containers/#containers-instances).

Feb 25, 2026
1. ### [Run 15x more Containers with higher resource limits](https://developers.cloudflare.com/changelog/post/2026-02-25-higher-container-resource-limits/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
You can now run more [Containers](https://developers.cloudflare.com/containers/) concurrently with significantly higher limits on memory, vCPU, and disk.  
| Limit                                          | Previous Limit | New Limit |  
| ---------------------------------------------- | -------------- | --------- |  
| Memory for concurrent live Container instances | 400GiB         | 6TiB      |  
| vCPU for concurrent live Container instances   | 100            | 1,500     |  
| Disk for concurrent live Container instances   | 2TB            | 30TB      |  
This 15x increase enables larger-scale workloads on Containers. You can now run 15,000 instances of the `lite` instance type, 6,000 instances of `basic`, over 1,500 instances of `standard-1`, or over 1,000 instances of `standard-2` concurrently.  
Refer to [Limits](https://developers.cloudflare.com/containers/platform-details/limits/) for more details on the available instance types and limits.

Feb 23, 2026
1. ### [Backup and restore API for Sandbox SDK](https://developers.cloudflare.com/changelog/post/2026-02-23-sandbox-backup-restore-api/)  
[ Agents ](https://developers.cloudflare.com/agents/)[ R2 ](https://developers.cloudflare.com/r2/)[ Containers ](https://developers.cloudflare.com/containers/)  
[Sandboxes](https://developers.cloudflare.com/sandbox/) now support `createBackup()` and `restoreBackup()` methods for creating and restoring point-in-time snapshots of directories.  
This allows you to restore environments quickly. For instance, in order to develop in a sandbox, you may need to include a user's codebase and run a build step. Unfortunately `git clone` and `npm install` can take minutes, and you don't want to run these steps every time the user starts their sandbox.  
Now, after the initial setup, you can just call `createBackup()`, then `restoreBackup()` the next time this environment is needed. This makes it practical to pick up exactly where a user left off, even after days of inactivity, without repeating expensive setup steps.  
TypeScript  
```  
const sandbox = getSandbox(env.Sandbox, "my-sandbox");  
// Make non-trivial changes to the file system  
await sandbox.gitCheckout(endUserRepo, { targetDir: "/workspace" });  
await sandbox.exec("npm install", { cwd: "/workspace" });  
// Create a point-in-time backup of the directory  
const backup = await sandbox.createBackup({ dir: "/workspace" });  
// Store the handle for later use  
await env.KV.put(`backup:${userId}`, JSON.stringify(backup));  
// ... in a future session...  
// Restore instead of re-cloning and reinstalling  
await sandbox.restoreBackup(backup);  
```  
Backups are stored in [R2](https://developers.cloudflare.com/r2) and can take advantage of [R2 object lifecycle rules](https://developers.cloudflare.com/sandbox/guides/backup-restore/#configure-r2-lifecycle-rules-for-automatic-cleanup) to ensure they do not persist forever.  
Key capabilities:  
   * **Persist and reuse across sandbox sessions** — Easily store backup handles in KV, D1, or Durable Object storage for use in subsequent sessions  
   * **Usable across multiple instances** — Fork a backup across many sandboxes for parallel work  
   * **Named backups** — Provide optional human-readable labels for easier management  
   * **TTLs** — Set time-to-live durations so backups are automatically removed from storage once they are no longer needed  
Note  
Backup and restore currently uses a FUSE overlay. Soon, native snapshotting at a lower level will be added to Containers and Sandboxes, improving speed and ergonomics. The current backup functionality provides a significant speed improvement over manually recreating a file system, but it will be further optimized in the future. The new snapshotting system will use a similar API, so changing to this system will be simple once it is available.  
To get started, refer to the [backup and restore guide](https://developers.cloudflare.com/sandbox/guides/backup-restore/) for setup instructions and usage patterns, or the [Backups API reference](https://developers.cloudflare.com/sandbox/api/backups/) for full method documentation.

Feb 17, 2026
1. ### [Docker-in-Docker support added to Containers and Sandboxes](https://developers.cloudflare.com/changelog/post/2026-02-17-docker-in-docker/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
[Sandboxes](https://developers.cloudflare.com/sandbox/) and [Containers](https://developers.cloudflare.com/containers/) now support running Docker for "Docker-in-Docker" setups. This is particularly useful when your end users or [agents](https://developers.cloudflare.com/agents) want to run a full sandboxed development environment.  
This allows you to:  
   * Develop containerized applications with your Sandbox  
   * Run isolated test environments for images  
   * Build container images as part of CI/CD workflows  
   * Deploy arbitrary images supplied at runtime within a container  
For [Sandbox SDK](https://developers.cloudflare.com/sandbox/) users, see the [Docker-in-Docker guide](https://developers.cloudflare.com/sandbox/guides/docker-in-docker/) for instructions on combining Docker with the SandboxSDK. For general Containers usage, see the [Containers FAQ](https://developers.cloudflare.com/containers/faq/#can-i-run-docker-inside-a-container-docker-in-docker).

Jan 05, 2026
1. ### [Custom container instance types now available for all users](https://developers.cloudflare.com/changelog/post/2026-01-05-custom-instance-types/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
Custom instance types are now enabled for all [Cloudflare Containers](https://developers.cloudflare.com/containers) users. You can now specify specific vCPU, memory, and disk amounts, rather than being limited to pre-defined [instance types](https://developers.cloudflare.com/containers/platform-details/limits/#instance-types). Previously, only select Enterprise customers were able to customize their instance type.  
To use a custom instance type, specify the `instance_type` property as an object with `vcpu`, `memory_mib`, and `disk_mb` fields in your Wrangler configuration:  
TOML  
```  
[[containers]]  
image = "./Dockerfile"  
instance_type = { vcpu = 2, memory_mib = 6144, disk_mb = 12000 }  
```  
Individual limits for custom instance types are based on the `standard-4` instance type (4 vCPU, 12 GiB memory, 20 GB disk). You must allocate at least 1 vCPU for custom instance types. For workloads requiring less than 1 vCPU, use the predefined instance types like `lite` or `basic`.  
See the [limits documentation](https://developers.cloudflare.com/containers/platform-details/limits/#custom-instance-types) for the full list of constraints on custom instance types. See the [getting started guide](https://developers.cloudflare.com/containers/get-started/) to deploy your first Container,

Nov 21, 2025
1. ### [Mount R2 buckets in Containers](https://developers.cloudflare.com/changelog/post/2025-11-21-fuse-support-in-containers/)  
[ Containers ](https://developers.cloudflare.com/containers/)[ R2 ](https://developers.cloudflare.com/r2/)  
[Containers](https://developers.cloudflare.com/containers/) now support mounting R2 buckets as FUSE (Filesystem in Userspace) volumes, allowing applications to interact with [R2](https://developers.cloudflare.com/r2/) using standard filesystem operations.  
Common use cases include:  
   * Bootstrapping containers with datasets, models, or dependencies for [sandboxes](https://developers.cloudflare.com/sandbox/) and [agent](https://developers.cloudflare.com/agents/) environments  
   * Persisting user configuration or application state without managing downloads  
   * Accessing large static files without bloating container images or downloading at startup  
FUSE adapters like [tigrisfs ↗](https://github.com/tigrisdata/tigrisfs), [s3fs ↗](https://github.com/s3fs-fuse/s3fs-fuse), and [gcsfuse ↗](https://github.com/GoogleCloudPlatform/gcsfuse) can be installed in your container image and configured to mount buckets at startup.  
```  
FROM alpine:3.20  
# Install FUSE and dependencies  
RUN apk update && \  
    apk add --no-cache ca-certificates fuse curl bash  
# Install tigrisfs  
RUN ARCH=$(uname -m) && \  
    if [ "$ARCH" = "x86_64" ]; then ARCH="amd64"; fi && \  
    if [ "$ARCH" = "aarch64" ]; then ARCH="arm64"; fi && \  
    VERSION=$(curl -s https://api.github.com/repos/tigrisdata/tigrisfs/releases/latest | grep -o '"tag_name": "[^"]*' | cut -d'"' -f4) && \  
    curl -L "https://github.com/tigrisdata/tigrisfs/releases/download/${VERSION}/tigrisfs_${VERSION#v}_linux_${ARCH}.tar.gz" -o /tmp/tigrisfs.tar.gz && \  
    tar -xzf /tmp/tigrisfs.tar.gz -C /usr/local/bin/ && \  
    rm /tmp/tigrisfs.tar.gz && \  
    chmod +x /usr/local/bin/tigrisfs  
# Create startup script that mounts bucket  
RUN printf '#!/bin/sh\n\  
    set -e\n\  
    mkdir -p /mnt/r2\n\  
    R2_ENDPOINT="https://${R2_ACCOUNT_ID}.r2.cloudflarestorage.com"\n\  
    /usr/local/bin/tigrisfs --endpoint "${R2_ENDPOINT}" -f "${BUCKET_NAME}" /mnt/r2 &\n\  
    sleep 3\n\  
    ls -lah /mnt/r2\n\  
    ' > /startup.sh && chmod +x /startup.sh  
CMD ["/startup.sh"]  
```  
See the [Mount R2 buckets with FUSE](https://developers.cloudflare.com/containers/examples/r2-fuse-mount/) example for a complete guide on mounting R2 buckets and/or other S3-compatible storage buckets within your containers.

Nov 21, 2025
1. ### [New CPU Pricing for Containers and Sandboxes](https://developers.cloudflare.com/changelog/post/2025-11-21-new-cpu-pricing/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
[Containers](https://developers.cloudflare.com/containers/) and [Sandboxes](https://developers.cloudflare.com/sandbox/) pricing for CPU time is now based on active usage only, instead of provisioned resources.  
This means that you now pay less for Containers and Sandboxes.  
#### An Example Before and After  
Imagine running the `standard-2` instance type for one hour, which can use up to 1 vCPU, but on average you use only 20% of your CPU capacity.  
CPU-time is priced at _$0.00002 per vCPU-second_.  
Previously, you would be charged for the CPU allocated to the instance multiplied by the time it was active, in this case 1 hour.  
CPU cost would have been: **$0.072** — 1 vCPU \* 3600 seconds \* $0.00002  
Now, since you are only using 20% of your CPU capacity, your CPU cost is cut to 20% of the previous amount.  
CPU cost is now: **$0.0144** — 1 vCPU \* 3600 seconds \* $0.00002 \* 20% utilization  
This can significantly reduce costs for Containers and Sandboxes.  
Note  
Memory cost and disk pricing remain unchanged, and is still calculated based on _provisioned_ resources.  
See the documentation to learn more about [Containers](https://developers.cloudflare.com/containers/get-started/), [Sandboxes](https://developers.cloudflare.com/sandbox/), and [associated pricing](https://developers.cloudflare.com/containers/pricing).

Oct 01, 2025
1. ### [Larger Container instance types](https://developers.cloudflare.com/changelog/post/2025-10-01-new-container-instance-types/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
New instance types provide up to 4 vCPU, 12 GiB of memory, and 20 GB of disk per container instance.  
| Instance Type | vCPU | Memory  | Disk  |  
| ------------- | ---- | ------- | ----- |  
| lite          | 1/16 | 256 MiB | 2 GB  |  
| basic         | 1/4  | 1 GiB   | 4 GB  |  
| standard-1    | 1/2  | 4 GiB   | 8 GB  |  
| standard-2    | 1    | 6 GiB   | 12 GB |  
| standard-3    | 2    | 8 GiB   | 16 GB |  
| standard-4    | 4    | 12 GiB  | 20 GB |  
The `dev` and `standard` instance types are preserved for backward compatibility and are aliases for `lite` and `standard-1`, respectively. The `standard-1` instance type now provides up to 8 GB of disk instead of only 4 GB.  
See the [getting started guide](https://developers.cloudflare.com/containers/get-started/) to deploy your first Container, and the [limits documentation](https://developers.cloudflare.com/containers/platform-details/limits/) for more details on the available instance types and limits.

Sep 25, 2025
1. ### [Run more Containers with higher resource limits](https://developers.cloudflare.com/changelog/post/2025-09-24-higher-container-resource-limits/)  
[ Containers ](https://developers.cloudflare.com/containers/)  
You can now run more Containers concurrently with higher limits on CPU, memory, and disk.  
| Limit                                          | New Limit | Previous Limit |  
| ---------------------------------------------- | --------- | -------------- |  
| Memory for concurrent live Container instances | 400GiB    | 40GiB          |  
| vCPU for concurrent live Container instances   | 100       | 20             |  
| Disk for concurrent live Container instances   | 2TB       | 100GB          |  
You can now run 1000 instances of the `dev` instance type, 400 instances of `basic`, or 100 instances of `standard` concurrently.  
This opens up new possibilities for running larger-scale workloads on Containers.  
See the [getting started guide](https://developers.cloudflare.com/containers/get-started/) to deploy your first Container, and the [limits documentation](https://developers.cloudflare.com/containers/platform-details/limits/) for more details on the available instance types and limits.

[Search all changelog entries](https://developers.cloudflare.com/search/?contentType=Changelog+entry) 