Command reference

Manage your dew identity: inspect it ('dew key status') or provision it onto another machine ('dew key push').

Show ~/.dew/devices.yaml — a local log of 'dew key push'/'pull' transfers (peer, direction, public-key fingerprint, when, optional label).

This is a best-effort audit log, NOT a registry or revocation tool: manual key copies aren't recorded, and there's no key rotation — so a machine listed here can't be de-provisioned by removing it. Use it to recall where you've distributed your identity.

Copy the dew identity FROM <user@host> onto this machine, so it can decrypt your images — the bootstrap when a new machine reaches back to one that already has the identity. It verifies the source's host key the normal way (an unknown host aborts), downloads to a temp file and checks it matches the source's public key before installing it 0600 under ~/.dew, and won't replace a different local identity without --force.

The mirror of 'dew key push'. 'dew sync' still never moves the key; this is an explicit, opt-in transfer you initiate.

Copy this machine's dew identity to <user@host> so it can decrypt your images — the one-time bootstrap for a second machine. It uses your existing SSH access (the host key is verified the normal way; an unknown host aborts), writes the key 0600 under ~/.dew there, and won't overwrite a different identity without --force.

This is the one command that moves your private key — and only when you run it, to a machine you control. 'dew sync' still never transmits the key. Prefer this over copying the key by hand, and don't run 'dew keygen' on the new machine.

Report whether this machine has a dew identity and print its public key. Use it to confirm a machine is set up before you restore.

Generate the one age keypair dew uses to encrypt and decrypt your images, stored in ~/.dew/. Run this once per machine, before you pack anything.

dew never commits or syncs the private key. To set up another machine, run 'dew key push <user@host>' (an explicit, opt-in copy over your SSH access) — don't run 'dew keygen' there, which would create a different identity that can't decrypt your images. Guard the key like any private key: without it, images can't be decrypted. keygen won't overwrite an existing identity. Next: 'dew init' inside a repo.

Add files to this repo's allow-list — the local context you want dew to manage (.env.local, certs, overrides). Adding is a one-time declaration recorded in the committed manifest; 'dew pack' then always uses the files' current contents, so you never re-add after editing.

Adding a directory includes its files (minus deny-listed noise); a file you add by name is always packed, even if the deny-list matches it — explicit intent wins. Paths outside the repo are rejected. 'dew add .' is special — it adds the candidates 'dew scan' found, prompting Y/n each, not every file in the repo. Next: 'dew pack'.

Tear down what dew keeps for this repo: the committed .dew/ manifest and this repo's encrypted image in ~/.dew/images. It is the inverse of 'dew init' plus 'dew pack' — run it when you're done using dew here, or to start over clean.

