How to move an agent's workspace between Daytona and E2B

To move an agent's workspace between Daytona and E2B, keep the repository, node_modules and build cache on a network disk that both providers can mount, and hand that disk from one sandbox to the next. Daytona and E2B sandboxes both support FUSE, and both providers' docs describe mounting an Archil disk, so the same directory follows the task wherever it runs.

How to move an agent's workspace between Daytona and E2B

Moving a task between providers is a storage hand-off. The sandbox that runs the task changes; the working directory doesn't. The source sandbox finishes with the workspace, releases the disk, and the destination sandbox mounts the same disk and carries on, with the repository, installed dependencies and build cache already in place.

An Archil disk is a POSIX file system that mounts with archil mount on any Linux machine with FUSE, so the workspace can live in a directory such as /workspace in both providers' sandboxes. The important boundary is between the sandbox that runs the task and the disk that holds its files.

Why provider storage doesn't follow the task

When a Daytona sandbox is deleted, or an E2B sandbox is killed or times out, the files written inside it go with it. Each provider's own volumes outlive a sandbox, but they are mounted by that provider's sandboxes: Daytona's Mount External Storage doc says Daytona Volumes are hosted on Daytona's own S3-compatible object store, and contrasts them with external mounts of storage hosted elsewhere. Persistence and portability are different promises.

Rebuilding from git on every move takes a different route, but it doesn't preserve the whole working directory. Each move reinstalls dependencies, discards the build cache and loses uncommitted work. For an agent in the middle of a task, the files it needs to continue include work that hasn't become a commit yet.

Keep the workspace on a disk both providers mount

Daytona's Mount External Storage doc and E2B's Archil page both cover mounting an Archil disk in their sandboxes. Archil publishes matching guides for Daytona and E2B.

Put the repository, node_modules and the build cache together in one directory on the disk, for example /workspace. A directory left outside it isn't part of what moves.

A write is durable once fsync returns: Archil stores it redundantly across Availability Zones. The client also buffers recent writes the application hasn't synced, which is why the hand-off below releases the disk before the sandbox goes away.

Your app can read files on the disk with the Archil SDK (getObject) without starting a sandbox, which is useful for showing a task's output while no agent is running.

Pick the Archil region nearest your sandboxes. In Archil's published measurement from five new E2B sandboxes with a disk in aws-us-west-2, about 2 ms away, installing the client took 5.2 s, mounting took 131 ms, and the first 4 KiB read took 0.17 s (medians of 5). See the Archil vs E2B comparison. Mounting a disk on compute outside Archil needs an Archil paid plan.

Hand-off: release the disk in one sandbox, mount it in the next

A plain mount is exclusive: one sandbox holds the disk at a time, which suits one task moving between providers.

• On E2B, run archil unmount before killing the sandbox. It returns once every buffered write has reached the disk, and it releases the disk.
• On Daytona, the client can't detach the mount, so run archil sync to send buffered writes and then archil checkin to release the sandbox's lock before deleting it.
• If a sandbox disappears before releasing the disk, revoke its delegation with the SDK's listDelegations and revokeDelegation, or mount from the next sandbox with archil mount --force. Forcing discards writes the old client never sent, so it doesn't replace a clean release.
• To skip the client install on every move, bake it into the image: an E2B template, or a Daytona snapshot.

Example: start a task in Daytona and finish it in E2B

The script below mounts the disk in a Daytona sandbox, releases it, then mounts it in an E2B sandbox created from a template named archil with the client installed, built as in the E2B guide. Both sides pass the disk's mount token only to the mount command.

import { Daytona } from "@daytona/sdk";
import { Sandbox } from "e2b";
 
const { ARCHIL_DISK_ID, ARCHIL_REGION, ARCHIL_MOUNT_TOKEN } = process.env;
const token = { ARCHIL_MOUNT_TOKEN: ARCHIL_MOUNT_TOKEN! };
 
// 1. Daytona: mount the workspace, do the first part of the task, then release the disk
const daytona = await new Daytona().create();
const sh = async (command: string, env?: Record<string, string>) => {
  const { exitCode, result } = await daytona.process.executeCommand(command, undefined, env);
  if (exitCode !== 0) throw new Error(result);
  return result;
};
try {
  await sh("sudo apt-get update -qq && curl -fsSL https://archil.com/install | sh > /dev/null");
  await sh(
    `sudo mkdir -p /workspace && sudo --preserve-env=ARCHIL_MOUNT_TOKEN archil mount ${ARCHIL_DISK_ID} /workspace --region ${ARCHIL_REGION}`,
    token,
  );
  // ... the agent clones the repo, runs npm ci and builds in /workspace ...
} finally {
  await sh("sudo archil sync /workspace && sudo archil checkin /workspace"); // Daytona can't detach the mount
  await daytona.delete();
}
 
// 2. E2B: mount the same disk and pick up where Daytona stopped
const e2b = await Sandbox.create("archil"); // template with the archil client installed
try {
  await e2b.commands.run(`mkdir -p /workspace && archil mount ${ARCHIL_DISK_ID} /workspace --region ${ARCHIL_REGION}`, {
    user: "root",
    envs: token,
  });
  // ... repo, node_modules and build cache are already there ...
} finally {
  await e2b.commands.run("archil unmount /workspace", { user: "root" });
  await e2b.kill();
}

The order is the point: the source sandbox sends its buffered writes and releases the disk before it is deleted, and only then does the destination mount it. The final sandbox releases the disk the same way when the task ends.

When several sandboxes need the workspace at once

Several sandboxes using one disk at the same time is a different problem from a sequential move. Archil has two modes for it, described in Sharing disks:

• --conditional: any client can write anywhere no other client has checked out. If two clients write the same part of a file, the last write to reach the disk wins.
• --shared: a client writes the paths it has claimed with archil checkout, at local-disk speed.

For a workspace that stays within one provider across restarts, see Persistent workspace for sandbox agents across restarts. For how Archil compares with each provider's own storage, see the Daytona, E2B and sandbox providers comparisons.