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):
get_secrets_public_key → the cluster's public key + fingerprint.- Source a token interactively —
gh auth token, a pasted fine-grained PAT (Contents: Read-only), or npm token create for a private registry.
encryptEnvelope(...) → seal it locally into an enc:v1: envelope (pure client-side crypto; the plaintext never leaves the machine).set_secret { envelope, grants:[component] } → store only ciphertext; the cluster decrypts it in-memory only at deploy/rollback time.- 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 — 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
Prototype PRs: #1850 (deploy by_ref) · #1851 (deploy setup) · HarperFast/harper-pro#594 (add_ssh_key generate) · HarperFast/create-harper#118 (create-harper scaffold)
Tracking issues: #1777 · #1778 · HarperFast/harper-pro#570 · HarperFast/create-harper#117 · #641 (rollback)
Problem
create-harpershippedscripts/setup-deploy.mjsto 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=trueA guided, client-side credential-provisioning flow (what
harper loginis for auth, but for deploy tokens):get_secrets_public_key→ the cluster's public key + fingerprint.gh auth token, a pasted fine-grained PAT (Contents: Read-only), ornpm token createfor a private registry.encryptEnvelope(...)→ seal it locally into anenc:v1:envelope (pure client-side crypto; the plaintext never leaves the machine).set_secret { envelope, grants:[component] }→ store only ciphertext; the cluster decrypts it in-memory only at deploy/rollback time.credentialsreference 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—bin/deploySetup.ts+ aharper deploy setup=trueintercept inbin/harper.ts. Parse + oxlint + prettier clean. Builds directly on thecredentialsarray (#1797), the git-host credential (#1799), and thehdb_secretclient-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
Prototype PRs: #1850 (deploy by_ref) · #1851 (deploy setup) · HarperFast/harper-pro#594 (add_ssh_key generate) · HarperFast/create-harper#118 (create-harper scaffold)
Tracking issues: #1777 · #1778 · HarperFast/harper-pro#570 · HarperFast/create-harper#117 · #641 (rollback)