infra-setup

name	infra-setup
description	Non-user-invocable provider/setup reference for evo backend switching, prerequisite checks, and auth/install guidance.
disable-model-invocation	true
evo_version	0.4.4

Infra Setup

Use this when the user wants to change where experiments run: local worktrees, pool slots, or a remote provider such as Modal, E2B, Daytona, AWS, Azure, SSH, manual, or a custom dotted-path provider.

Goals

• Be explicit about the target backend/provider.
• Check prerequisites before mutating evo config.
• Never install provider SDKs silently.
• Give one actionable auth command per provider.
• Keep provider credentials separate from benchmark runtime env.

Flow

1. Identify the target:
   • worktree or pool means local backends.
   • modal, e2b, ssh:..., or another remote spec means backend=remote.
2. If the target is remote, parse the provider choice the same way evo CLI does:

• modal
• e2b
• daytona
• aws
• azure
• manual
• ssh:user@host[:port]
  • another built-in provider name
  • dotted import path for a custom provider

3. Check whether evo is on PATH and whether it is the expected evo-hq-cli package (evo --version). If the provider SDK is missing, evo's provider loader prints the provider-specific extra or SDK package to install; use that message rather than guessing.
4. For SDK-backed providers, verify the SDK import only when you can run the check in the same environment that owns the evo executable. If missing, ask the user before installing it.
   • If evo was installed with uv tool or pip/venv, prefer the matching extra on evo-hq-cli:
     • uv-tool: uv tool install --reinstall 'evo-hq-cli[<provider-extra>]'
     • venv / pip: python -m pip install 'evo-hq-cli[<provider-extra>]'
   • If evo was installed with pipx, inject the provider SDK into the same evo-hq-cli environment:
     • pipx: pipx inject evo-hq-cli <provider-sdk>
5. Check auth and show exactly one provider-specific auth command or setup step. Use references/provider-matrix.md.
6. Once prerequisites are satisfied, run the explicit config command:

evo config backend remote --provider <provider> --provider-config ...

Or for local backends:

evo config backend worktree
evo config backend pool --workspaces /abs/slot-a,/abs/slot-b

7. Be explicit that incomplete provider setup usually surfaces on evo new --remote <provider> ..., because that is where remote allocation and bootstrap actually happen.
8. If the benchmark itself needs application keys, configure runtime env separately with evo env load <path> --all or evo env load <path> --allow KEY1,KEY2. Provider auth provisions the sandbox; runtime env is what benchmark/gate processes see.

Pre-assumptions

Before trying to switch a workspace to a remote provider, confirm the basics:

• the target backend is clear from the user's request; only ask if the intent is genuinely ambiguous between worktree, pool, and remote
• the machine running evo has the right provider SDK or transport installed
• the user has auth for that provider available now, not "somewhere else"
• the provider-specific minimum config exists
  • modal: auth + optional config
  • e2b: API key + optional config
  • daytona: API key and API URL/target if needed
  • aws: creds, region, image, SSH key pair/private key, and usually network config
  • azure: subscription, resource group, region, SSH key/private key, and VM/image choices
  • ssh: reachable host, working SSH user, and key/port if needed
  • manual: reachable remote endpoint URL and bearer token
• for SSH-backed VM providers, the guest assumptions are plausible before allocation:
  • the image enables SSH
  • the SSH user matches the image
  • the image architecture matches the selected instance type
  • the host can run evo's remote workspace runtime

Provider notes

See references/provider-matrix.md for the compact provider summary, common config, and provider-specific setup/auth command.