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
- [VM-to-VM Integration](integrations-vm-to-vm) — let one VM call another over HTTPS, generated key injected at the edge
- [GitHub Integration](integrations-github) — work with private repos without managing tokens
- [LLM Integration](integrations-llm) — expose managed, API-key, ChatGPT-backed, or custom HTTPS LLM providers to VMs
- [Object Storage (S3) Integration](#object-storage-s3) — sign requests to S3-compatible storage without putting credentials on the VM
- [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
- [Discord Integration](integrations-discord) — send messages from a VM to a Discord channel
- [Discord Bot Integration](integrations-discord-bot) — drive your own Discord bot from a VM, token held off-VM
Beyond these built-in types, the catalog covers well over a hundred services;
see the [Integration catalog](integrations-catalog) for the full list of
handles and connect links.
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
## Object storage (S3)
Object storage integrations support Amazon S3, Tigris, Cloudflare R2, and
custom S3-compatible HTTPS endpoints. exe.dev stores the access key and secret
outside the VM and signs each request with AWS Signature Version 4.
Create one from the `Object storage` tile on the Integrations page, or over
SSH. Set `--region` to the AWS region for Amazon S3; `auto` works for providers
such as Tigris and R2.
```
$ printf '%s\n%s\n' "$S3_ACCESS_KEY_ID" "$S3_SECRET_ACCESS_KEY" | \
ssh exe.dev integrations add s3 --name objects \
--endpoint=https://t3.storage.dev --region=auto --bucket=my-bucket \
--access-key-id=- --secret-access-key=- --attach auto:all
```
Attached VMs access the bucket through
`https://objects.int.exe.xyz/<object-key>` without receiving the stored
credentials.
## 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`). Set any credential value
flag to `-` to read its value from stdin:
```
$ printf '%s' "$OPENAI_API_KEY" | ssh exe.dev integrations add llm --name openai-key --openai=byok --openai-key=-
```
This works with password managers:
```
$ op read "op://vault/slack-bot/token" | ssh exe.dev integrations add slack --name mybot --bot-token=-
```
With one credential flag set to `-`, the flag receives the complete stdin
value, including internal newlines such as those in a PEM private key. With
multiple `-` flags, provide one non-empty value per line **in the exact order
the flags appear on the command line**. The first line belongs to the first
`-` flag, the second line to the second `-` flag, and so on. A multiline
credential must be supplied by itself. In the interactive shell, credentials
are prompted for in the same flag order.
## 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.