mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-04 02:33:56 +00:00
80bc51c40e
SandboxProviderKind is now a validated string newtype instead of a closed enum. The bundled kinds (local, docker, daytona) keep their constants and a BundledProvider enum for the code paths that still dispatch on them; any other well-formed sandbox-driver kind name is accepted and names a plugin executable. EnvironmentProvider is gone: environment settings carry SandboxProviderKind directly, and is_clone_based is replaced by a workspace policy where local runs in a designated directory and every other provider clones. Server sandbox policy is keyed by kind. [server.sandbox.providers.<kind>] accepts the bundled kinds with `enabled` and any plugin kind with its launch settings (path, sha256, dev, args, env, inherit_env); bundled kinds reject the plugin keys and a kind with no entry is disabled. The OpenAPI schema, generated Rust and TypeScript clients, web settings pages, and docs follow. The environments table drops its provider CHECK enumeration in favour of the kind name rules so a plugin environment can be stored. Bundled-only code paths (run start, preflight, reconnect, terminal, details) now fail with an explicit message for a plugin kind until the driver construction function lands in the next step. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
31 lines
2.1 KiB
Text
31 lines
2.1 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 bundles three sandbox providers: `local` (no isolation), `docker` (container-level), and `daytona` (cloud VM). Additional providers run as [sandbox-driver](https://github.com/lithoscomputer/sandbox-driver) plugins configured under `[server.sandbox.providers.<kind>]`; an environment selects one by its kind name. See [Environments](/execution/environments) for full provider-specific configuration and [Server configuration](/administration/server-configuration#serversandboxproviders-section) for plugin settings.
|
|
|
|
Operators can enable or disable which providers the server may launch with
|
|
`[server.sandbox.providers.<kind>]` in `settings.toml`. Missing bundled entries default to
|
|
`enabled = true`; setting `enabled = false` rejects new runs whose effective provider is disabled,
|
|
and a plugin kind with no entry is disabled. Dry-run runs on any non-local provider 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.
|