Skip to main content
All three platforms follow the same pattern: they invoke a start command on a long-running container. Wrap it with capy run and set SECRETS_BLOB + PROJECT_KEY in their env var UI.

​
The pattern

The platform runs npm start (or equivalent). With SECRETS_BLOB and PROJECT_KEY both set, capy run decrypts the blob at boot and spawns node server.js with the plaintext values in process.env. It doesn’t read .env in this mode. The child runs until killed; capy run forwards SIGTERM, SIGINT, and SIGHUP to it and exits with its exit code. Any runtime works - just swap the inner command:
  • Python: capy run -- python app.py
  • Go: capy run -- ./my-binary
  • Ruby: capy run -- bundle exec rails server
Two things worth knowing before you paste the values in:
  • Set both variables or neither. With only one of the two, capy run refuses to guess which mode you meant and exits 1.
  • Config vars the platform sets itself win. The decrypted values are merged underneath the existing process.env, so a DATABASE_URL you also set in Railway’s, Render’s, or Heroku’s own store overrides the one Capy delivered.

​
Railway

  1. Install: add @capysc/cli as a dep (bun add @capysc/cli). Railway will install it during the build step.
  2. Start command: either use the start script in package.json (Railway runs npm start by default) or set a custom start command in Railway’s service settings: capy run -- <your cmd>.
  3. Env vars: set SECRETS_BLOB and PROJECT_KEY in Variables (Railway dashboard).
  4. Deploy: push to the connected git branch.

​
Render

  1. Install: @capysc/cli as a dep.
  2. Start command: in Render’s service settings → Start Command, set capy run -- <your cmd>.
  3. Env vars: Environment tab → add SECRETS_BLOB and PROJECT_KEY.
  4. Deploy: push, Render picks up the new build.

​
Heroku

@capysc/cli needs to be in dependencies (not devDependencies) so Heroku installs it for the runtime dyno.

​
Per-environment secrets

Each platform has a separate env var store per service / environment. capy deploy mints from whatever .env holds when you run it, which is the secret branch you currently have checked out - so switch branches first, then mint one pair per environment:
Every mint is its own deploy token, so you can revoke one environment without touching the others:
  • Railway: create a new Capy deploy token for each Railway environment (Production, Staging, etc.)
  • Render: same - each service instance gets its own token
  • Heroku: each Heroku pipeline stage gets its own config vars

​
Revocation

capy deploy list shows your active tokens; pass the token id to capy deploy revoke to disable it. Revoking a token prevents future deployments from using it. If the values themselves may be exposed, change them at their source - capy rotate covers the credentials you set up with capy connect - then mint a fresh deploy token.
Last modified on August 11, 2026