CLI commands

seekrit <command> [options]. At runtime a service token selects the org, app, and environment — so seekrit run/export need no config file. Management commands select their target with --org/--app/--group/--env flags (plus --branch for an ephemeral branch config), falling back to the optional seekrit.json written by seekrit init.

Environment variables

Precedence: environment variables override values saved by seekrit login in ~/.config/seekrit/config.json. seekrit run additionally reads these from its .env file(s) (below process.env, above saved config) — see Running & exporting.

Output conventions

Everything the CLI can do from the dashboard, it can do from the terminal, and every listing reads the same way:

• Listings print an aligned table with a header when stdout is a terminal, and plain tab-separated rows with no header when it is piped — so seekrit app list | cut -f1 keeps working.
• --json on any read command prints the API's own response instead. Use it when a table would flatten something you need (ids, nested config, timestamps).
• Data goes to stdout; everything else goes to stderr — confirmations (created app …), "nothing to list" notes, and pagination hints. A command's stdout is always safe to pipe.
• Destructive commands ask first. Anything that deletes or revokes prompts for confirmation at a terminal, and refuses outright when there is no terminal unless you pass --yes (or, for sync enable, --acknowledge-decryption).
• list is aliased as ls, and rm as delete, wherever both read naturally.

Auth & identity

seekrit login

With no flags, signs you in through your browser: it prints a URL and a pairing code, opens the URL when you press [Enter], and waits while you authorize the device in the dashboard (re-entering your authenticator code if you have one). The session it saves authenticates as you — every org you belong to, at your role — and lasts 90 days. Nothing to copy and paste, and no org, app, or environment to choose.

Passing a credential stores that instead and skips the browser entirely — the path machines and CI use.

A browser session carries no key material, so reading a secret's value still unlocks your private key with your passphrase (SEEKRIT_PASSPHRASE, else prompted) — exactly as the dashboard does. Service tokens carry their own key and don't prompt, which is why they remain the right credential for unattended jobs.

seekrit logout

Forget the saved credentials. A browser-authorized session is also revoked server-side, so the token can't be used again; a service token is only removed locally (other machines may hold it — revoke it with seekrit token revoke). Machine (M2M) credentials are left in place.

seekrit whoami

Show the authenticated identity. For a service token, prints its bound org/app/env scope; for a browser session, names the session so you can revoke it.

seekrit keys setup

Generate your P-256 keypair and upload your public key plus a passphrase-encrypted private key. Run once per account. Honors SEEKRIT_PASSPHRASE, otherwise prompts.

Resources

seekrit init

--org <slug> --app <slug> — write seekrit.json naming default org + app for management commands. Environment-independent and safe to commit — it never pins an environment (the token does that at runtime).

Organizations (seekrit org)

Applications (seekrit app)

Environments (seekrit env)

seekrit branch create

<slug> [--org <slug>] [--app <slug>] --from <env> [--name <name>] [--ttl <duration>] [--no-share] — fork an application environment into an ephemeral branch (a per-PR / preview config). The branch inherits its parent's secrets by layering at read time — nothing is copied or re-encrypted — and stores only what you override on it. Generates the branch's own data key locally and, unless --no-share, wraps it to everyone who already holds a grant on the parent.

--ttl accepts 30m, 12h, 7d, 2w, … or never (default 7d, max 30 days). Expired branches are deleted automatically, along with their overrides, key grants, and any service token bound to them.

seekrit branch list

[--org <slug>] [--app <slug>] [--env <slug>] — list branches in an application, or just those of one environment. Prints slug, id, and expiry.

seekrit branch delete

<slug> [--org <slug>] [--app <slug>] — tear down a branch and every value it overrode. The environment it overlays is untouched. Aliased as branch rm.

Shared groups (seekrit group)

A group is a reusable secret bag shared across applications, holding one environment per slug (its variants).

Composition (env groups)

Compose shared groups into an application environment. At resolve time each group is matched to the environment whose slug matches the app environment's (or a --with override).

Secrets

