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

# Data ownership and portability

> Where your data lives, how to get it out, and what happens to it if you stop using Archil. Disks synced to your own bucket store files as ordinary S3 objects that any S3 tool can read without Archil.

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](https://docs.archil.com/guides/platforms/e2b.md),
   [Daytona](https://docs.archil.com/guides/platforms/daytona.md), [Modal](https://docs.archil.com/guides/platforms/modal.md), [Vercel Sandbox](https://docs.archil.com/guides/platforms/vercel-sandbox.md),
   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

| | Durable copy lives in | Readable without Archil | How to leave |
| - | - | - | - |
| Disk synced to your bucket ([BYOB](https://docs.archil.com/concepts/data-sources.md)) | Your S3, GCS, R2, or other S3-compatible bucket | Yes. Each file is an ordinary object at its path. | Stop writing and delete the disk. The objects stay in your bucket. |
| Archil-managed disk (the default) | A bucket Archil operates, in Archil's internal format | No | Copy it out over the [S3 API](https://docs.archil.com/protocols/s3-api.md) or a mount. |
| [Sandbox](https://docs.archil.com/compute/sandboxes/introduction.md) root filesystem | An Archil-managed disk | No | Keep data you need on a mounted disk. Images are standard OCI images. |
| [BYOC](https://docs.archil.com/reference/byoc.md) deployment | Your own cloud account or hardware | Same as above, inside your environment | Same as above. Disk data never leaves your environment. |

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](https://docs.archil.com/concepts/data-sources.md), 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](https://docs.archil.com/concepts/data-sources.md#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](https://docs.archil.com/concepts/data-sources.md#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](https://docs.archil.com/protocols/s3-api.md).** 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:

  ```bash theme={null}
  aws s3 sync s3://dsk-abc123/ ./dsk-abc123 \
    --endpoint-url https://s3.green.us-east-1.aws.prod.archil.com
  ```

  Symbolic links, FIFOs, sockets, and device nodes aren't readable over the S3 API.
* **A mount.** [Mount the disk](https://docs.archil.com/mounting/linux.md) 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](https://docs.archil.com/administration/billing.md). Deleting a managed disk deletes
its data, so export anything you want to keep first.

## Sandboxes

[Persistent sandboxes](https://docs.archil.com/compute/sandboxes/introduction.md) 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](https://docs.archil.com/reference/byoc.md), 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](https://status.archil.com).
* **Security.** Archil undergoes ongoing SOC 2 Type II audits. See [Security & Compliance](https://docs.archil.com/details/security.md).
* **Contracts.** Enterprise customers can sign an availability SLA, a DPA, and a BAA.

Questions about data ownership or exit planning: [support@archil.com](mailto:support@archil.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.