DeployLog Changelog

Each API key now holds its own set of capabilities, so the key in your CI can do less than the key on your laptop. Pick them when you create a key: open the dashboard, then API Keys.

• read lists projects and entries. Every key holds it.
• write creates and edits projects and entries.
• publish publishes an entry, including one you publish as you create it.
• delete deletes an entry, or unpublishes one.

Four presets sit above the checkboxes: Full access (all four), CI / automation (read, write and publish), Read only, and Custom. Every key that existed before this change was given publish and delete as well, so nothing you already run breaks.

A call the key is not scoped for gets a 403 that names what is missing, such as API key lacks publish permission. deploylog push --publish needs both write and publish. Run deploylog whoami to see what the current key holds.

The API keys section of chapter 11 of the DeployLog manual describes every preset and capability.

You can now publish a product manual next to your changelog, drafted from your code. A manual is your product's set of numbered chapters, and a chapter is one page of that manual whose factual sentences are anchored to your code. You write the brief; DeployLog writes the prose and records, for every sentence that states a value, exactly where that value lives in your repository. Each recorded link is a claim: one sentence in the chapter, one exact value in one exact file.

The loop:

1. Create a chapter. It gets a number and a title.
2. Generate. A generation is one run that turns your brief and a list of source files into the chapter's prose and its claims.
3. Read the claims before you read the prose.
4. Cold read the chapter front to back, the way a stranger to the code would.
5. Approve. Approval opens a pull request against your repository.
6. Merge, then publish the chapter from its page.
7. Cut a version when the set is ready. A version pins each cited repository to a commit.

The public manual lives at /p/<slug>/manual and lists published chapters only, in your order. Until one chapter is published, that address is not found.

The free allowance is five manual generations a month.

On a pull request, the GitHub Action in mode: verify annotates drift on the changed lines, and fail-on decides which findings fail the check. From your terminal, deploylog manual verify runs the same check and answers with its exit code.

Your repository stays canonical. Nothing lands in git until the pull request an approval opens is merged.

The whole loop is in chapter 10 of the DeployLog manual.

Two new commands put your manual in the CLI. deploylog manual export shipped in 0.5.0 on npm on 2026-08-24, and deploylog manual verify in 0.6.0 on 2026-08-25. Install or update with npm i -g deploylog.

manual export writes out the project's versioned prose, its commit map (the commit each cited repository was pinned at when the version was cut), and the claims each chapter pins to code.

• Flags: -p, --project <slug>, -o, --out <path>, --json.
• The default output file is ./<slug>-manual.json, and - streams the payload to stdout.
• The payload is validated against the server's published schema before anything is written.
• The export is available on every plan.

manual verify runs the check on DeployLog's side, the same check the GitHub Action runs on a pull request. The exit code is the answer.

• 1 means a cited value moved.
• 2 means the run could not vouch for the manual, and you asked for that with --fail-on any.
• 0 otherwise.
• --fail-on accepts none, drift and any, and defaults to drift. Anything else is refused before a request is sent, with INVALID_FAIL_ON under --json, and exit 1.
• --changed-from <base> scopes the run to what changed since that base. Without it, the whole manual is checked.

Two guards stop a false clean. When nothing changed since the base, the CLI says so on stderr and verifies the whole manual instead. And when no claim in the manual cites the repository you sent, the CLI prints verified nothing at <ref>: no claim cites <repository> on stderr, whatever --fail-on is set to.

# In a pre-push hook: block the push on drift
deploylog manual verify || exit 1

Both new commands take --json. Without it, manual verify prints a human report.

Both commands are covered in chapter 05 of the DeployLog manual.

The CLI now manages an entry after you push it: view, edit, publish, unpublish and delete it. Update with npm install -g deploylog@latest.

New commands

• view: a full entry, including its markdown body.
• edit: change an entry via flags, a body file, or your $EDITOR.
• publish / unpublish: move an entry between draft and published. Publishing sends the email digest on Pro, once per entry.
• delete: remove an entry permanently.
• init: scaffold a .deploylog.yml so a repo remembers its project and default type.
• projects create: create a project without leaving the terminal.
• import github: pull your existing GitHub releases in as entries.
• open: jump to your public changelog, or one entry's page, in the browser.
• whoami: show the authenticated org, plan, and API key.

list gains filters for drafts, published entries, and type.

Built for scripts and agents Every command takes --json: machine-readable output, a predictable error shape, and no prompts. The CLI is safe to drive from CI or an AI agent.

Entries are addressed by slug or id, and delete asks for confirmation before it does anything (pass --yes when scripted).

Every command and flag is listed in chapter 05 of the DeployLog manual.