Every secrets command targets one environment via flags: an application environment (--app --env, or the config's app + --env) or a group environment (--group --env). --org is inferred from seekrit.json or a lone org.

JSON and multi-line values

A value is an opaque string to seekrit — a service-account key, a PEM block, or a certificate chain is stored and delivered byte-for-byte. The only thing that needs care is getting it in without a shell or a .env file mangling it first. Read it from a file and neither is involved:

seekrit secrets set GOOGLE_SERVICE_ACCOUNT --file ./service-account.json \
  --app storefront --env production
cat ./key.pem | seekrit secrets set TLS_KEY - --app storefront --env production

Both drop a single trailing newline and store everything else exactly as written. To read one back formatted:

seekrit secrets get GOOGLE_SERVICE_ACCOUNT --pretty --app storefront --env production

--pretty only re-indents values that parse as JSON; anything else prints unchanged. Without it, output stays byte-exact, which is what you want when piping to a file or another tool.

.env syntax

seekrit secrets import, the --env-file overlays, and the dashboard's paste .env tab all use one parser — as does the seekrit-run launcher, byte-for-byte:

A quoted value may span lines — it runs to its closing quote, wherever that lands. That is what makes a pretty-printed credential storable:

GOOGLE_SERVICE_ACCOUNT='{
  "type": "service_account",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvQ…\n-----END PRIVATE KEY-----\n"
}'

Single quotes are the right choice for JSON: the value is full of double quotes and \n escapes that must survive as written, and single quotes pass them through untouched.

seekrit export --format dotenv writes this same syntax and quotes as needed, so exporting and re-importing a value round-trips exactly, escapes included.

Point-in-time restore

Every write appends to the secret's history, so a bad value is always one command away from being undone:

seekrit secrets history DATABASE_URL --app storefront --env production

VERSION  WHEN                      BY                  NOTE
v3       2026-07-24T18:22:05.994Z  user:usr_KvxTL40S…  current
v2       2026-07-24T18:19:41.769Z  user:usr_KvxTL40S…
v1       2026-07-24T18:02:13.539Z  user:usr_KvxTL40S…

Check what you're rolling back to, then roll back:

seekrit secrets get DATABASE_URL --version 2 --app storefront --env production
seekrit secrets restore DATABASE_URL 2 --app storefront --env production

Restoring is a roll-forward: v2's value is written back as v4, so nothing in the history is lost and the rollback is itself undoable. Because the server simply replays ciphertext it already stores, no key is involved — a machine (M2M) credential that cannot decrypt the value can still roll it back. The restore is audited as secret.restored.

Running & exporting

Both resolve a layered environment for the current principal:

group secrets  <  app-env secrets  <  .env file  <  process env   (highest wins)

With a service token, org/app/env come from the token. As a logged-in user, pass --app --env (and --org if ambiguous).

Once the layers are merged, ${OTHER_SECRET} references inside values are expanded — locally, in the same process that decrypted them.

seekrit run -- <command…>

Run a command with the resolved environment injected. Everything after -- is the command.

SEEKRIT_TOKEN=skt_… seekrit run -- ./start-server
# swap only the auth group to its staging slice for this boot:
seekrit run --with auth-providers=staging -- pnpm dev

run reads its .env file(s) before authenticating, so SEEKRIT_TOKEN and SEEKRIT_API_URL can live in .env — resolved as process.env > .env > saved config, matching the seekrit-run launcher. Drop a token into a project's .env and seekrit run uses it with no global login.

Resolving seekrit secrets is best-effort: if no credentials are configured or seekrit can't be reached (network, auth, or decryption failure), run logs a warning to stderr and still launches the command with just the .env overlay and process.env. This mirrors the seekrit-run launcher. (seekrit export does not degrade — it errors if it can't resolve the secrets.)

run is a transparent wrapper: it forwards termination signals (SIGINT from Ctrl-C, plus SIGTERM/SIGHUP/SIGQUIT) to the command and every process below it, then stays alive until the command exits and exits with its status (signal death is re-raised, so Ctrl-C yields 130). Relaying down the whole process tree, rather than to the one process, is what makes Ctrl-C reliably tear down commands that spawn their own children (npm/pnpm scripts running nodemon, for example), since those don't always pass the signal on themselves.

The command keeps your terminal: run does not put it in a separate session, so it stays visible in ps as usual, still gets the terminal's own Ctrl-C and its hangup when you close the window, and can still prompt on /dev/tty for things like a git credential or an SSH passphrase.

