anodizer

io.github.tj-smith47Published by GitHub account tj-smith47v0.30.0Updated Oct 24, 2026

Rust release tooling — drop-in GoReleaser parity + Rust extras.

VerifiedSTDIODesktop onlyCloud & InfrastructureDeveloper Tools

Overview

AI-generated overview

Anodizer's built-in MCP server exposes its Rust release CLI as tools, letting an assistant validate config, bump versions, tag, build, publish and announce a C

What you can do
Inspect and validate: check config and version files, run healthcheck, preflight, JSON schema, tag resolution, target and vocabulary lookups, list tools. Author releases: generate a starter config, refresh changelogs, bump crate versions, create or roll back tags. Ship releases: build, run the full release pipeline, publish, promote to a stable track, continue a stalled release, announce and notify. Long-running commands return task handles that can be polled, streamed and cancelled.
When to use it
Useful when a Rust project's release work should be driven from an AI assistant: validating a config, previewing a version bump or tag, or running build and publish stages. The inspect group alone gives a read-only assistant for checking a release setup.
Requirements
Runs as a local process on the user's machine (stdio, or streamable HTTP via the stream command); desktop only. The anodizer CLI must be installed (Homebrew, cargo, or from source). Release and publish stages need a GitHub token in GITHUB_TOKEN or ANODIZER_GITHUB_TOKEN, plus credentials for whichever publishers and signing tools are configured.
Before you install
Publishing, announcing and promoting act on external services and can spend or expose credentials; preflight checks publisher credentials and state. Bump is non-idempotent and moves versions twice if run twice. Tag rollback is marked destructive: it unwinds publishers, deletes tags and rewrites history. Release failures roll back by default, deleting the tag and reverting the bump.

Installation

In SourceWeft

  1. Open anodizer in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

[anodizer logo]

anodizer

The release pipeline built for Rust — workspace-aware, reproducible, and signed by default.

[CI] [Release] [Docs] [Coverage] [Crates.io] [License: MIT OR Apache-2.0]

Anodizer reads a declarative config file and runs your entire release from a single anodizer release command: build, archive, checksum, changelog, sign, release, publish, and announce. It's built around the Rust ecosystem — Cargo workspaces, Cargo.lock-aware version bumps, crates.io, and byte-reproducible artifacts.

See What works (with proof) for a per-feature status — every "live" claim links to a real published artifact you can verify yourself.

Why anodizer?

Your release is a Cargo workspace — not a bag of loose binaries. anodizer is built that way from the ground up.

  • It speaks Cargo. Per-crate release cadences, per-crate tags, and a tag resolver let a single crate and a thirty-crate monorepo share one config. anodizer tag and anodizer bump rewrite Cargo.toml and Cargo.lock, then commit and tag — locally by default, and (on --push) push the bump commit and tag atomically — no orphaned bump commit, no hand-rolled git push, no lockfile drift.
  • crates.io, published in the right order. Dependency-aware ordering with sparse-index polling holds each crate until the ones it depends on have propagated — so a workspace publish never races itself into a transient "version not found."
  • Cross-compiles without the toolchain tax. musl, glibc, Windows, and macOS from one machine via cargo-zigbuild or cross. No rustup target add rituals, no per-target CI shards to babysit.
  • Reproducible — and it proves it. Deterministic artifacts by default, then anodizer check determinism rebuilds them and byte-compares. "Reproducible" becomes a fact your CI enforces, not a claim in your release notes.
  • Signing and attestation are first-class. cosign + GPG for binaries, archives, checksums, and images, plus SLSA-style build provenance — wired in a few lines of config.

Then the long tail that Rust authors actually hit: generated per-crate READMEs, cargo-binstall metadata derived straight from your config (no hand-maintained pkg-url that 404s), version_files to pin your docs and install scripts to the released version, and post-release install smoke tests that catch a broken artifact before your users do.

Already know GoReleaser? anodizer's {{ .Field }} template syntax will feel right at home. Moving from cargo-dist, release-plz, or cargo-release? The migration guides map your setup straight over.

Features

Build

  • Cross-platform builds via cargo-zigbuild, cross, or native cargo build
  • Per-build hooks (pre/post), environment variables, feature flags, and target overrides
  • UPX binary compression with per-target filtering
  • Workspace support with per-crate independent release cadences

