fabro/docs/public/administration/sandboxing.mdx
2026-05-26 21:55:17 -04:00

30 lines
1.8 KiB
Text

---
title: "Sandboxing"
description: "Sandboxing workflow execution"
---
Sandboxes isolate agent execution from the host machine. When an agent runs a shell command, edits a file, or searches code, it does so inside a sandbox — preventing unintended side effects on the host and providing a reproducible environment for each run.
Fabro supports three sandbox providers: `local` (no isolation), `docker` (container-level), and `daytona` (cloud VM). See [Environments](/execution/environments) for full provider-specific configuration.
Operators can enable or disable which providers the server may launch with
`[server.sandbox.providers.<provider>]` in `settings.toml`. Missing entries default to
`enabled = true`; setting `enabled = false` rejects new runs whose effective provider is disabled.
Dry-run Docker/Daytona runs execute locally, so they are governed by the `local` provider policy.
The API can also list Fabro-managed sandboxes directly from configured providers:
```http
GET /api/v1/sandboxes
GET /api/v1/sandboxes/{id}
```
Provider-backed inventory is useful when you need to inspect Docker or Daytona resources independent of a single run projection. Listing is fail-soft: available provider results are returned with provider errors in response metadata.
## Network access control
For cloud sandboxes (Daytona), you can control outbound network access with `[environments.<slug>.network]`. Three modes are available: `"allow_all"` (default), `"block"`, and `"cidr_allow_list"` with an `allow = ["..."]` CIDR list.
Server defaults in `settings.toml` apply when a run config doesn't specify `network`. Individual run configs can override the server default.
See [Environments — Network access](/execution/environments#network-access) for syntax examples and the full reference.