Build1 distinct publisher2 min readPublished
RelayPublisher publishes YAML manifests as Intune line-of-business apps straight from CI, which relocates the right to write apps in your tenant from a human's time-boxed elevation to a pipeline credential that holds it permanently.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
This workflow relocates the elevation rather than eliminating it. `publish` creates or updates Intune apps and uploads packaged content [7], so the identity the pipeline authenticates as has to be able to create and update apps in the tenant every time the workflow runs. The source text I have cuts off mid-sentence in that description, so I cannot quote the Graph permission set it asks for.
For the trade to pay, a few things have to hold in your tenant. The pipeline credential needs to be scoped tighter than the role you were activating through PIM [3]. Branch protection on the manifest directory has to be a genuine approval gate, because it is now the only human in the path. And the CI run log needs to be retained at least as long as your elevation records, or the auditable escalation turns into an unreviewed secret.
This capability already existed before RelayPublisher. The author lists the existing routes as manual registration in the Intune portal, sample PowerShell scripts, or building your own automation on the Microsoft Graph APIs [2]. What RelayPublisher supplies is shape: a schema check that runs before anything reaches the tenant [4], and a resolved manifest list that later jobs consume instead of re-globbing the repository [5].
Getting the tool is four channels wide. Three are package feeds, nuget.org, GitHub Packages and Azure Artifacts [9], and the fourth is the set of self-contained single-file binaries attached to each GitHub release for win-x64, win-arm64 and osx-arm64 [10], which works out to four ways in [17]. Only the feed path is a one-liner, `dotnet tool install --global relaypublisher` [11], and the alternate feed instructions live in doc/05-operation.md [18]. The release binaries are neither code-signed nor notarized, so macOS shows a Gatekeeper warning [10]; the tool itself ships unmanaged even though its job is pushing managed software into a managed tenant.
Version numbers come from CI, injected from the `vX.Y.Z` Git tag [8]. That is the right default for a publishing tool, because it makes the artifact in the feed traceable to a commit without anyone typing a number. The repository is described by its author as the CLI foundation for the normal workflow [12], which is an honest label and worth taking at face value.
What decides adoption is how much of your existing app estate the manifest schema can actually express, a figure the post doesn't give. Where it fits, routine version bumps stop needing a person with standing rights. Where it does not, you are back in the portal [2], and the elevation comes back with you.
Ranked by verification strength, evidence, and original report placement.
The validate command checks manifest schema rules and repository-wide identity uniqueness.
The plan command resolves the target manifest set once and writes manifest-list.json for later CI jobs.
The package command stages app files: Windows Win32 .intunewin packages require a Windows runner, while a staged, checksum-verified macOS .pkg can be produced on any OS.
The publish command creates or updates Intune apps and uploads packaged content; the source description is truncated at that point.
Distribution is a NuGet global tool with package id relaypublisher and command name relaypublisher, and the package version is injected by CI from the Git tag vX.Y.Z.
The tool is published to three feeds: nuget.org, GitHub Packages (the project repository), and Azure Artifacts.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
One non-ASCII letter broke four toolchains: path checks belong in CI, not folklore1 distinct publisher
build
A Claude response header now names the workspace that actually handled the request1 distinct publisher
build
Native AOT buys a quarter-second of startup for 30MB and your reflection1 distinct publisher
build
Three permission problems wearing one service principal: why published agents return 4031 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
First-party and mostly self-verifying
Much of what is asserted is the kind of thing that checks itself — a package id, a command name, four subcommands, three feeds — and the author is the person who would know. But it is one post by the author of the tool, and the claims that matter most to a reader deciding anything (that this removes the elevation step, that the workflow holds up in a real tenant) are exactly the ones with no second witness.
Published, not yet used by anyone we can see
Shipping is real: the tool is on three feeds with binaries on every release, which is more distribution plumbing than most launch-day projects bother with. Users are a different matter — no organisation, no install count, no tenant, not even a second developer appears anywhere in this reporting.
Modest claims, one unexamined trade
The author is not overselling — he calls it a foundation and volunteers that his binaries are unsigned. The overstatement is structural rather than rhetorical: taking the elevation step out of routine updates is presented as pure relief, when it moves the right to write apps in a tenant from a time-boxed human approval to a credential a pipeline holds all the time. That trade is never named, and unsigned downloads for a privileged tool cut the same way.
The builder introducing his own build
This is a launch post by the person who wrote the software, on a platform where developers promote their own work, and the reputational payoff is stars and installs rather than revenue. He is candid about it — no sponsor, an open repository, an upfront note that the piece was translated from his Japanese original with AI help — so the pull is obvious rather than hidden, which is the mildest version of this problem.
Enough to try it, not enough to trust it
We can be fairly sure the tool exists, installs, and does roughly what its command names say; a reader can verify most of that in five minutes. Everything past installation — how it behaves against a real tenant, what its pipeline identity is allowed to do, whether anyone maintains it next quarter — has a single unaudited source and no track record behind it.