Package

  • Archives in tar.gz, tar.xz, tar.zst, zip, gz, or raw binary format with OS-specific overrides
  • Linux packages (.deb, .rpm, .apk, .archlinux, .ipk) via nFPM with full lifecycle scripts
  • Snapcraft snaps with prime-dir architecture
  • macOS DMG disk images and PKG installers
  • Windows MSI and NSIS installers
  • Flatpak bundles
  • AppImage portable Linux applications
  • Makeself self-extracting archives
  • curl | sh install-script generation — a per-platform asset table derived from your build/archive config (no hand-maintained URLs to 404), with a checksum-verify gate
  • Source RPMs (.src.rpm)
  • Source archives with file filtering
  • SBOM generation (CycloneDX/SPDX)
  • Checksums with SHA-256, SHA-512, SHA3, BLAKE2b, BLAKE2s, BLAKE3, CRC32, MD5, and more — combined or split per-artifact sidecars in bare or coreutils (shasum -c) format

Sign

  • GPG and cosign signing for binaries, archives, checksums, Docker images, and SBOMs
  • Signed git tags (GPG or SSH) using your existing git signing key
  • Multiple independent signing configurations
  • Conditional signing via template expressions
  • Build provenance attestations (SLSA-style) for binaries and artifacts

Publish

  • GitHub/GitLab/Gitea Releases with asset uploads, draft/prerelease detection, header/footer templates; the repository owner and name default to the origin remote
  • crates.io with dependency-aware ordering and index polling
  • Homebrew formula and cask generation
  • Homebrew-core formula bump PRs (bump an existing homebrew-core formula)
  • Scoop manifest generation
  • Chocolatey package generation
  • Winget manifest generation
  • AUR PKGBUILD and .SRCINFO generation
  • Krew plugin manifest generation
  • Nix derivation generation
  • SchemaStore catalog registration for editor autocomplete of your config files
  • MCP registry server-manifest publishing (Model Context Protocol)
  • Docker multi-arch images via docker buildx
  • Blob storage uploads (S3, GCS, Azure)
  • NPM per-platform binary packages and PyPI native binary wheels
  • Keyless OIDC Trusted Publishing for crates.io, npm (with provenance), and PyPI — no stored registry tokens
  • Artifactory, Cloudsmith, Fury, Docker Hub
  • Custom publisher commands

Announce

  • Discord, Slack, Telegram, Teams, Mattermost
  • Email, Reddit, Twitter/X, Mastodon, Bluesky, LinkedIn
  • OpenCollective, Discourse
  • Generic webhooks with custom headers and templates

Advanced

  • Tera templates (Jinja2-like) with GoReleaser-compatible {{ .Field }} syntax
  • Nightly builds with date-based versioning
  • Config includes for shared configuration
  • Split/merge CI for fan-out parallel builds
  • Monorepo support with independent workspaces
  • Auto-tagging from commit message directives
  • Reproducible builds with mod_timestamp and builds_info
  • Version-string file syncing (version_files) to keep docs, scripts, and manifests in lockstep at tag
  • Cross-publisher track promotion (anodizer promote) — flip an already-published artifact to a stable track (snapcraft channels, npm dist-tags, OCI floating tags, GitHub prerelease) with no rebuild
  • Post-release verification with install smoke tests
  • GitHub Actions job summary listing every release, pull request, package and image the run published
  • JSON Schema for editor autocomplete and validation
  • Built-in MCP server (anodizer mcp) exposing the CLI as annotated tools for AI assistants

Installation

Homebrew (macOS/Linux)

bash
brew install tj-smith47/tap/anodizer

Cargo

bash
cargo install anodizer

From source

bash
git clone https://github.com/tj-smith47/anodizer.gitcd anodizercargo install --path crates/cli

Quick Start

