
anodizer
io.github.tj-smith47Published by GitHub account tj-smith47v0.30.0Updated Oct 24, 2026
Rust release tooling — drop-in GoReleaser parity + Rust extras.
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.
Installation
In SourceWeft
- Open anodizer in the dashboard and add it to a workspace.
- 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
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 tagandanodizer bumprewriteCargo.tomlandCargo.lock, then commit and tag — locally by default, and (on--push) push the bump commit and tag atomically — no orphaned bump commit, no hand-rolledgit 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-zigbuildorcross. Norustup target addrituals, no per-target CI shards to babysit. - Reproducible — and it proves it. Deterministic artifacts by default, then
anodizer check determinismrebuilds 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 nativecargo 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 | shinstall-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
originremote - crates.io with dependency-aware ordering and index polling
- Homebrew formula and cask generation
- Homebrew-core formula bump PRs (bump an existing
homebrew-coreformula) - 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_timestampandbuilds_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)
Cargo
From source
Quick Start
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:
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:
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:
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.
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:
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:
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
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:
- Release resilience guide - three-group publisher dispatch, Submitter gate, rollback, replay-from-run
- Determinism guide - byte-stability contract,
anodizer check determinismharness, runtime allow-list
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)
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
0Version history
3- v0.30.0LatestOct 15, 2026
- v0.29.0Oct 11, 2026
- 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