This is local-only and never touches your identity key (it's shared by every repo) or any copy you've synced to a remote or another machine. dew has no version history, so removal is permanent — but the image is just a repack of files still on disk, and the manifest is normally committed to Git, so the common case is recoverable. You are asked to confirm unless you pass --force.

Scope it with --image-only (drop the image, keep tracking config so the next 'dew pack' rebuilds it) or --manifest-only (stop managing the repo but keep the image around). To delete an image whose repo is already gone, use 'dew images rm <project>' instead.

Start managing this repo's local context with dew. Creates .dew/manifest.yaml — the list of which local files dew should manage — plus a short .dew/README.md that explains the directory to anyone browsing the repo. The manifest holds no secrets or file contents, only paths, so it's safe to commit; committing it means teammates and other machines know what to hydrate.

The project name defaults to the directory name (override with --project); it becomes the image name. With --from-gitignore, dew seeds the allow-list with candidates discovered from your .gitignore so you can go straight to pack. Next: 'dew add <path>' (or 'dew scan') to choose what to manage, then 'dew pack'.

Show this repo's allow-list — the local files dew manages — and the project name. These are the paths 'dew pack' will include. To see the deny rules by layer as well, use 'dew rules'.

Remove one or more paths from this repo's allow-list so dew no longer manages them. Removing a path that isn't tracked is a harmless no-op. The next 'dew pack' reflects the change; existing images are untouched until you re-pack.

Show the effective rules for this repo: the allow-list (what dew manages) and the three deny layers that keep noise out — built-in patterns, your global ~/.dew/config.yaml, and the repo's .dew/manifest.yaml. Use it to understand why a path is included or skipped.

The built-in layer is deliberately minimal: only noise that's regenerated in essentially every project that has it (node_modules/, Pods/, .gradle/, …). Exclude project-specific generated files — an Expo app's ios/ and android/, say, which are hand-written source in other projects — with a deny: entry in .dew/manifest.yaml. Deny lines are gitignore syntax and support ! to un-deny.

Look through this repo's .gitignore and working tree and suggest local files dew could manage — the per-developer context Git leaves out — while filtering out noise like build output and logs.

scan only suggests; nothing is added until you opt in. Use it to discover what's worth tracking. Next: 'dew add <path>' for specific files, 'dew add .' to take the suggestions, or 'dew init --from-gitignore' to seed them at setup.

Hydrate the working tree from this repo's encrypted image — identical to 'dew restore', with the same --force, --dry-run, and --image flags. dew's signature verb; use whichever name you reach for first.

Bundle the local files dew tracks for this repo — the context Git ignores (.env.local, dev certs, docker-compose.override.yml, local config) — into one encrypted image at ~/.dew/images/<project>.dew.age.

Run it after you add or change a tracked file: pack always uses the current contents of the allow-list, so you declare files once with 'dew add' and never re-add. The image is what 'dew sync' ships and 'dew restore' restores — packing is how your local state becomes portable. Next: 'dew sync' to push it.

The deny-list keeps noise out even from allow-listed directories — though a file you added by name is always packed; explicit intent wins. pack won't overwrite an image created by a different repo unless you pass --force.

--all is the one-shot exception: instead of the allow-list, it packs every LOCAL file — everything Git doesn't carry, ignored and not-yet-committed alike (it asks 'git ls-files', so it needs Git and a git repo). The manifest is untouched, the deny-list still filters generated noise, and .git/ and .dew/ are never included. Use it to carry a repo's complete local half; preview with --dry-run. If --dry-run shows project-specific generated files (e.g. an Expo app's ios/ and android/), exclude them with a deny: entry in .dew/manifest.yaml — see 'dew rules'.

Hydrate the working tree from this repo's encrypted image: decrypt, decompress, and write the tracked files back into place. This is what makes a fresh clone runnable — pair it with 'dew sync pull' on a new machine.

Safe by default: files are staged first, and any local file that differs from the image is reported as a conflict and left untouched, so you won't lose local edits unless you pass --force. --dry-run shows exactly what would change, touching nothing. ('dew hydrate' is the same command.)

By default the image comes from ~/.dew/images; --image restores from an explicit .dew.age file instead — one copied over by hand or pulled from a backup. The same safety rules apply, and no manifest is needed: the image defines what it holds.

Manage the destination dew pushes images to and pulls them from — a local/mounted path (e.g. /Volumes/nas/dew) or an scp-style remote (e.g. nas:/volume1/dew). With no subcommand, 'dew remote' prints the current destination.

The destination is stored in ~/.dew/config.yaml and shared across all repos. Once set, 'dew sync' pushes to it and 'dew sync pull' fetches from it.

Show the dew images present at the configured destination — the mirror of 'dew images', which lists what's on this machine. Useful to confirm a push landed, or to see what a new machine can pull. A local/mounted path is read directly; a remote 'host:path' is listed over ssh.

Record where dew syncs this machine's images — a local/mounted path, or an scp-style 'host:path' remote that uses your existing SSH config. Saved to ~/.dew/config.yaml and shared across all repos; run 'dew sync' afterward to push. Replaces any existing destination.

Verify the configured destination is actually usable before you rely on 'dew sync'. A local/mounted path is checked in place (is the volume mounted? is it writable?). A remote 'host:path' is checked over ssh — reachable, host key trusted, and the path writable — reporting OpenSSH's own verdict (it never prompts, so an untrusted host key fails cleanly). Exits non-zero if unusable.

Remove the configured sync destination from ~/.dew/config.yaml. 'dew sync' then has nowhere to push until you set one again with 'dew remote set'. A no-op if no destination is configured.

Copy this repo's encrypted image to the destination you configured with 'dew remote set' so another machine can fetch it. Local or mounted paths are copied directly; a remote host:path goes over scp using your existing SSH config. Only the encrypted image moves — never your private key.

Run it after 'dew pack' (and 'dew remote test' if you want to check the destination first). On the other machine, 'dew sync pull' fetches it.

Download this repo's encrypted image from the configured destination into ~/.dew/images, so you can restore it. Run this on a fresh clone, then 'dew restore' (or 'dew hydrate'). Your identity must already be on this machine to decrypt.

Check this repo end to end and report the one thing to fix next — a missing identity, no manifest, an unpacked or undecryptable image, or files still waiting to be restored — or confirm the repo is fully hydrated. Unlike 'dew status', it verifies the image actually decrypts, and every problem comes with the exact command to run.

Start here whenever a clone isn't working as expected.

Show a global inventory of the encrypted images in ~/.dew/images — each one's project, size, when it was last packed, and which repo owns it. Where 'dew status' and 'dew list' describe the current repo, images spans every repo and runs from anywhere.

Delete one or more encrypted images from ~/.dew/images, named by project (the PROJECT column 'dew images' prints; the trailing .dew.age is optional). Use it to garbage-collect images whose repo is gone, or any image you no longer want — its .id owner marker is removed alongside it.

This only deletes the local image file; it never touches your identity key or any copy synced elsewhere, and it leaves repo manifests alone (to tear down the current repo's manifest and image together, use 'dew clean'). You are asked to confirm unless you pass --yes. Naming a project with no image is a harmless no-op.

Summarize dew's state for this repo: whether your identity and manifest are present, whether an image exists, how many files are tracked, and whether the working tree is fully hydrated. A quick check after cloning or before packing. For a diagnosis with the exact fix to run, use 'dew doctor'.

Replace this dew binary with a newer release from GitHub: resolve the latest version (or the exact tag you name with --version), download the build for this platform, verify it against the release's checksums, and swap it in atomically. --check only reports what's available and changes nothing.

If dew was installed with Homebrew, upgrade refuses and points you at 'brew upgrade --cask dew' instead — replacing a brew-managed binary corrupts brew's own bookkeeping (--force overrides if you know what you're doing). After an upgrade, 'dew version' confirms what's running.

Print dew's version along with the build commit, date, and Go toolchain — handy when reporting a bug. (See also the --version flag.)