What are Integrations?

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 in the web UI or via SSH.

The common public integration types are:

• HTTP Proxy Integration — inject headers into HTTP requests
• VM-to-VM Integration — let one VM call another over HTTPS, generated key injected at the edge
• GitHub Integration — work with private repos without managing tokens
• LLM Integration — expose managed, API-key, ChatGPT-backed, or custom HTTPS LLM providers to VMs
• Object Storage (S3) Integration — sign requests to S3-compatible storage without putting credentials on the VM
• Reflection Integration — expose VM metadata such as email, tags, comments, and attached integrations
• Slack Integration — send messages from a VM to a Slack channel
• Slack Bot Integration — run a two-way Slack bot from a VM, tokens held off-VM
• Discord Integration — send messages from a VM to a Discord channel
• Discord Bot Integration — 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 for the full list of handles and connect links.

Identity Federation guides:

• AWS Workload Identity Federation — let VMs assume AWS IAM roles with short-lived OIDC tokens
• GCP Workload Identity Federation — 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 for how to connect integrations to your VMs using direct attachment, tags, or auto-attach.