HarperFast / HarperFast/harper

CLI: `harper deploy --setup` — one-command deploy-key provisioning

Open
#1,778 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.