bash
# Generate a starter config from your Cargo workspaceanodizer init > .anodizer.yaml
# Validate your configanodizer check
# Check that required tools are availableanodizer healthcheck
# Build a snapshot (no publishing)anodizer release --snapshot
# Dry run (full pipeline, no side effects)anodizer release --dry-run
# Bump crate versions from Conventional Commits — rewrites Cargo.toml + Cargo.lock,# no tag (tag separately, or let the release workflow tag for you)anodizer bump --dry-run --output json         # preview the per-crate plan as JSONanodizer bump                                 # infer patch/minor/major per crate since its last taganodizer bump minor --package mycrate         # force a level for one crateanodizer bump --workspace --commit --changelog  # bump every member, commit, refresh CHANGELOG.mdanodizer bump --pre rc.1                       # append a prerelease identifier (0.5.0-rc.1)
# Auto-tag from commit directives# (Conventional Commits: feat: → minor, fix: → patch, BREAKING CHANGE: → major)anodizer tag --dry-run                         # preview what tag would be createdanodizer tag --push --changelog                # tag + refresh changelog + push (triggers the release)anodizer tag --sign --push                     # signed annotated tag (uses git user.signingkey)anodizer tag --custom-tag v0.1.0               # force a tag value, bypassing bump derivationanodizer tag --version 1.2.3 --crate mycrate   # pin an exact version for recovery (per-crate mode)anodizer tag rollback "$GITHUB_SHA"            # delete anodizer-managed tags at a SHA + revert the bump
# Resume a stalled release from a populated dist/ — no rebuildanodizer continue                              # resume the publish-only pipeline after a transient failureanodizer continue --merge                      # fan-in split-build workers, then sign/checksum/release/publishanodizer continue --skip npm,announce          # resume but skip named stages/publishers
# Run only the publish stages (release / blob / publish) from a completed dist/anodizer publish --publishers homebrew,scoop   # publish to a subset of configured publishersanodizer publish --dry-run                     # preview the publish chain with no side effects
# Promote an already-published artifact to a stable track — no rebuildanodizer promote --to stable                                  # promote the newest prerelease artifactanodizer promote --to stable --from candidate --dry-run       # preview promoting from a named source trackanodizer promote --to stable --version v1.2.0 \  --publishers snapcraft,npm                                  # promote a pinned version on chosen publishers

For CI-based releases, set GITHUB_TOKEN (or ANODIZER_GITHUB_TOKEN) as a secret — the release pipeline picks it up automatically.

Configuration

Anodizer uses .anodizer.yaml (or .anodizer.toml) in your project root. Add a schema comment for editor autocomplete:

yaml
# yaml-language-server: $schema=https://tj-smith47.github.io/anodizer/schema.json
project_name: myapp
defaults:  targets:    - x86_64-unknown-linux-gnu    - aarch64-unknown-linux-gnu    - x86_64-apple-darwin    - aarch64-apple-darwin    - x86_64-pc-windows-msvc  cross: auto
crates:  - name: myapp    path: "."    tag_template: "v{{ Version }}"    builds:      - binary: myapp    archives:      - name_template: "{{ ProjectName }}-{{ Version }}-{{ Os }}-{{ Arch }}"        files: [LICENSE, README.md]    release:      github:        owner: myorg    # optional: read from the origin remote when omitted        name: myapp    publish:      cargo: {}      homebrew_cask:        repository:          owner: myorg          name: homebrew-tap        binaries: [myapp]

See the full configuration reference and the template reference for all available fields, variables, and filters.

Real-world adoption: cfgd

cfgd — declarative, GitOps-style machine configuration management — is anodizer's first real-world adopter and dogfoods every shipped publisher. It's a 4-crate workspace (shared lib + CLI + Kubernetes operator + CSI driver) that ships to crates.io (dependency-aware ordering), GitHub Releases, Homebrew, Scoop, Chocolatey, Winget, the Snap Store, Krew, GHCR, and via cargo binstall — all from one .anodizer.yaml and one tag push.

A condensed slice of cfgd's .anodizer.yaml:

yaml
workspaces:  - name: cfgd-core    crates:      - name: cfgd-core        tag_template: "core-v{{ Version }}"        version_sync: { enabled: true, mode: cargo }
  - name: cfgd    crates:      - name: cfgd        depends_on: [cfgd-core]        version_sync: { enabled: true, mode: cargo }        universal_binaries:          - name_template: "{{ ProjectName }}"            replace: false        binstall:          enabled: true   # pkg-url + per-target overrides derived from archive.name_template  # ... cfgd-operator, cfgd-csi

Every cell of What works (with proof) links to a real published cfgd artifact for the feature in question — that's where the verification lives.

GitHub Actions

