HarperFast / HarperFast/harper
CLI: `harper deploy --setup` — one-command deploy-key provisioning
- Dominant language
- JavaScript
- Stars
- 89
- Forks
- 10
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 200
Description
## Problem
`create-harper` shipped `scripts/setup-deploy.mjs` to bootstrap private-repo deploy access. That belongs in the CLI — and, more importantly, the credential should be **sealed client-side** so the plaintext token never reaches the cluster, its logs, its operations journal, or replication.
## Proposal — `harper deploy setup=true`
A guided, client-side credential-provisioning flow (what `harper login` is for auth, but for deploy tokens):
1. `get_secrets_public_key` → the cluster's public key + fingerprint.
2. Source a token interactively — `gh auth token`, a pasted fine-grained PAT (Contents: Read-only), or `npm token create` for a private registry.
3. `encryptEnvelope(...)` → seal it **locally** into an `enc:v1:` envelope (pure client-side crypto; the plaintext never leaves the machine).
4. `set_secret { envelope, grants:[component] }` → store only ciphertext; the cluster decrypts it in-memory only at deploy/rollback time.
5. Print the `credentials` reference the deploy uses (`[{ host|registry, secret }]`).
Because the token is **durable** (unlike a CI `GITHUB_TOKEN`, revoked at job end), a re-resolve rollback works for as long as it's valid. One flow unifies **git-host** (`{host, …}`) and **npm-registry** (`{registry, …}`) credentials.
## Prototype
Branch [`claude/deploy-setup-sealed-token`](https://github.com/HarperFast/harper/tree/claude/deploy-setup-sealed-token) — `bin/deploySetup.ts` + a `harper deploy setup=true` intercept in `bin/harper.ts`. Parse + oxlint + prettier clean. Builds directly on the `credentials` array (#1797), the git-host credential (#1799), and the `hdb_secret` client-side envelope (#1717 / secretOperations); custody ships on by default (harper-pro#560).
Supersedes the SSH-deploy-key provisioning this issue originally described; the SSH path (harper-pro#570) remains a secondary alternative.
## Related — deploy-by-reference effort
- `HarperFast/harper#1849` — two-phase stage/activate + `revert_component`
- `HarperFast/harper#1850` — `harper deploy by_ref=true` (deploy by git reference)
- `HarperFast/harper#1851` — `harper deploy setup=true` (client-side sealed deploy credential)
- `HarperFast/harper#1876` — CI token auth + `harper login --for-ci`
- `HarperFast/harper-pro#594` — `add_ssh_key generate=true` (cluster-side keygen)
- `HarperFast/create-harper#118` — scaffolds this flow
- `HarperFast/documentation#599` — two-phase deploy docs
- `HarperFast/documentation#616` — by-reference / sealed-credential / CI-auth docs
Contributor guide
Research direction
Start with the prototype files bin/deploySetup.ts and the setup=true intercept in bin/harper.ts, then review the referenced credentials and secretOperations work. Verify the guided flow sources a token, creates an enc:v1 envelope locally, stores the grants, and prints the deploy credentials reference without exposing plaintext; run the parse, oxlint, and prettier checks mentioned in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, typescript
- Domain
- cli, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 38/100