Werk1112’s release tooling produces one router artifact for each configured platform profile. It does not produce a separate archive for every backend. Runtime availability is determined later from compiled Werk features, managed backend installations, host-installed runtimes and configured remote services.
This page follows the current packaging scripts:
scripts/package-release.sh for the
shell packaging surface;scripts/package-release.ps1 for native
Windows packaging;scripts/build-windows.ps1 for the guarded
Windows build;.cargo/config.toml for target aliases;Cargo.toml for the version and release feature bundles.See Building from source for toolchain setup and feature details, and Backend support for runtime provisioning after release installation.
| Platform | Cargo alias | Binary | Release archive |
|---|---|---|---|
| Linux x86_64 | cargo +stable build-linux |
target/x86_64-unknown-linux-gnu/release/werk |
werk1112-v<VERSION>-linux-x86_64.tar.gz |
| Linux x86_64 / AMD Strix Halo | cargo +stable build-linux-strix-halo |
target/x86_64-unknown-linux-gnu/release/werk |
werk1112-v<VERSION>-linux-x86_64-amd-strix-halo.tar.gz |
| Linux aarch64 / DGX Spark | cargo +stable build-linux-aarch64 |
target/aarch64-unknown-linux-gnu/release/werk |
werk1112-v<VERSION>-linux-aarch64-dgx-spark.tar.gz |
| Windows 10/11 x64 | cargo +stable build-windows or scripts/build-windows.ps1 |
target/x86_64-pc-windows-msvc/release/werk.exe |
werk1112-v<VERSION>-windows-x86_64.zip |
| macOS Apple Silicon | cargo +stable build-macos-apple-silicon |
target/aarch64-apple-darwin/release/werk |
werk1112-v<VERSION>-macos-aarch64.tar.gz |
Windows arm64, macOS x86_64 and other target combinations are not currently produced by the checked-in release scripts.
The version embedded in each archive name is read from the [package] version
in Cargo.toml. The scripts write archives under releases/ and a sibling
.sha256 file for each archive.
The current scripts stage exactly these files:
| Archive | Files |
|---|---|
| Linux/macOS tarball | werk, README.md, LICENSE |
| Windows zip | werk.exe, README.md, LICENSE |
The media companion implementation needed by the binary is embedded at build time. The archive does not contain:
nvcc;docs/ tree.The included LICENSE contains the authoritative terms for Werk1112. It does
not relicense third-party dependencies, models, runtimes, or other materials;
those retain their own licenses.
Each packaging command invokes its target build before creating the archive.
After a successful build, it validates CLI/parameter generation using
--profile discovery in a temporary directory, then discards that output without
overwriting the canonical Linux catalogues in docs/reference/. Python 3.9+ is
required; generation errors stop packaging before an existing archive is replaced. Windows packaging invokes
the hook through scripts/build-windows.ps1. Native artifacts are inspected
directly; cross-builds compile a separate backend-neutral host binary for
parser/schema discovery, which does not validate inference on the foreign target.
See automatic reference generation.
The configured Rust target alone does not provide a foreign linker, SDK or accelerator toolchain. Unless a complete cross-compilation environment exists:
gfx1151;Do not use WSL to produce the native Windows archive. WSL can produce the Linux artifact.
From the repository root on a Linux host with the release CUDA toolchain:
./scripts/package-release.sh linux
The shell script:
Cargo.toml;cargo build-linux;target/package/linux as a staging directory;werk, the current root README.md, and the authoritative
LICENSE;sha256sum, or shasum -a 256 when
sha256sum is unavailable.It requires tar and python3 (Python 3.9+) in addition to the build prerequisites.
Run the Strix Halo packaging branch natively on a Ryzen AI Max release host:
./scripts/package-release.sh linux-strix-halo
It invokes cargo build-linux-strix-halo, selects the backend-neutral
release-linux-strix-halo feature, stages the normal three files and writes:
releases/werk1112-v<VERSION>-linux-x86_64-amd-strix-halo.tar.gz
releases/werk1112-v<VERSION>-linux-x86_64-amd-strix-halo.tar.gz.sha256
Before invoking Cargo, the packager requires native Linux x86_64 plus a
specific Ryzen AI Max/Strix Halo signal from CPU or DMI identity, a matching
Radeon 8050S/8060S/8040S identity, or a gfx1151 agent from
rocm_agent_enumerator/rocminfo. A generic x86_64 builder cannot
label its output as Strix Halo merely because the Rust target matches. The
gate verifies host identity, not working ROCm kernels; complete the
hardware smoke gate
before publishing.
Run the aarch64 packaging branch natively on the DGX Spark release builder:
./scripts/package-release.sh linux-aarch64
It invokes cargo build-linux-aarch64, which selects
aarch64-unknown-linux-gnu, the release-linux-aarch64 CUDA bundle and compute
capability 12.1 (sm_121). It then stages the same three files as the x86_64
Linux package and writes:
releases/werk1112-v<VERSION>-linux-aarch64-dgx-spark.tar.gz
releases/werk1112-v<VERSION>-linux-aarch64-dgx-spark.tar.gz.sha256
The checked-in packaging command intentionally requires a native Spark/GB10
build host. Before invoking Cargo, the packager requires Linux aarch64 plus a
DGX Spark/GB10 signal from /proc/device-tree/model or nvidia-smi. It does
not attempt to synthesize an ARM64 sysroot or CUDA cross-toolchain on x86_64.
The resulting archive still requires a separate native smoke test before
release.
From the repository root on Apple Silicon macOS:
./scripts/package-release.sh macos
The flow is the same as Linux but invokes
cargo build-macos-apple-silicon and stages the arm64 binary. It requires
tar and either shasum or sha256sum.
Use the PowerShell packager from native x64 Developer PowerShell:
.\scripts\package-release.ps1 -Target windows
windows is currently the only accepted PowerShell target and is also the
default. The script:
Cargo.toml;scripts/build-windows.ps1;target\x86_64-pc-windows-msvc\release\werk.exe;target\package\windows;werk.exe, README.md, and LICENSE;Compress-Archive;Get-FileHash.The nested build script rejects WSL/non-Windows execution and checks for the x64 MSVC compiler and CUDA compiler. See the native Windows build instructions before packaging.
The shell packager also accepts a windows argument and uses zip, but it
still invokes the Windows Cargo alias. The native PowerShell entry point is the
documented path for normal Windows releases.
There is intentionally no aggregate all mode. Strix Halo and DGX Spark
artifacts require mutually exclusive native hardware identities, while the
Windows and macOS artifacts require their own platform SDKs. Build each
artifact on its matching host and aggregate the checksum-verified files in the
release workflow.
For package version 1.10.2, the generated tree is:
releases/
├── werk1112-v1.10.2-linux-x86_64.tar.gz
├── werk1112-v1.10.2-linux-x86_64.tar.gz.sha256
├── werk1112-v1.10.2-linux-x86_64-amd-strix-halo.tar.gz
├── werk1112-v1.10.2-linux-x86_64-amd-strix-halo.tar.gz.sha256
├── werk1112-v1.10.2-linux-aarch64-dgx-spark.tar.gz
├── werk1112-v1.10.2-linux-aarch64-dgx-spark.tar.gz.sha256
├── werk1112-v1.10.2-windows-x86_64.zip
├── werk1112-v1.10.2-windows-x86_64.zip.sha256
├── werk1112-v1.10.2-macos-aarch64.tar.gz
└── werk1112-v1.10.2-macos-aarch64.tar.gz.sha256
Staging directories are recreated below target/package/<platform>. Existing
archive and checksum files with the same version and platform name are
replaced by the packaging script.
Inspect Unix archive contents:
tar -tzf releases/werk1112-v<VERSION>-linux-x86_64.tar.gz
tar -tzf releases/werk1112-v<VERSION>-linux-x86_64-amd-strix-halo.tar.gz
tar -tzf releases/werk1112-v<VERSION>-linux-aarch64-dgx-spark.tar.gz
tar -tzf releases/werk1112-v<VERSION>-macos-aarch64.tar.gz
Inspect the Windows archive on a Unix host with unzip:
unzip -l releases/werk1112-v<VERSION>-windows-x86_64.zip
Verify a shell-generated checksum from inside releases/:
cd releases
sha256sum -c werk1112-v<VERSION>-linux-x86_64.tar.gz.sha256
On Windows, compare the generated file with:
Get-Content .\releases\werk1112-v<VERSION>-windows-x86_64.zip.sha256
Get-FileHash .\releases\werk1112-v<VERSION>-windows-x86_64.zip -Algorithm SHA256
After extracting on the matching target, run the packaged binary directly:
./werk --help
.\werk.exe --help
Artifact verification should test the router binary itself. Optional runtime
health remains host-specific and is checked after installation with
werk backend doctor --debug.
The installer scripts download these exact artifact names from a GitHub release
whose tag is v<VERSION>:
| Installer | Supported downloads |
|---|---|
scripts/install.sh |
linux-x86_64 on generic Linux x86_64; linux-x86_64-amd-strix-halo when specific CPU, DMI, Radeon 8050S/8060S/8040S, or gfx1151 signals identify Strix Halo; linux-aarch64-dgx-spark only when Linux arm64 identifies DGX Spark/GB10; macos-aarch64 on Apple Silicon macOS |
scripts/install.ps1 |
windows-x86_64 on native Windows |
Both installers accept WERK_VERSION with or without a leading v. When it is
unset they query the latest GitHub release. WERK_REPO can select a different
GitHub repository, and WERK_INSTALL_DIR changes the binary destination.
The POSIX installer downloads the archive’s sibling .sha256, requires
sha256sum or shasum, verifies it before extraction, and rejects archives
whose entries are not exactly werk, README.md, and LICENSE.
The packaging scripts only create local files. They do not create a Git tag, create a GitHub release or upload artifacts.
After merging feature and fix changes, open Actions → Release → Run workflow
on the default branch and keep the default auto version mode. No manually
prepared release PR or local preparation command is needed. The workflow updates
the product version files and lockfiles, dates the changelog, generates the README
release section and updates current documentation references. It creates a
canonical Linux CLI build (--no-default-features, no optional backend features)
in target/cli-reference-neutral after the version bump, then regenerates and
checks all five CLI/parameter catalogues before preparing the release PR. It then
creates a release PR with the built-in GITHUB_TOKEN, merges it immediately when branch
rules allow it, then tags the actual merge commit as
v<VERSION> and creates the GitHub release from those notes. The workflow must
first be merged into the default branch to appear in GitHub’s manual workflow menu.
auto examines non-merge commits since the latest stable tag:
! before the colon, or a BREAKING CHANGE: /
BREAKING-CHANGE: footer, selects the next major version.feat: or feat(scope): commit (including this repository’s feat():
form) selects the next minor version.Commit messages therefore determine the automatic compatibility classification.
The optional patch, minor and major selections override it. If product
metadata already contains an untagged newer version, auto validates and uses
that prepared version instead. If there are no commits after the latest release
tag, auto reuses that release instead of creating another version.
Existing Unreleased changelog bullets become the release notes. If that
section is empty, the workflow generates notes from commit subjects and hashes.
A curated ### Highlights section is used for the README when present;
otherwise it copies the first five change bullets. Neither a highlights section
nor a manually prepared changelog entry is required to start a release.
The workflow synchronizes Cargo, Media Companion, ComfyUI and n8n versions. It also updates installation examples, artifact filename examples, protocol service-version examples, integration READMEs, parity references and the current validation reference. Historical results and dependency/protocol/schema versions are preserved. Content-specific API explanations and actual test evidence still belong with their feature changes; commit subjects are not an inferred technical summary of the source code.
The generated CLI reference comes from the freshly built release-version CLI,
using help and model-free task schemas. A --check against that binary must
pass on the prepared tree before a tag can be created or reused. A generator
or build failure stops the release. Retries of an existing tag only check its
documentation; they do not rewrite the tagged reference. No model downloads,
backend installations or inference are needed for this step.
Keep release as a draft is enabled by default. Build the platform artifacts
from the generated tag, upload the archives and their .sha256 files to the
draft, then publish it. This keeps the previous release available to installers
until the new downloads are ready. Disable the draft option to publish immediately
and attach artifacts afterward. The workflow builds a local CLI for reference
generation, but does not package platform artifacts, upload assets, publish to
npm or publish to the ComfyUI Registry.
The release-tool tests, CLI reference build/check and metadata validation run
directly in this workflow.
The generated version/documentation commit includes [skip ci], so it does not
start duplicate CLI Reference, Werk Observability, n8n Custom Nodes (Beta)
or ComfyUI Registry PR workflows that would require manual approval when
opened with GITHUB_TOKEN. This marker is limited to the generated release commit;
normal feature and fix PRs retain their CI. Release runs the canonical reference
build/check inline before the PR and checks again before tagging. No required
checks or branch protections are changed or bypassed; repository rules still
govern merging. Complete ordinary PR checks before starting Release. Native GPU
smoke tests and platform artifact builds remain manual.
See GitHub’s skip instructions.
No custom GitHub App, personal access token or additional release secret is
required. The workflow uses the built-in GITHUB_TOKEN for PR creation, merging,
tags and the GitHub release. The release remains a draft by default until you
upload the platform artifacts and publish it.
The built-in token retains contents: write and pull-requests: write for
merging and publishing. Branch protection remains enabled; the workflow does
not approve reviews, force-push or use an administrator bypass. The current
repository does not configure required status checks, so the release workflow
can merge the metadata PR immediately. If required reviews or status checks are
configured later, they must be satisfied; skipped required checks block merging.
The workflow does not bypass those rules. Enable Allow GitHub Actions to create
and approve pull requests under Settings → Actions → General → Workflow
permissions so the built-in token can create the preparation PR.
The default branch is checked out at job start, including on retries. If it advances before the release PR is merged, the workflow stops; start it again on the latest branch. Its release branch includes the base commit identifier and is reused only when its tree matches the generated files. Existing open PRs for that branch are reused. Historical failed/approval-blocked PR runs are left intact; this change prevents new duplicate runs for generated release commits.
If a merge or tag push succeeded but a later step failed, run again with auto
before merging more commits. An untagged prepared version must have a merged
preparation PR and pass metadata validation. The retry reuses the prepared
version, tag and notes. An existing GitHub release is left intact, including its
assets, notes and draft/publication state. A repeated click never publishes an
existing draft implicitly.
If newer feature commits have already landed after a partial release, recover
its existing tag through GitHub’s release UI or gh release create v<VERSION>
--verify-tag --draft --title "Werk1112 v<VERSION>" --notes-file release-notes.md,
using that tag’s dated changelog entry. Do not move or delete the tag.
For a local preview on a clean checkout with all release tags fetched:
python3 scripts/prepare-release.py auto --notes-file /tmp/werk-release-notes.md
This only edits files; it does not commit, tag, push or publish. check validates
an untagged prepared version without changing tracked files:
python3 scripts/prepare-release.py check --notes-file /tmp/werk-release-notes.md
python3 -m unittest discover -s scripts/tests -p 'test*release*.py'
auto and draft mode.ComfyUI Registry publication is a separate manual workflow dispatch on the default branch, after its validation and archive checks pass. The n8n package remains private and is distributed through the documented manual custom-directory installation; preparing the product release does not publish it to npm. Optional oMLX requires a separate installed runtime, and its native Apple Silicon smoke tests must be distinguished from simulated preflight and HTTP tests.
The repository currently has no checked-in GitHub Actions workflow that builds or publishes the Werk release archives. The steps above remain a manual or externally orchestrated release process.