relic push copies the secrets of one Relic environment into a deploy platform’s own secret store. Use it when a platform reads secrets at runtime and you can’t wrap the process with relic run.
How a push works
1
Connect to the platform
Relic finds the platform credentials and target (project, Worker, repository, or app). If credentials are missing, the command stops with the exact login command to run, before anything is decrypted.
2
Read existing names
Relic lists the secret names already on the platform. Values are read back only where the platform allows it (Vercel variables of the encrypted type), so unchanged values can be skipped.
3
Fetch and decrypt
Relic fetches the environment from the server and decrypts it locally. This records a
secrets.pushed audit log entry with the target, destination, and count. It never contains values.4
Show the plan
The plan lists names only, grouped as added (
+), updated (~), removed (-, only with --prune), and unchanged (=).5
Confirm and write
Production-like targets ask for confirmation. In CI and other non-interactive shells you must pass
--yes.Options
Use
--scope to push only what a target needs. For example, a frontend usually needs client and shared secrets but not server ones:
Vercel
Authentication. Relic uses
VERCEL_TOKEN when set. Otherwise it reads the Vercel CLI login from auth.json in the Vercel CLI data directory:
If neither is available, run
vercel login or create a token at vercel.com/account/tokens.
Variable types. New variables are created as sensitive, so their values can’t be read back from the dashboard or API. Vercel doesn’t allow sensitive variables in the development target, so pushes that include development create encrypted variables instead. Existing variables keep their current type and only have their value replaced.
Because sensitive values can’t be read back, existing sensitive variables always appear as updates in the plan.
Production-like: any push that includes the production target.
Cloudflare Workers
Worker names follow wrangler’s rules: with
--wrangler-env staging, Relic targets env.staging.name when your config sets it, and <name>-staging otherwise.
Authentication. When wrangler is installed (in node_modules/.bin or on your PATH), Relic runs wrangler secret bulk with JSON on stdin, using your existing wrangler login. Wrangler also honors CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID if you set them. If wrangler isn’t installed, Relic calls the Workers API directly with CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID (or account_id from your wrangler config). The token needs the Workers Scripts: Edit permission.
If neither works, run npx wrangler login.
Production-like: pushes without --wrangler-env, or to an environment whose name looks like production (for example production, prod, or live).
GitHub Actions
Relic uses the GitHub CLI and sends each value to
gh secret set on stdin. Run gh auth login first, or set GH_TOKEN.
GitHub rejects names that start with GITHUB_, names with characters other than letters, digits, and underscores, empty values, and values over 48 KB. Relic checks these before writing anything.
Production-like: repository-level secrets, and environment secrets whose environment name looks like production.
Fly.io
Relic pipes secrets to
fly secrets import on stdin. Run fly auth login first, or set FLY_API_TOKEN. Values that start or end with quotes or whitespace are rejected, because fly secrets import can’t store them exactly.
Production-like: always, because setting secrets restarts the app unless you pass --fly-stage.
CI/CD
In CI, pass--yes after you’ve reviewed the plan. Without it, relic push exits with code 2 instead of writing.
relic run. See Service Accounts.
Exit codes
Missing required flags such as
--environment are reported by the argument parser and exit with code 1.