DeployLog Changelog

The first entry on this changelog is CLI 0.3.0, published 2026-06-21. DeployLog is older than that. Here is what shipped before it, in order.

April 2026

• 2026-04-10: the first CLI release, deploylog 0.1.0, on npm.
• 2026-04-16: the GitHub Action, deploylogdev/action v1.0.0. Publish a GitHub Release and it creates an entry from the release notes, can rewrite them with Claude Haiku, and either publishes the entry or saves it as a draft.
• By 2026-04-20, the rest of the core: the dashboard's Markdown editor with a preview and AI drafting, the hosted public changelog with RSS and JSON feeds, a page and a share image for every entry, email subscribers and digests, the embeddable widget, view analytics, API keys, and the Pro plan.
• By 2026-04-20, CLI 0.2.1 covered login, projects, list and push. push --from-git turns the commits since your last tag into a draft entry, and --ai-summarize rewrites it with AI.

June 2026

• 2026-06-16: import your existing GitHub Releases as entries from the dashboard, and start a new entry from a template.
• 2026-06-16: Action v1.1.0 adds skip-prerelease. Set it to true and a prerelease such as v2.0.0-rc.1 is skipped instead of published.

To start where DeployLog started, install the CLI with npm i -g deploylog and run deploylog push --from-git in a repository that has a tag. Chapter 01 of the DeployLog manual walks through the rest.

Your public changelog's Subscribe button now fits inside its card on phones. Clicking the back link on an entry page no longer shows a Skip to main content link in the corner; keyboard users still reach it first with Tab. Open your changelog on a phone to see it, or read chapter 03 of the DeployLog manual.

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.

deploylog manual verify now fails a run that could not read a single claim. Update with npm i -g deploylog; 0.7.0 reached npm on 2026-09-26.

Changed

• A run that reads claims and cannot read any of them exits 2 at every --fail-on except none. Before 0.7.0 it exited 0 under the default, drift.
• This affects anyone who runs manual verify in CI or a git hook at the default, from 0.7.0 on. If a run that used to pass now exits 2, read the reasons it prints, or pass --fail-on none to report without failing.
• The summary line prints vouched N: the claims the run read and stood behind. One unreadable claim among readable ones still exits 0 under drift; pass --fail-on any to fail on it.

Fixed

• Claims that cite a second repository can now be read. Generating a chapter records the commit of the repository it read. Until a server fix on 2026-09-18, only the repository a run was in had a commit on record, so every claim citing another repository was unreadable. Regenerate a chapter that cites another repository to record its commit.
• deploylog --version prints the installed version. 0.6.0 printed 0.5.0.
• A key in .deploylog.yml that the CLI does not know is reported on stderr, with the closest real key when there is one, such as default_type. The file still loads.

Every exit code is listed in the manual verify section of the CLI README.

On Pro, you can now set an accent color for your public changelog: open your project's settings, then Changelog Appearance. DeployLog refuses a color too close to its own brand red, and falls back to its default indigo where your color would be hard to read. Chapter 03 of the DeployLog manual shows where the accent appears.

Improved

• Pro now includes 20 manual generations a month, where a generation is one run that writes a chapter of your manual. Free stays at five a month.

Fixed

• A manual generation that crashed partway no longer holds one of your monthly slots forever.
• Re-approving an unchanged chapter that is already merged no longer opens an empty pull request.
• An approved chapter's status now shows whether its pull request has merged.
• One invalid subscriber address no longer stops the digest for everyone else.
• A chapter page shows its title once, and its description in search results and link previews starts at the prose, not the title.
• An account created with email now gets its organization, so the dashboard can save from the first sign-in.
• Signing up with an email that already has an account tells you to sign in, instead of promising a confirmation email that never comes.
• Signing in with GitHub lets you pick which GitHub account to use.
• The site header wraps on phones, and the footer links stay clear of the widget's floating button at every width.

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 changelog widget now works in setups where it used to break:

• A snippet placed in <head> used to fail to mount. It now waits for the page body.
• Loading the snippet twice mounts one widget, not two.
• Safari 13 runs it, and auto theme follows system light and dark changes reliably.
• All text coming from the API (entry types, versions, project names) is escaped before rendering.
• Accent colors are validated before they touch your page.

The snippet loads the widget from DeployLog's CDN, so every existing embed picks up these fixes with no change. To add the widget to a new site, copy the snippet from your project's settings, then Widget Embed. Every option is in chapter 04 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.

The DeployLog dashboard has a cleaner, more consistent look, and public changelog pages now follow your reader's light or dark setting, so entries stay readable in either.

Also new:

• The Free plan holds three projects, up from one.
• A draft's slug now updates when you change its title, until you set your own. Once an entry is published its slug stays fixed, because it is the entry's public address.
• When AI drafts an entry, it now sees the titles, types and versions of your recent published entries.
• Signing out of the dashboard ends your session on every device.

Open your public changelog with your system set to dark mode to see the new theme. Chapter 03 of the DeployLog manual covers the public page in full.

The DeployLog CLI now takes less typing. Update with npm install -g deploylog@latest.

New

• dpl is a shorter alias for the deploylog command.
• New short and long flags for push: -g/--git (--from-git), -a/--ai (--ai-summarize), -T (--type), -P (--publish), and -D (--draft).

Every existing command and flag still works, so nothing you've scripted breaks.

For example, deploylog push --from-git --ai-summarize is now just dpl push -g -a.

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