Nothing the command started outlives run. Once the command itself has exited, anything still alive underneath it has both ignored the signal and lost the process that started it, so nothing is left to stop it — not the terminal either, which only ever hangs up its own foreground group. Rather than trust it, run escalates: SIGTERM, then SIGKILL two seconds later, printing the pids it had to force-kill. A process that ignores both is usually a signal handler in the app that cleans up but never exits — in Node, process.on("SIGINT", …) replaces the default action, so the process stops dying on Ctrl-C unless the handler itself exits. Watch for that if you see the message; it names the pids. A command that exits on its own is never chased this way, so if it deliberately leaves a daemon running in the background, that keeps working.

The compiled seekrit-run launcher replaces itself with the command (exec), so signals and the process tree behave exactly as if you had run the command directly — with no wrapper left to escalate, cleaning up a command that ignores signals is up to the command. See its exit-code notes below.

seekrit export

Print the resolved secrets (managed layers + .env, without process.env). --format <dotenv|json|shell> (default dotenv).

seekrit-run launcher

seekrit-run is a separate, compiled single-file binary — a dependency-free seekrit run for machines (containers, CI, agents). It is service-token only and reproduces seekrit run's precedence and .env parsing exactly. See the launcher guide for install and container usage.

seekrit-run [OPTIONS] [--] <command> [args...]
seekrit-run run [OPTIONS] [--] <command> [args...]   # `run` is optional

Like seekrit run, it degrades gracefully: a missing/malformed token or an unreachable API is logged to stderr, and the command runs with just .env + the live environment. Exit codes: 2 usage error, 1 a local failure (an unreadable explicit --env-file, or a reference cycle in one), 127 command not found; otherwise the command's own exit code (Unix exec). Honors HTTPS_PROXY / ALL_PROXY. Its default API URL is the hosted https://api.seekrit.dev — the same default the Node seekrit run uses when nothing else is configured.

Last-known-good cache

Off by default. With --cache, a successful resolve is written to disk and a later run falls back to it when the seekrit API cannot be reached — so a deploy, a CI job, or an agent boot still works during an outage.

seekrit run --cache -- ./start-server

seekrit-run: could not reach the seekrit API: … — using cached secrets fetched 6m ago

Only the encrypted response is stored — ciphertext plus your token's wrapped data keys, the same bytes the API serves. Decrypting still requires the service token's private key, so the file is no more sensitive than the token sitting beside it; it is written 0600 inside a 0700 directory. The zero-knowledge invariant is untouched: nothing is written in plaintext, and nothing new is sent to the server.

How it behaves:

• Live first, always. Every invocation tries the API before touching the cache, so a recovered network is picked up immediately — the cache never serves a request that could have been answered fresh.
• A refused resolve does not fall back. If the API answers 401/403/404, the entry is deleted and the command fails as it would have anyway. Revoking a token still takes effect on the next run. Only "the API is unreachable" — a network failure, a 5xx, or a rate limit — uses the cache.
• Bounded by --cache-max-age (default 24h). Past that, the entry is ignored and pruned.
• Scoped to the exact request. The entry is keyed by API URL, token, --branch, and --with overrides, so a different environment or override never reads another's copy.
• Shared with seekrit-run. Both use the same file format and directory, so whichever one runs first warms the cache for the other.

Two trade-offs worth stating plainly, both consequences of a copy that outlives the network:

• A revoked token keeps working offline until the entry expires. That window is exactly --cache-max-age, and it only applies while the API is unreachable (a reachable API that refuses the token clears the entry immediately). Set a shorter max-age if that window matters more to you than the outage coverage.
• A run served from cache makes no resolve call, so it produces no env.resolve_denied audit entry. If you monitor for revoked credentials still in use, a cached client is invisible to that signal until it next reaches the API.

For the long-lived integrations, the same cache is configured in their own way: [cache] enabled = true in the egress proxy's config, and cache.enabled=true in the Kubernetes chart. Both also retry in the background and switch to live secrets as soon as the API answers.

Access

Who can decrypt an environment. Every command targets the environment with --env plus --app or --group.

seekrit grant --user … --env … is the bare grant verb and behaves exactly as it always has; list and rm are subcommands beside it.

Service tokens

An admin token can also be bound to an environment (pass --admin --app --env) to both provision structure and decrypt that environment.

Honey tokens

Decoy credentials that unlock nothing and alert your admins the moment anyone presents one. See the honey tokens guide.

A decoy is byte-for-byte indistinguishable from a real skt_ token, and presenting one returns exactly the same 401 unknown service token an unregistered token gets — so an attacker probing credentials can't tell bait from a typo. Plant them where a thief would look, never anywhere your own tooling reads: a deploy script that tries one by mistake trips the alarm just as loudly.