Anodizer ships a first-party action, tj-smith47/anodizer-action, which is what this repo dogfoods in its own release.yml:

yaml
# not an anodizer configname: Release
on:  push:    tags: ["v*"]
permissions:  contents: write
jobs:  release:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v6        with:          fetch-depth: 0
      - uses: dtolnay/rust-toolchain@stable
      - name: Release        uses: tj-smith47/anodizer-action@v1        with:          version: latest        # accepts `latest`, `nightly`, or an exact tag (e.g. `v0.5.0`). Pin in production.          auto-install: true     # auto-detect nfpm/makeself/snapcraft/cosign/etc from .anodizer.yaml          args: release --clean        env:          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

For split/merge fan-out, GPG key import, registry login, and per-platform variants, see anodizer-action and the live .github/workflows/release.yml in this repo.

MCP server

anodizer mcp serves the CLI to any MCP client — Claude Desktop, VS Code, Cursor, Zed — over stdio or streamable HTTP, built on brontes. Every subcommand becomes a tool with its flags as a JSON Schema, so a release can be driven by an assistant without wrapping anything by hand.

bash
$ anodizer mcp claude enable      # register with Claude Desktop (also: vscode, cursor, zed)$ anodizer mcp start              # stdio, for a client that spawns the process$ anodizer mcp stream --port 8080 # streamable HTTP, for a shared/remote client$ anodizer mcp tools              # dump the tool list to mcp-tools.json for inspection

23 tools ship by default (completion and man are shell-prompt artifacts and are withheld). Three groups narrow that for a client that shouldn't see every tool:

SelectionToolsCovers
(default)23the full tree
--group inspect9check config, check version-files, healthcheck, preflight, jsonschema, resolve-tag, targets, vocabulary, tools
--group author5init, changelog, bump, tag, tag rollback
--group ship7build, release, publish, promote, continue, announce, notify

The same --group / --command / --tool flags work on mcp start and mcp stream, and the editor installers forward them — anodizer mcp claude enable --group inspect registers a read-only assistant. Each has a --hide- counterpart for subtracting from the full list instead of selecting into it.

Each tool carries annotations a client can gate on, so a config validation and a publish are distinguishable before either runs:

AnnotationCommands
readOnlyHintthe inspect group — preflight alone sets openWorldHint
idempotent local writebuild, changelog, check determinism, init, tag
idempotent + openWorldHintannounce, continue, notify, promote, publish, release
non-idempotentbump — bumping twice moves the version twice
destructiveHinttag rollback — unwinds publishers, deletes tags, rewrites history

The six commands that routinely run for minutes — build, check determinism, continue, promote, publish, release — are handed back as task handles rather than held-open requests, so a client that speaks the MCP tasks extension can poll, stream progress, and cancel a running release.

CLI Reference

anodizer release       Full release pipeline (--snapshot, --dry-run, --split/--merge, --publish-only)anodizer tag           Auto-tag from commit directivesanodizer tag rollback  Delete anodizer-managed tags at a SHA and revert the bump commitanodizer bump          Bump crate versions (Conventional Commits → semver level) without tagginganodizer promote       Promote a published artifact to a stable track without rebuildinganodizer continue      Resume a stalled or split release from a populated dist/ (--merge to fan-in)anodizer publish       Run only the publish stages (release, blob, publish) from a completed dist/anodizer check         Validate configuration + run determinism harnessanodizer preflight     Run the release preflight without releasing (tools, secrets, publisher credentials and state)anodizer init          Generate starter .anodizer.yamlanodizer healthcheck   Probe external tools (nfpm, cosign, ...)

Failure handling is in-process: a failed anodizer release executes the release.on_failure policy itself (rollback by default — delete the tag, revert the bump — auto-degrading to hold once a one-way-door publisher like crates.io has published), so release workflows need no if: failure() recovery steps. anodizer tag rollback "$GITHUB_SHA" is the manual recovery command for killed or held runs. See Release resilience for the flag matrix and recovery flows.

Full reference: anodizer --help or the docs site.

Documentation

Full documentation is available at tj-smith47.github.io/anodizer.

Operator guides:

License

Licensed under either of

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Source: README.md at commit 6cb440a

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

3
  1. v0.30.0LatestOct 15, 2026
  2. v0.29.0Oct 11, 2026
  3. v0.28.1Sep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts