What are Integrations?
Integrate exe.dev with other tools and services
Integrations connect your exe.dev VM to other services securely and flexibly.
They allow you to "inject secrets" on the network, so that those secrets cannot
be extracted from the VM itself. Integrations are created with the `integrations add`
command and attached to VMs with the `integrations attach` command.
You can manage integrations from the [Integrations page](/integrations) in the
web UI or via SSH.
The common public integration types are:
- [HTTP Proxy Integration](integrations-http-proxy) — inject headers into HTTP requests
- [GitHub Integration](integrations-github) — work with private repos without managing tokens
- [LLM Integration](integrations-llm) — expose managed, API-key, or ChatGPT-backed LLM providers to VMs
- [Reflection Integration](integrations-reflection) — expose VM metadata such as email, tags, comments, and attached integrations
- [Slack Integration](integrations-slack) — send messages from a VM to a Slack channel
- [Slack Bot Integration](integrations-slack-bot) — run a two-way Slack bot from a VM, tokens held off-VM
Identity Federation guides:
- [AWS Workload Identity Federation](integrations-aws-wif) — let VMs assume AWS IAM roles with short-lived OIDC tokens
- [GCP Workload Identity Federation](integrations-gcp-wif) — let VMs impersonate Google Cloud service accounts with short-lived OIDC tokens
## Default integrations
New accounts get these default integrations:
- `reflection`: exposes all reflection fields and is attached with `auto:all`, so every VM can read its metadata from `reflection.int.exe.xyz`.
- `llm`: exposes the managed LLM model list at `https://llm.int.exe.xyz/v1/models` and is attached with `auto:all`, so every VM can use the managed Anthropic, OpenAI, and Fireworks providers.
Reinstall Reflection from the Reflection tile on the Integrations page or with:
```
exe.dev ▶ integrations add reflection --name reflection --fields all --attach auto:all
```
Reinstall the default LLM integration from the LLM tile on the Integrations
page or with:
```
exe.dev ▶ integrations add llm --name llm --attach auto:all
```
## Providing secrets to `integrations` commands
Several integration types take a secret at creation time: an API key
(`--openai-key`), a bot token (`--bot-token`, `--app-token`), a webhook URL
(`--webhook-url`), or a bearer token (`--bearer`). For any of the key and
token flags, pass `-` as the value to read the secret from stdin instead of
putting it on the command line:
```
$ printf '%s' "$OPENAI_API_KEY" | ssh exe.dev integrations add llm --name openai-key --openai=byok --openai-key=-
```
This keeps the secret out of your local shell history and process listings.
It also composes with password managers:
```
$ op read "op://vault/slack-bot/token" | ssh exe.dev integrations add slack --name mybot --bot-token=-
```
When a command takes two secrets, set both flags to `-` and provide one per
line (see the [Slack Bot Integration](integrations-slack-bot) for an
example).
As a backstop, exe.dev never saves commands containing credential flags to
your SSH command history, and redacts their values in server logs — but
stdin is the tidier habit.
## Where secrets live
Whatever the type, the secret is stored server-side and injected at the
network edge when your VM calls the integration hostname. The VM — and any
agent running on it — can *use* the integration but can never read the
secret. `integrations list --json` shows stored secrets as `***`.
See also: [Attaching Integrations](integrations-attach) for how to connect
integrations to your VMs using direct attachment, tags, or auto-attach.