Skip to main content
capy deploy has two paths. A deploy target saves a platform configuration in .capy/deploy.json, delivers selected values through that adapter’s delivery model, and either deploys immediately or opens a deploy PR. The token-and-instructions path creates a runtime pair for platforms where you configure the process yourself.

​
The flow

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.
  1. Run capy first. A deployment needs keep.lock, an active secret branch, and secrets to deliver. Deploying is unavailable in local-only mode.
  2. Pick a platform. For a supported target, choose target mode and configure its name, branch, variable set, and direct or CI delivery mode. Capy saves the non-secret configuration in .capy/deploy.json.
  3. For token mode, Capy mints a fresh pair and serves local instructions. The generated runtime variables are SECRETS_BLOB and PROJECT_KEY. Keep them together.
You paste those into the platform’s UI (or its CLI equivalent), redeploy, and capy run decrypts them at build or boot time. Released target adapters are Cloudflare Workers, Cloudflare Pages, Vercel, AWS SSM Parameter Store, and Dokploy. Fly.io, Railway, and Render appear as planned adapters; use their platform tools or the token path until an adapter ships. See capy deploy for the available flags.

​
What gets injected

Two env vars on your platform:
  • SECRETS_BLOB - base64 of the deploy ID, a service-wrapped portion, and the encrypted environment map.
  • PROJECT_KEY - a hex-encoded 32-byte project key. It is combined locally with the service response to derive the decrypt key.
At build or boot time, capy run detects both variables, sends the service-wrapped portion to Capy, and decrypts the environment map in memory. See Running your app for the runtime’s compatibility behavior.

​
Two deployment patterns

The split is dictated by whether you control the process entrypoint. Platforms that invoke your handler directly (serverless, Edge) don’t let you wrap with capy run at request time, so you decrypt at build and inline the results.

​
Revocation

Every mint has a deploy id. List this project’s tokens, then revoke one:
capy deploy list prints each token’s id prefix, its active or revoked status, and the date it was created; pass that id prefix to capy deploy revoke. Revocation is server-side, so a revoked token stops bootstrapping new builds or cold starts immediately - capy run can no longer fetch the service key it needs. Any process that already decrypted keeps serving traffic until it recycles: capy run resolves the key once at startup, hands the plaintext values to its child process, and nothing re-checks revocation after that. Practical timing:
  • Long-running servers - revocation propagates on next deploy or restart.
  • Containers - revocation takes effect when the next container starts.
  • Edge / serverless isolates - propagates as isolates recycle (seconds to minutes under load, longer when idle).
Revocation gates new decrypts only. To cut off a process that is already running, restart or redeploy it after revoking. If the secret values themselves may be exposed, change them at their source - capy rotate covers the credentials you set up with capy connect - then mint a new deploy token.

​
Platform walkthroughs

Vercel

Vercel target delivery.

Cloudflare Pages / Workers

Target delivery to Workers or Pages.

Docker

capy run as the container entrypoint.

VPS / droplet

Deploy tokens and capy run on a box you manage yourself.

Fly.io

Runtime-pair setup while the target adapter is planned.

Railway / Render / Heroku

Long-running hosts with capy run in the start command.

GitHub Actions

Wrap build steps with capy run in CI.

AWS Lambda

AWS SSM delivery and container runtime-pair options.

​
What’s next

capy deploy (CLI reference)

Command flags and flow details.

Cryptography

The deploy token double-wrap in full.
Last modified on October 2, 2026