Cloudflare has introduced snapshot and restore support for Container filesystems, now in public beta, according to the company's developer changelog. The feature lets a developer capture a point-in-time copy of a running Container's filesystem and later use that copy to bring files back after the container sleeps, restarts, or is handed off to a different Durable Object.
The mechanism is exposed through the Durable Object Container API. A developer calls snapshotContainer() on the running container to capture the full filesystem, stores the returned handle, and passes that handle to start() when restoring. The changelog's example stores the snapshot in Durable Object storage under a key and reads it back before calling start() with the containerSnapshot option.
The documented flow has two distinct steps. First, saveSnapshot() awaits this.ctx.container.snapshotContainer({}) and writes the result to this.ctx.storage. Second, restoreSnapshot() reads the stored value, returns early if nothing is found, and otherwise calls this.ctx.container.start({ containerSnapshot, enableInternet: false }). The restore call in the example explicitly disables internet access.
The source lays out two constraints. First, the feature's scope covers Container applications running the durable_object scheduling policy alone; projects relying on any other scheduling policy fall outside it. Second, snapshots cannot be altered once made: rather than modify an existing one, a developer who wants filesystem changes from after a restore to persist has to create a new snapshot.
For freelancers and developers building on Cloudflare's container platform, the practical value is in state continuity. A container that sleeps or restarts normally loses in-memory and filesystem state; a stored snapshot handle gives a documented way to bring the filesystem back to a known point. The handoff case matters for architectures where work moves between Durable Objects, because the snapshot travels with the handle rather than staying tied to one instance.
The immutability rule shapes how such a workflow has to be designed. Because a restored snapshot cannot be updated in place, any changes written after a restore exist only in the live filesystem until a fresh snapshot is taken. Teams that want durable checkpoints at several stages will need to manage multiple snapshot handles and decide when each is created and discarded.
The example's enableInternet: false is worth noting as a documented parameter in the restore path, but the supplied source does not explain what network behavior applies when it is set differently, nor does it describe snapshot size limits, storage costs, retention, or performance characteristics. Those details are not established by the evidence available here.
The changelog labels the capability a public beta, which signals that the API surface and behavior may still change. It also points readers to separate documentation on Snapshots and the Durable Object Container API for more information, but the supplied excerpts do not include that documentation's contents.
No pricing, regional availability, or migration guidance is provided in the source material. The excerpts also do not state whether existing containers can adopt snapshots without code changes, or what happens to a snapshot handle if the underlying container is deleted. These remain open questions for anyone planning to rely on the feature.
Editorially, the sensible approach for this audience is to treat snapshots as a checkpointing primitive rather than a backup system. The documented behavior supports restoring a filesystem state and handing it to another Durable Object; it does not, on this evidence, promise durability guarantees, cross-account portability, or long-term archival.
A reasonable first step would be to prototype the save-and-restore cycle in a non-critical container that already uses the durable_object scheduling policy, confirm that the stored handle survives the sleep or restart path you care about, and measure how snapshot creation interacts with your workload before depending on it in production.
The headline fact is narrow and concrete: Cloudflare now documents snapshotContainer() and a containerSnapshot option on start() for Container filesystems, in public beta, with a durable_object scheduling policy requirement and immutable snapshots. Everything beyond that — cost, limits, and long-term support — is not answered by the evidence supplied.