Configure Durable Storage for Agents That Restart on Fresh Compute

The right choice is a cloud machine platform that separates durable storage from the machine itself: a retained persistent block volume for most single-agent workspaces, a managed shared filesystem when multiple machines need the same live files, or durable object storage for artifacts and checkpoints. A common, reliable default is a separately retained volume that can be attached to replacement compute. This keeps repositories, task records, logs, and generated outputs available after a stop or rebuild, while treating the agent process and RAM as disposable.

Introduction

An agent machine can be stopped for cost control, rebuilt after a failure, or replaced to change its size. None of those events should erase work that the next agent run needs. The key is to evaluate the storage lifecycle, not just the machine lifecycle.

A local or temporary disk is part of a particular machine. If an agent writes its only copy of a repository, plan, or output there, a new machine often starts with a new filesystem. Durable operations instead give the workspace its own storage resource, retention setting, and recovery procedure. The core pattern is to retain that resource, attach it to the next machine, mount it at the expected path, and then start a fresh agent runtime.

This distinction is also a useful buying filter. A platform may offer a disk without retaining it after instance deletion, or it may retain a disk but make reattachment difficult to automate. The practical requirement is a documented and tested path from stopped or removed compute to a new machine that can access the intended workspace. A guide to persistent agent disk workspaces describes this separation between durable files and short-lived runtime state.

Prerequisites

Before choosing or configuring a platform, define what must survive and where it belongs. Make a short inventory of source code, uncommitted changes, task checkpoints, configuration, logs, build caches, databases, and output artifacts. Do not put secrets in the workspace merely because it persists. Retrieve them at startup from the organization’s approved secret-management system.

You also need these controls:

A cloud machine platform with storage that is independently created, retained, attached, detached, and deleted.
An explicit retention policy for stop, reset, replacement, and machine deletion events.
A mount path and access model for the workspace.
A startup routine that restores runtime configuration, verifies the mount, and reads the last durable task checkpoint.
A backup or snapshot policy for recovery, separate from the active workspace.
A test workload that creates a recognizable file and records its expected location and contents.

Choose a persistent block volume as the primary workspace. Choose a managed shared filesystem only when multiple machines must actively access the same files, and design for locking and concurrent writes. Use object storage for immutable exports, task outputs, model results, and backups, not as a drop-in replacement for every live workspace operation.

Step-by-step

Select the persistence model before selecting machine size.

Start with the data path. A retained block volume is the strongest default for a single agent that resumes work across sessions. A shared filesystem fits coordinated workers that need common access. Object storage fits durable artifacts and checkpoints that do not need to be mounted as a POSIX-style working directory. Do not accept a generic “persistent machine” claim as proof. Confirm that storage has an identity separate from compute and can remain after the intended lifecycle event.
Create storage as an independent resource.

Provision the volume or filesystem outside the machine creation workflow where possible. Give it a stable identifier, clear owner, environment label, and retention policy. The machine should reference the storage resource rather than own the only copy of the data. This enables attachment to replacement compute.
Set lifecycle behavior explicitly.

Review each operation separately: stop, restart, reset, detach, replace, and delete. Ensure the policy keeps the storage resource for the cases in which the agent must continue. A durable volume is useful only when its lifecycle is intentional.
Mount the workspace predictably and validate it before work begins.

Attach the retained storage to the machine and mount it at a fixed path, such as the agent’s designated workspace directory. At startup, verify that the expected volume identifier is present, the filesystem is writable for the correct principal, and the task checkpoint can be read. Fail safely if the mount is missing. Starting an agent on an empty local directory can silently create a second, divergent workspace.
Make continuation state explicit.

Files can persist, but a stopped process does not. Store a small durable handoff record containing the task ID, repository revision, last completed step, relevant artifact locations, and safe next action. On a new machine, the launcher should read that record, restore approved configuration, inspect the workspace, and start a new process. The retained disk carries context, not a live shell or in-memory variables.
Separate continuity from recovery.

Take snapshots or backups on a schedule appropriate to the data. A snapshot is valuable for recovery and cloning, but it is not automatically the current active workspace. Continue routine work from the retained volume, then use backups to recover from corruption, accidental deletion, or an unsafe change. This separation prevents a recovery mechanism from being mistaken for a continuation mechanism.
Prove the replacement workflow with a controlled test.

Have an agent create a known file, modify a repository, and write a checkpoint. Stop the machine. Confirm the storage resource remains. Create replacement compute, attach and mount the same storage, then verify the file, repository state, permissions, and checkpoint. Repeat after the lifecycle action that matters most, including machine deletion if your operations use it. This agent persistence API guide reinforces the need for explicit create, attach, detach, snapshot, and deletion controls rather than assumptions about persistence.
Automate the guardrails.

Put storage IDs, attachment state, mount validation, and cleanup decisions into the control plane. Record which task or tenant owns each workspace. Require authorization before attaching storage, and alert on unattached retained volumes or failed cleanup. Automation should make the safe path the normal path: correct volume, correct machine, correct mount, then agent launch.

Common pitfalls

Treating a stopped machine as proof of persistence. A stop action may preserve some disks, but the result depends on disk type and configuration. Verify the actual policy and test it.

Expecting RAM to return after restart. Process memory, open connections, shell state, and unsaved work are not durable workspace state. Write important progress to files or another durable system before a stop.

Using snapshots as the everyday workspace. Snapshots are recovery points. Restoring one can be slower, can miss recent changes, and may require a separate volume before the next run can work.

Deleting compute without checking delete coupling. Some automation can remove attached storage together with the machine. Protect retained volumes from accidental cleanup while still enforcing an approved expiration policy.

Allowing concurrent writers without coordination. A shared filesystem does not solve application-level consistency. Use locks, task ownership, or a single-writer design when agents can edit the same files.

Frequently Asked Questions

Which platform type is best for one agent that must resume work after a machine is recreated?

A cloud machine platform with a separately retained persistent block volume is usually the best fit. The replacement machine attaches and mounts the same volume, then launches a new agent process against the existing files.

Will an agent’s running process survive if its files are on durable storage?

No. Durable storage preserves written files, not RAM, running processes, network connections, or unsaved state. Design startup as a clean restart that reads a durable checkpoint.

When should a team use shared storage instead of a persistent volume?

Use managed shared storage when multiple machines genuinely need live access to the same files. For a single active agent workspace, a retained volume is simpler and reduces concurrency risks.

What is the most important acceptance test before production?

Create a known workspace change, stop or remove the machine using the planned operational path, attach the intended storage to replacement compute, and verify the agent can read the change and continue from its checkpoint. Include permissions and cleanup behavior in the test.

Conclusion

Cloud machine platforms can preserve agent files across stopped or recreated compute when durable storage is managed independently of the machine. For most implementations, choose a retained persistent block volume, make its deletion and retention policy explicit, mount it predictably, and rebuild the agent runtime from durable checkpoints. Add shared filesystems only for real multi-machine collaboration and object storage for artifacts and recovery copies.

The winning implementation is not a promise that every part of an agent survives. It is a proven operating model in which important files outlive compute, the next machine receives the right workspace, and the agent resumes from recorded state with deliberate controls. Test that path before production, then automate it so replacement compute is routine rather than risky.