Skip to main content
Picking a storage and sandbox layer means planning for the day you leave it, or the day the vendor changes. This page says exactly what you own, what you depend on Archil for, and how to get your data out.

​
Adopt Archil without a one-way door

You can run your whole agent stack on Archil, disks and sandboxes, and still be able to replace either half on its own:
  1. Keep workspaces on a disk synced to your own bucket. Each file is an ordinary object in your S3, GCS, or R2 bucket, readable with any S3 tool without Archil.
  2. Build sandbox images as standard OCI images in your own registry. The same image runs on other container and microVM platforms.
  3. To move sandboxes elsewhere, mount the same disk in E2B, Daytona, Modal, Vercel Sandbox, or any Linux machine. Your agents keep their files, and nothing needs to be migrated.
  4. To move storage elsewhere, your bucket already holds the files. Point your new storage layer at it.
With this setup, the cost of leaving Archil is changing where your code runs or where you mount the bucket, not migrating data.

​
Summary

If you want a copy of your data that never depends on Archil, use a disk synced to your own bucket. Bring your own bucket is included on every paid plan, starting with Developer.

​
Disks synced to your own bucket

With bring your own bucket, Archil writes file contents to your bucket as ordinary objects, at the key that matches the file’s path on the disk. You can read them with aws s3, boto3, Athena, Spark, or any other S3 tool, without the Archil client and without an Archil account. If you stop using Archil, those objects stay in your bucket, under your control. What to know before relying on the bucket copy:
  • Sync is asynchronous. A write committed to Archil is stored durably on Archil’s storage layer, replicated across Availability Zones, and reaches your bucket in the background. How long that takes depends on the workload. Until then, the newest writes exist only in Archil. See Consistency.
  • POSIX metadata stays in Archil. Mode bits, ownership, and extended attributes aren’t written to the bucket. Symbolic links are stored as a text file containing the link target, and hard links as full copies.
  • Multi-step operations aren’t atomic in the bucket. A directory rename can show partial results in the bucket while it runs. See Atomicity.
  • Deleting the disk doesn’t delete your objects. Archil stops synchronizing and discards its cached copy. Objects already written to your bucket remain.
  • You control access. Archil reaches your bucket through the bucket policy or credentials you grant. Remove them and Archil can no longer read or write the bucket.
Before deleting a disk you’re moving away from, stop writing to it and give the background sync time to finish. You can compare a listing of the disk over the Archil S3 API with a listing of your bucket to confirm they match.

​
Archil-managed disks

By default, disks use Archil-managed storage: a bucket Archil operates, holding data in Archil’s internal format with multi-AZ durability. You can’t point your own tools at that bucket, so you read the data through Archil. Two ways to export it:
  • S3 API. Every disk is also an S3-compatible bucket. Add S3 credentials to the disk in the console and copy everything out with any S3 client:
    Symbolic links, FIFOs, sockets, and device nodes aren’t readable over the S3 API.
  • A mount. Mount the disk and copy it with rsync -aH to keep permissions, ownership, symbolic links, and hard links.
To move a managed disk to a bucket you own, create a disk synced to your bucket and copy the data into it. Data transfer out of Archil is billed at the standard rate. Deleting a managed disk deletes its data, so export anything you want to keep first.

​
Sandboxes

Persistent sandboxes boot from standard OCI images, public or private, so the same image runs on other container and microVM platforms. A sandbox’s root filesystem lives on an Archil-managed disk. Write data you want to keep, or to take elsewhere, to a mounted Archil disk, ideally one synced to your own bucket.

​
Bring your own cloud

BYOC, on Enterprise, runs both the file system and storage layers in your own cloud account or on bare metal, so disk data never leaves your environment. Combined with your own buckets, the durable copy of your data sits entirely in infrastructure you control. Archil operates each BYOC deployment through egress-only access, and you can require two-person approval before Archil makes changes.

​
Commitments

  • Durability and availability. Archil is designed for 99.999% durability and 99.99% availability. Per-component uptime history is public at status.archil.com.
  • Security. Archil undergoes ongoing SOC 2 Type II audits. See Security & Compliance.
  • Contracts. Enterprise customers can sign an availability SLA, a DPA, and a BAA.
Questions about data ownership or exit planning: support@archil.com.