Synopsis
Description
Sets up secret delivery for the current project. Capy can issue a deploy token with platform guidance, or configure a target that performs deployment work.
Run capy in the project first - capy deploy needs a keep.lock and at least one secret in .env. The command is disabled in local-only mode.
Token and docs
The default path. Capy mints a deploy token, then serves a temporary page on 127.0.0.1 and opens it in your browser. That page carries the setup instructions for the platform you picked, plus two environment variables to copy into your platform’s secret store. It shuts down when you press Ctrl+C, or after five minutes. If the page can’t be served, Capy prints both values in the terminal instead.
SECRETS_BLOB - a base64 blob containing the deploy ID, an outer-wrapped key material blob (held by the Capy service), and the encrypted env vars. Self-contained.
PROJECT_KEY - a hex-encoded 32-byte key. It is not sent to the Capy service.
At build or boot time capy run detects both variables, sends only the outer-wrapped portion of SECRETS_BLOB to the service, receives a derived service key (the service verifies the deploy token isn’t revoked first), combines that with PROJECT_KEY locally to reconstruct the decrypt key, and decrypts the env vars in process memory. The service never learns the project key or the plaintext values.
The token-and-docs picker offers setup instructions for these platforms:
- Managed runtimes: Vercel, Netlify, Cloudflare Pages, Cloudflare Workers, Render, Fly.io, Railway, Heroku, DigitalOcean App Platform, Google Cloud Run, Azure App Service, AWS App Runner.
- Containers and orchestration: Docker, Docker Compose, Kubernetes, Helm, Nomad, AWS ECS.
- CI/CD: GitHub Actions, GitLab CI, CircleCI, Jenkins.
- Infrastructure tooling and self-hosted: Terraform, Pulumi, AWS CDK, Kamal, Dokku, CapRover, Coolify, systemd.
Pick your platform in the terminal; Other… sits at the top of the list for anything not covered. --platform <id> skips the picker - ids are the lowercase, hyphenated forms of the names, with a few shortened (e.g. fly for Fly.io, digitalocean for DigitalOcean App Platform). Capy remembers the platform you picked in .capy/config and offers it as the default next time.
Target mode
Target mode configures a saved deployment target. The 0.9.7 adapter registry contains Cloudflare Workers (cf-worker), Cloudflare Pages (cf-pages), Vercel (vercel), AWS Systems Manager Parameter Store (aws-ssm), and Dokploy (dokploy). Capy may write target configuration to .capy/deploy.json, run preflight checks, and deploy or prepare a CI handoff according to the selected adapter and mode.
Capy saves each target to .capy/deploy.json. capy deploy <target> redeploys a saved target by name. To re-enter the target setup picker, run capy deploy --connect --edit; when exactly one target is saved, Capy pre-fills it. capy deploy targets lists saved targets, and capy deploy targets-remove <name> removes one.
GitHub Actions token setup
The GitHub Actions integration supports repository or environment scope. Use --platform github-actions, then select its integration path with --mode target if you want to skip the mode picker:
See Deploying for the full delivery flow.
Flags
Token mode at runtime
This section applies to the token-and-docs path. Wrap your app (or its build step) with capy run -- <your command>. capy run enters deployed mode when a complete runtime pair is set and spawns the child with plaintext values in its environment. It supports both SECRETS_BLOB / PROJECT_KEY and _SECRETS_BLOB / _PROJECT_KEY; a half-configured pair makes it exit rather than guess.
For long-running servers (Fly, Render, Railway, Heroku, containers), set it as the entrypoint:
For build-time inlining (Vercel, Netlify, any build-then-deploy platform), wrap the build:
In both cases the token runtime pair is the Capy configuration your platform needs. Target mode has different behavior: adapters such as Vercel and Dokploy can write values directly to their target instead of using capy run. See Build-time inlining for the Next.js walkthrough.
Revocation
Every mint has a deploy id. List this project’s tokens, then revoke one by id (a prefix is enough):
capy deploy list prints each token’s id prefix, its active or revoked status, and the date it was created.
Revocation is server-side: a revoked token immediately stops working for new builds and boots, because capy run can no longer fetch the service key it needs to reconstruct the decrypt key. Already-running processes that have reconstructed the key keep functioning.
See also
Last modified on October 2, 2026