Agent integration

seekrit mcp

Run an MCP server over stdio so AI agents (Claude Code and other MCP clients) can drive seekrit as tools. It reads the same credentials as every other command — a SEEKRIT_TOKEN, machine credentials (SEEKRIT_CLIENT_ID + SEEKRIT_CLIENT_SECRET, which auto-mint an admin token), or the saved config.

# Register with Claude Code (token selects the org; admin token enables provisioning):
SEEKRIT_TOKEN=skt_… claude mcp add seekrit -- seekrit mcp

For a fully autonomous agent, pass machine credentials instead — the server mints and caches its own admin token from them (see the AI agents guide):

claude mcp add seekrit \
  --env SEEKRIT_CLIENT_ID=… --env SEEKRIT_CLIENT_SECRET=… -- seekrit mcp

All decryption happens locally, in this process — the server exposes the tools that touch plaintext (secret values, data keys, decryption-capable grants), which is why it runs on your machine rather than a hosted endpoint. Call get_started first — an in-protocol tool (and the server's instructions, shown to the model on connect) that returns the recommended first-project recipe so an agent landing here mid-context can orient itself. Other tools include create_org/create_app/create_env, set_secret/get_secret, create_token, grant_env, and run_command (inject secrets into a subprocess without returning their values). Because stdin is the transport, user-auth sessions that decrypt need SEEKRIT_PASSPHRASE set (token auth needs nothing extra). Prefer run_command over get_secret with reveal:true so plaintext never enters the agent's context.

Temporary Postgres credentials (pg)

Mint short-lived database logins that auto-expire. Minting happens client-side: the password and its SCRAM verifier are generated on your machine and only the verifier is sent, so the plaintext never reaches seekrit or Postgres at rest. See Temporary access.

# Register a read-only target (prints the group-role setup SQL to run once):
SEEKRIT_PG_ADMIN_URL=postgres://admin:…@db.example.com:5432/app \
  seekrit pg target add --name prod-db --host db.example.com --database app --access readonly

# Lease a 30-minute credential and hand the URL straight to psql:
psql "$(seekrit pg lease prod-db --ttl 30m)"

Temporary MySQL / MariaDB credentials (mysql)

The MySQL/MariaDB analog of pg. Minting is client-side too: the password and its mysql_native_password hash are generated on your machine and only the hash is sent, so the plaintext never reaches seekrit or MySQL at rest. Presets apply their GRANTs inline per user (no one-time setup step), and there is no account-level expiry — the broker drops the user at the deadline. See Temporary access.

# Register a read-only target (no setup SQL needed — grants apply inline):
SEEKRIT_MYSQL_ADMIN_URL=mysql://admin:…@db.example.com:3306/app \
  seekrit mysql target add --name prod-db --host db.example.com --database app --access readonly

# Lease a 30-minute credential and hand the URL straight to the mysql client:
mysql "$(seekrit mysql lease prod-db --ttl 30m)"

Temporary Redis credentials (redis)

The Redis (6+) analog of pg/mysql. Minting is client-side too: the password and its SHA-256 digest are generated on your machine and only the digest is sent (ACL SETUSER … on #<digest>), so the plaintext never reaches seekrit or Redis at rest. Presets apply their ACL rules inline per user (no one-time setup step), and there is no account-level expiry — the broker deletes the ACL user at the deadline. See Temporary access.

# Register a read-only target (ACL rules apply inline, no setup step):
SEEKRIT_REDIS_ADMIN_URL=rediss://default:…@cache.example.com:6379 \
  seekrit redis target add --name prod-cache --host cache.example.com --access readonly

# Lease a 30-minute credential and hand the URL straight to redis-cli:
redis-cli -u "$(seekrit redis lease prod-cache --ttl 30m)"

Agent egress proxy (proxy)

Fetch, configure, and run seekrit-proxy without a Rust toolchain and without hand-writing a config file. The proxy itself is unchanged by these commands — they resolve the released binary (verifying its SHA-256) and generate the same TOML you would otherwise write.

Generating a config

init and run share these flags. Pass presets, ad-hoc hosts, or an agent identity — the last takes the rules from published policy and cannot be combined with the first two, because server-policy mode rejects local rules rather than silently ignoring them.

init additionally takes -o, --out <path> (default ./seekrit-proxy.toml), --print to write to stdout instead, and --force to overwrite.

run additionally takes -c, --config <path>, --proxy-version <version>, and --print-config. With no generation flags it runs the config file as-is.

Resolving the binary

Downloads are cached under $XDG_CACHE_HOME/seekrit/proxy/v<version>/<target>/, so the fetch happens once per version. A binary already on PATH is deliberately not used: silently running a different version than the one the CLI pins is the kind of surprise that costs an afternoon.

Self-hosted provisioner (provisioner)

Helpers for the remote executor — the seekrit-provisioner daemon that runs a target's provisioning SQL inside your own network, so seekrit never sees the database admin credential.

Temporary SSH access (ssh)

Issue short-lived SSH certificates. seekrit acts as a certificate authority: target add generates a CA keypair locally (only the private half is wrapped and uploaded) and prints the public key to install on your hosts. Minting generates an ephemeral keypair on your machine and sends only the public key; the signed certificate comes back and the private key never leaves. See Temporary access.

# Create a CA target and install the printed CA key on your hosts:
seekrit ssh target add --name prod-fleet --host bastion.example.com --user deploy --principal deploy

# Issue an 8-hour cert, then run the ssh command it prints:
seekrit ssh lease prod-fleet --ttl 8h

Temporary AWS credentials (aws)

Mint short-lived AWS credentials via STS AssumeRole (a tier-2 provider — the credential comes back wrapped to your machine's ephemeral key, never in the clear through seekrit). target add registers one assumable IAM role and wraps a base IAM credential (needs only sts:AssumeRole) to the broker. Minting generates an ephemeral P-256 keypair locally, sends only the public key, and unwraps the returned credential on your machine. See Temporary access.

# Register a role (base creds from your AWS env vars), then source a 1h credential:
seekrit aws target add --name prod-deploy \
  --role-arn arn:aws:iam::123456789012:role/seekrit-deploy --region us-east-1

eval "$(seekrit aws lease prod-deploy --ttl 1h)"
aws sts get-caller-identity

Temporary GCP credentials (gcp)

Mint short-lived GCP access tokens via IAM generateAccessToken (a tier-2 provider — the token comes back wrapped to your machine's ephemeral key, never in the clear through seekrit). target add registers one impersonable service account and wraps a base service-account key (needs roles/iam.serviceAccountTokenCreator on the target) to the broker. Minting generates an ephemeral P-256 keypair locally, sends only the public key, and unwraps the returned token on your machine. See Temporary access.

# Register a service account (source key from GOOGLE_APPLICATION_CREDENTIALS),
# then source a 1h token:
seekrit gcp target add --name prod-deploy \
  --service-account deploy@my-project.iam.gserviceaccount.com

eval "$(seekrit gcp lease prod-deploy --ttl 1h)"
gcloud storage ls

Temporary MongoDB credentials (mongodb)

Mint short-lived MongoDB users (a tier-2 provider — MongoDB hashes the password server-side, so the broker generates it, runs createUser, and returns the credential wrapped to your machine's ephemeral key, never in the clear through seekrit). target add registers one cluster and wraps an admin mongodb:// connection string (needs userAdmin on the database) to the broker. Minting generates an ephemeral P-256 keypair locally, sends only the public key, and unwraps the returned credential on your machine. Unlike AWS, revoke is real — it drops the user. See Temporary access.

# Register a cluster (admin creds from SEEKRIT_MONGODB_ADMIN_URL), then lease a 1h user:
export SEEKRIT_MONGODB_ADMIN_URL='mongodb://admin:pw@mongo.example.com:27017/?authSource=admin'
seekrit mongodb target add --name prod-app --database app --access readonly

eval "$(seekrit mongodb lease prod-app --ttl 1h)"
mongosh "$MONGODB_URI"

Managed keys (kms)

Client-side managed keys for application-layer encryption and signing. Material is generated locally and wrapped to grantees; the server never sees it. See the Managed keys guide.

# Encrypt a field, bound to its context, then read it back:
echo -n "$SSN" | seekrit kms encrypt --key pii --context "field=ssn" > ssn.enc
seekrit kms decrypt --key pii --context "field=ssn" < ssn.enc

# Sign a release and verify it:
echo -n "release-v1.2.3" | seekrit kms sign --key release-signer > r.sig
echo -n "release-v1.2.3" | seekrit kms verify --key release-signer --signature "$(cat r.sig)"

Secret rotation (rotation)

Managed, scheduled replacement of a stored secret's value — and, for the database kinds, of the password on the account it belongs to. (admin). Enabling rotation wraps the environment's data key to your org's rotator key locally; see the rotation guide and Secret rotation.

Every command accepts a rotation id (rot_…) or the secret's name when that name rotates in only one environment. Durations accept s/m/h/d suffixes (minimum 5 minutes, maximum 365 days).

# Re-key an existing Postgres role weekly, against a registered target:
seekrit rotation enable DATABASE_PASSWORD --app web --env production \
  --kind postgres --target prod-db --username app_user --every 7d --now

# A value only your own code checks — nothing external is contacted:
seekrit rotation enable API_SIGNING_KEY --app web --env production \
  --kind generated --every 30d

seekrit rotation list
seekrit rotation rotate DATABASE_PASSWORD   # e.g. after a suspected exposure

Customer-controlled recovery (recovery)

Org-scoped M-of-N recovery. The recovery key is generated and split locally; seekrit stores only its public half and shares it cannot open. Management is (admin); any custodian can approve a ceremony. See the recovery guide.

# Enable 3-of-5 recovery, then check coverage:
seekrit recovery setup --threshold 3 \
  --custodian alice@example.com --custodian bob@example.com --custodian carol@example.com \
  --custodian dan@example.com --custodian erin@example.com
seekrit recovery status

# Run a ceremony: start it, custodians approve, then the target completes.
seekrit recovery request                 # prints rrq_…
seekrit recovery approve rrq_XXXXXXXX     # each custodian, until the quorum is met
seekrit recovery complete rrq_XXXXXXXX

Your account

Your devices and your email preferences. Both are per-user, not per-org, so neither takes --org.

Audit

seekrit audit

Print the org's audit trail — the append-only record of every mutation. Admins only.

When more entries remain, the next cursor is printed to stderr so it doesn't corrupt piped output.

seekrit audit actions

List every action the trail can record — the vocabulary for --action.

# Everything that changed who can decrypt something, as JSON:
seekrit audit --action env.key_granted --all --json

Audit export (log-sink)

Ship every audit row to your own OTLP/HTTP collector (SIEM) within about a minute of it being written. Admins only. Header values are write-only — encrypted at rest and never returned — so show reports only the header names.

seekrit log-sink set https://collector.example.com/v1/logs \
  --header "Authorization: Bearer $SIEM_TOKEN"
seekrit log-sink test

Third-party sync

Push an environment's resolved secrets to a platform that keeps its own copy: Vercel project env vars, Cloudflare Worker secret bindings, Cloudflare Pages env vars, Cloudflare Secrets Store secrets, Railway service variables, AWS Secrets Manager secrets, AWS SSM parameters, a Render service or environment group, a Fly.io app's secrets, a Northflank secret group, DigitalOcean App Platform variables, Heroku config vars, Netlify site variables, Bunnyshell environment or project variables, GitHub Actions secrets, or Google Secret Manager secrets. Admins only. Each destination has its own guide under Third-party sync.

A connection is a destination account; a binding is one environment syncing to one place in it.

seekrit sync enable takes the environment (--env, plus --app), the connection (--connection), and the destination:

Enabling wraps the environment's data key — and the key of every group it composes — to the connection, on your machine. You need a key for all of them, so run it as someone who can already read the environment.

printf '%s' "$VERCEL_TOKEN" | seekrit sync connect --name acme-vercel --team-id team_…
seekrit sync enable --connection acme-vercel --app storefront --env production \
  --project prj_… --target production --acknowledge-decryption
seekrit sync run syb_…

# Cloudflare: one scoped token per product, plus the account id
printf '%s' "$CLOUDFLARE_API_TOKEN" | seekrit sync connect --name acme-cf \
  --provider cloudflare-workers --account-id 0123456789abcdef0123456789abcdef
seekrit sync enable --connection acme-cf --provider cloudflare-workers \
  --script my-api --app storefront --env production --acknowledge-decryption

# Railway: three UUIDs address a variable, and the token kind picks the header
printf '%s' "$RAILWAY_TOKEN" | seekrit sync connect --name acme-railway \
  --provider railway --token-kind project
seekrit sync enable --connection acme-railway --provider railway \
  --railway-project 11111111-1111-4111-8111-111111111111 \
  --railway-environment 22222222-2222-4222-8222-222222222222 \
  --service 33333333-3333-4333-8333-333333333333 \
  --app storefront --env production --acknowledge-decryption

# AWS: the region and key id are config, the secret access key is the credential
printf '%s' "$AWS_SECRET_ACCESS_KEY" | seekrit sync connect --name acme-aws \
  --provider aws-secrets-manager --region us-east-1 --access-key-id AKIA…
seekrit sync enable --connection acme-aws --provider aws-secrets-manager \
  --path prod/storefront/ --app storefront --env production --acknowledge-decryption

# Render: one key for the whole workspace, then a service or an env group
printf '%s' "$RENDER_API_KEY" | seekrit sync connect --name acme-render --provider render
seekrit sync enable --connection acme-render --provider render \
  --service srv-abc123 --app storefront --env production --acknowledge-decryption
seekrit sync enable --connection acme-render --provider render \
  --env-group evg-xyz789 --app storefront --env staging --acknowledge-decryption

# Fly.io: the app name is the whole destination; nothing to set on the connection
printf '%s' "$(fly tokens create deploy -a storefront-production)" \
  | seekrit sync connect --name acme-fly --provider fly
seekrit sync enable --connection acme-fly --provider fly \
  --fly-app storefront-production \
  --app storefront --env production --acknowledge-decryption

# Northflank: one secret group, named by slug — the token carries its own team
printf '%s' "$NORTHFLANK_API_TOKEN" | seekrit sync connect --name acme-northflank \
  --provider northflank
seekrit sync enable --connection acme-northflank --provider northflank \
  --project default-project --secret-group app-secrets \
  --app storefront --env production --acknowledge-decryption

# DigitalOcean App Platform: app-level variables, written encrypted.
# Each push submits a new app spec, which starts a deployment.
printf '%s' "$DIGITALOCEAN_TOKEN" | seekrit sync connect --name acme-digitalocean \
  --provider digitalocean
seekrit sync enable --connection acme-digitalocean --provider digitalocean \
  --do-app 4f6c71e2-1e90-4762-9fee-6cc4a0a9f2cf \
  --app storefront --env production --acknowledge-decryption

# Heroku: config vars on one app — each push restarts its dynos
printf '%s' "$(heroku authorizations:create --short)" \
  | seekrit sync connect --name acme-heroku --provider heroku
seekrit sync enable --connection acme-heroku --provider heroku \
  --heroku-app storefront-production \
  --app storefront --env production --acknowledge-decryption

# Netlify: one site's variables, per deploy context — the team is on the connection
printf '%s' "$NETLIFY_AUTH_TOKEN" \
  | seekrit sync connect --name acme-netlify --provider netlify --account-id acme
seekrit sync enable --connection acme-netlify --provider netlify \
  --netlify-site 3970e0fe-8564-4903-9a55-c5f8de49fb8b \
  --target production,deploy-preview \
  --app storefront --env production --acknowledge-decryption

# Bunnyshell: one environment's variables — the connection carries no scope
printf '%s' "$BUNNYSHELL_TOKEN" \
  | seekrit sync connect --name acme-bunnyshell --provider bunnyshell
seekrit sync enable --connection acme-bunnyshell --provider bunnyshell \
  --bunnyshell-environment env-9f3a2b \
  --app storefront --env production --acknowledge-decryption

# Bunnyshell: the project instead, to seed ephemeral environments that don't exist yet
seekrit sync enable --connection acme-bunnyshell --provider bunnyshell \
  --project prj-4c8d1e \
  --app storefront --env preview --acknowledge-decryption

# GitHub Actions: prefer seekritdev/github-action, which decrypts in the run.
# Sync only for what an Action cannot reach — `with:` inputs of third-party
# actions, `secrets: inherit`, job-level container/services credentials.
printf '%s' "$GITHUB_TOKEN" \
  | seekrit sync connect --name acme-github --provider github-actions
# ...to one deployment environment's secrets, the narrowest scope GitHub has
seekrit sync enable --connection acme-github --provider github-actions \
  --gh-repo acme/storefront --gh-environment production \
  --app storefront --env production --acknowledge-decryption
# Google Secret Manager: the credential is the whole key file, so pipe it in
seekrit sync connect --name acme-gcp --provider gcp-secret-manager \
  --project-id acme-prod < key.json
seekrit sync enable --connection acme-gcp --provider gcp-secret-manager \
  --gcp-prefix prod-storefront- --gcp-prune-versions \
  --app storefront --env production --acknowledge-decryption

Billing