- Standalone (Docker)
- Embedded (SDK)
Run Key0 as a pre-built Docker container alongside your existing API. No code changes required.
Best for teams that want a quick deploy, prefer Docker-native workflows, or want to avoid touching application code.
- Published to Docker Hub as
key0ai/key0 - Configure via the browser-based Setup UI at
/setup, or through environment variables - Token issuance is delegated to your
ISSUE_TOKEN_APIendpoint — Key0 POSTs to it after a successful payment and forwards the credential back to the agent - Docker Compose profiles control which infrastructure is managed for you:
| Profile | What it includes |
|---|---|
| (none) | BYO Redis and Postgres |
redis | Managed Redis |
postgres | Managed Postgres |
full | Managed Redis + Postgres (batteries included) |
Comparison
| Standalone (Docker) | Embedded (SDK) | |
|---|---|---|
| Setup | docker compose up then browser Setup UI | npm install @key0ai/key0 |
| Configuration | Setup UI or environment variables | TypeScript SellerConfig object |
| Token issuance | Delegated to your ISSUE_TOKEN_API endpoint | Your fetchResourceCredentials callback |
| Infrastructure | Docker Compose manages Redis + Postgres | You provide store instances (Redis, Postgres, or in-memory) |
| Best for | Quick deploy, no code changes, Docker-native workflows | Full control, existing app integration |
Which should I choose?
Choose Standalone if you have an existing API and want to add agent payments without modifying your application code. Key0 runs as a sidecar container and calls back to your token endpoint. Choose Embedded if you want the payment flow to live inside your server process. You get direct access to theChallengeEngine, full control over credential issuance, and no extra container to manage.
Both modes support the same transports (REST x402, A2A, MCP), the same on-chain verification, and the same refund logic. You can start with one and switch later.