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

# Environment and execution selection

> How Environment requirements guide managed or customer-owned Cloudflare execution.

A Session selects an **Environment**: reusable configuration for packages,
networking, resources and execution requirements. Admission freezes those
requirements for the Run. An Environment is separate from a physical allocation
or a persistent Computer.

## Where execution runs

Checkfu's execution direction is Checkfu-managed Cloudflare or a
customer-owned Cloudflare installation. Each route must satisfy the selected
Environment and the Harness's requirements. Bring-your-own sandbox services,
including Daytona, are being retired as product routes.

Customer-owned Cloudflare is separate from **BYOH** (bring your own Harness)
and **BYOK** (bring your own model-provider key). A custom Harness does not
select a sandbox provider, and a model-provider key does not grant machine
control.

The exact deployment must make the required runtime available. A configured
adapter, protocol connection or checked-in fixture does not establish that a
Workspace can execute the workload. See [capability status](/getting-started/status)
for current support and availability.

## Request the capabilities your work needs

Code execution, browser access, desktop viewing and input are separate
capabilities. A Computer can be headless and has an owner independent of the
Session. A Session borrowing a Computer detaches when it finishes; destroying
the Computer requires its owner's authority.

Execution must satisfy the frozen Environment requirements or refuse the work.
It must not silently substitute a different runtime, weaker network boundary or
empty retained machine. Do not infer a base image, operating system, mount
capacity or recovery grade from an Environment name.

## Retained state and recovery

Retained conversation history, restored files, native checkpoints and running
process recovery are distinct promises. Files restored into a new allocation
do not prove that the prior native process resumed. A checkpoint is usable only
where the selected Harness, runtime and retention policy support it.

Standard retention and ZDR have different requirements. Selecting ZDR must not
silently fall back to execution that retains prohibited content. Neither a
checkpoint nor retained history proves that an external effect completed.


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