Skip to main content
The official image runs Keyring as a non-root user in a small distroless container with no shell or package manager.

​
Pull the official image

alpha is the current supported image tag on Docker Hub. It is a moving tag; use a controlled rollout when adopting an update.

​
Create runtime configuration

Create keyring.env without provider credentials:
Replace AUTH_AUDIENCE with the Composio organization ID from Project Settings → General; the placeholder above is not a valid production audience. Replace the OTLP placeholders using the telemetry delivery guide. Running a collector beside Keyring is recommended for production. Create config.yaml using one of the KMS adapter examples. Prefer a workload identity so the file contains key references, not long-lived provider credentials.
Treat both files as secrets if either contains an OTLP credential, cloud credential, Vault token, private key, or access token. Do not bake them into the image.

​
Run the container

The process listens on 0.0.0.0 inside the container so port publishing works, while the example binds only to host loopback. Put a reviewed TLS reverse proxy or private load balancer in front of it before remote use.

​
Verify the deployment

​
Container-platform identity

With AWS adapters, credential_source: runtime_environment checks static AWS environment variables first, then ECS-compatible container credential endpoints. It supports ECS/Fargate task roles and EKS Pod Identity. It intentionally does not use EC2 IMDS or IRSA/web identity. The application refreshes expiring container credentials and may use still-valid cached credentials during a transient endpoint failure. Provider IAM must allow only the configured root and transfer keys.

​
Healthcheck behavior

The image includes a healthcheck for /healthz. Because the container has no shell or diagnostic utilities, perform troubleshooting from the host, a sidecar, or your platform tooling.