> ## 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.

# Bring Your Own Cloud (BYOC)

> Run the full Archil platform, fully managed by Archil, in your own cloud account or on bare metal.

Bring Your Own Cloud (BYOC) runs Archil inside your own environment instead of Archil's public regions. BYOC is
available to Enterprise customers. Archil fully manages each deployment, so it works like a
managed cloud service that happens to run in your account.

## Supported environments

BYOC runs on any cloud, including AWS, Google Cloud, and Azure, as well as on your own bare-metal servers. The only
dependency is a Kubernetes cluster with outbound (egress-only) network access. Archil doesn't need inbound access to
your network and doesn't depend on any cloud provider's managed services.

Both the file system and storage layers run in your environment, so your disk data never leaves it.

A BYOC deployment can include the full Archil platform. Choose the parts you need:

* **Disks**, including [shared access](/concepts/sharing-disks) from many clients, the
  [S3-compatible API](/protocols/s3-api), and the [Kubernetes CSI driver](/reference/csi-driver)
* **[Persistent sandboxes](/compute/sandboxes/introduction)**
* **[Serverless execution](/compute/serverless-execution)** (`exec` and `grep`)

BYOC deployments are on the same release pipeline as Archil's public regions and receive new versions on the same
schedule.

## Why public regions differ

In Archil's public regions, sandboxes and serverless execution run in AWS (see
[Region availability](/reference/regions#compute-availability)). That reflects where Archil hosts its own service, not
a limit of the software. In a BYOC deployment, every part of the platform runs on whichever cloud or hardware you
choose.

## Deploying into your customers' environments

If you sell software that runs in your customers' cloud accounts, Archil can be deployed alongside your product in each
of those accounts. You set up Archil as part of installing your own software. Your customers don't need a separate
agreement with Archil. Because the deployment is egress-only and Archil doesn't process the data stored in it, Archil
isn't added as a subprocessor for your customers.

## Setting up a deployment

Setup takes about an hour:

1. Create the access role Archil provides, such as an IAM role on AWS or its equivalent on your cloud.
2. Run the provided Helm chart or `kubectl` install in your cluster.

Archil's automation does the rest: it provisions the node groups the deployment needs, installs Archil's services,
and brings the deployment online.

## Operations and maintenance

Archil operates each BYOC deployment the same way it operates its public regions. Archil monitors the deployment,
pages its own on-call operators when something goes wrong, and performs upgrades and maintenance through its
egress-only deployment tooling. Your team doesn't need to run Archil itself.

If you want control over when Archil can make changes, you can require two-person approval: Archil can only perform
maintenance on your cluster after someone on your team approves it.

## Telemetry

To operate a deployment, Archil collects operational telemetry from it. Telemetry never includes personally
identifiable information (PII) or protected health information (PHI). It is censored and scrubbed inside your cluster
before it leaves:

* **File data is never logged** or sent to Archil.
* **File paths and file names are blocked** from leaving the deployment.

BYOC requires this telemetry connection. If your environment can't allow any outbound telemetry,
[contact us](mailto:sales@archil.com) to discuss options.

## Getting started

To try BYOC in your own environment, start with a pilot. [Contact us](mailto:sales@archil.com) to set up a pilot or to
choose a deployment model.


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