Availability
There is no built-in Fly.io adapter today. Connect it through a customer-installed custom capacity provider.
Integration shape
The setup, credentials, governed actions, and evidence should be obvious.
Agent loop
ExecWarden can host the loop, or an external client can own it. Customer-managed Fly.io capacity supplies optional compute rather than deciding who owns the loop.
Tools
Local tools are governed by the execution environment; ExecWarden-mediated tools pass through MCP or hosted-session credentials.
Credentials
Keep external system credentials in ExecWarden when you want ExecWarden policy to apply.
Governed actions
ExecWarden governs calls it mediates, not arbitrary shell commands or secrets independently present in the execution environment.
ExecWarden evidence
Mediated calls can produce activity records, approval records, and provider results even when execution happens elsewhere.
Start
Implement and register the custom capacity provider, then run a task with an ExecWarden-mediated GitHub or API capability.
Where the boundary is
How this boundary works in practice.
ExecWarden governs the credentials and capabilities it supplies. The execution environment still governs its own files, shell, network, and separately available secrets.
Execution
Use provider-hosted or customer-controlled execution.
The agent loop and execution environment can live outside ExecWarden while governed tools still pass through ExecWarden.
Preview
Expose running work when available.
Tunnels and previews can make a branch or app state inspectable without changing production.
Boundary
Keep local secrets out of scope unless intended.
Secrets placed directly in the execution environment may be usable outside ExecWarden policy.
Examples
Example tasks and outcomes.
Get started during beta
Start with one bounded task and one boundary to review.
Use the app during beta, or open the docs and choose the first agent task you want to govern.