Skip to main content
Composio publishes Keyring as a Docker image for AMD64 and ARM64. You decide where it runs and control its networking, KMS access, scaling, monitoring, and upgrades. One Keyring deployment serves one Composio organization. We recommend using a separate Composio organization for testing before connecting your production organization.

​
Choose where to run Keyring

AWS ECS and Google Cloud Run are our preferred production platforms. Both provide managed compute and short-lived workload identity for access to your KMS.

AWS ECS on Fargate (preferred)

Deploy with an ECS task role and AWS KMS.

Google Cloud Run (preferred)

Deploy with a Cloud Run service identity and Google Cloud KMS.

Docker

Run the published image on your container platform.

Kubernetes

Deploy the image with the supported Helm chart.

Cloudflare Workers

Deploy the supported Worker runtime without Docker.

Vercel

Deploy the supported Vercel runtime without Docker.
Container deployments use composiohq/keyring:alpha. Cloudflare Workers and Vercel deploy the supported repository runtime directly because those platforms do not run the container image.

​
Before you deploy

Your platform guide walks through the provider-specific steps. Every production deployment needs:
  • a KMS or Vault that only the Keyring workload can use;
  • a public HTTPS endpoint restricted to Composio traffic;
  • the production Composio authentication values below; and
  • durable audit delivery plus health monitoring.
Open Project Settings → General and copy your organization ID. Organization IDs look like ok_example123456. The platform guide provisions the required encryption keys and stores the complete ENCRYPTION_CONFIG in its secret manager. Use workload identity instead of a long-lived cloud key. See Encryption and key hierarchy when you need the underlying key model.

​
Network access

Keyring needs a public HTTPS hostname, but it does not need to accept traffic from the entire internet. Permit TCP 443 from only these Composio production egress addresses:
Keep JWT verification enabled behind this allowlist. The network rule restricts the source, while the signed JWT binds each request to your Composio organization. The Composio Dashboard does not need a direct network path to Keyring.
Confirm the egress list through your Composio support channel before changing a production firewall. Review additions or replacements as security-policy changes.
Keyring needs outbound HTTPS access to the Composio JWKS endpoint, your KMS or Vault, approved provider origins, and your telemetry destination. The official image includes the reviewed Composio toolkit policy, so a standard deployment does not need a remote policy manifest.

​
Connect Keyring to Composio

After Keyring is available at its HTTPS endpoint, open Project Settings → Keyring. Add the Keyring URL for your organization, then enable Keyring for each project that should use it. Existing credentials continue working as they do today. They move to Keyring only when you ask Composio to migrate them, and the Composio team can assist with that migration.

​
Verify the deployment

Check the public endpoint before enabling a project:
Then use a connected account or run a tool that requires one. A successful flow produces a Keyring request with a request ID without logging the credential value. If the connection fails, use health and troubleshooting to check the public path, organization audience, KMS identity, and audit collector.
Infrastructure identity authorizes access to your KMS. It does not replace request authentication. Keyring still verifies a signed Composio token and provider policy on every credential operation.