An exact blast radius, confirmed twice
Target count, managed identity, artifact path, and the resolved command on one card. A strip shows each environment's runner: ready, working, stale, or missing.
Real PowerShell, from a browser — without the foot-gun.
The Forge lets operators run real PowerShell from the dashboard without the browser touching a shell. The web app records intent; a runner pinned to each environment claims hash-pinned, allowlisted work from SQL and leaves evidence for every run. It's the piece of the platform I'm proudest of.
PowerShell 7.6
SQL Server 2025
Node 24TanStack StartEffectPrisma 7xterm.js 6Hash-pinned manifestsAudit trail
◆ Built into the Azure Local operations platform.
45
runnable commands: 29 custom, 16 allowlisted from a 317-row catalog
15
SQL tables and 13 stored procedures behind the queue
5
environments, each with its own pinned runner
0
arbitrary shell exposed to the browser — three allowlists deep
// The problem
Operators need to run real ops. Browsers should never run real shell.
Half of monitoring is seeing the problem; the other half is doing something about it. Across five environments with their own domains and credentials, that means RDP, jump boxes, and tribal knowledge about which commands run, in what order, as whom.
You can't fix that by letting a web app shell out — that's how you hand the internet a domain admin. The Forge is the in-between: the browser can ask, the server can check, and only a runner can act.
// How it works
Manifest in, evidence out.
Nothing runs that isn't released, queued, and recorded.
01 REQUEST
An operator picks an approved command and targets from live inventory in one environment, then confirms the blast radius twice.
02 QUEUE
The server re-checks rights, release state, an online runner, and every target, then commits the job with a hash-pinned command snapshot. Schedules are revalidated every time.
03 RUN
That environment's runner claims the job — exactly one winner — and runs the fixed script for its command ID. Anything unknown throws.
04 CAPTURE
Output streams through SQL to an xterm.js terminal; closing the tab never touches the job. Every executed run ends with a merged log, a result JSON, and a ZIP.
05 AUDIT
Every job records who asked, what ran down to the command hash, and where. The gates are release gates, not a two-person sign-off.
// What it powers
Governed workflows, not one-off scripts.
BALANCE
Cluster balance report
Plans VM moves from a week of business-hours history. Report-only by default; applying runs at most 10 live migrations, each gated on health and memory, with intent written first.
RECONCILE
SharePoint warranty sync
Matches HCI collector serials against Lenovo warranty data and saves the inventory, both SharePoint lists, and every planned change before writing anything.
DIAGNOSE
AksArc remediation
Runs Support.AksArc as a scheduled task on the target, in Windows PowerShell 5.1 — catching tasks that never start, and always cleaning up.
// What was hard
The hard part was never running a script.
It was where, as whom, exactly once — and knowing when to stop.
Credentials stop at the first hop. Kerberos won't carry the runner's identity past a node to a share or cluster. So scripts ship from the runner instead of a share, cluster cmdlets run on the cluster, and console-only tools run as scheduled tasks on the target. CredSSP gets exactly one hop, live migration, after a preflight.
Live output wasn't live. Scripts blocked on Wait-Job and a proxy buffered the stream, so everything arrived at the end. Incremental pumping, with buffering off, fixed that — then the terminal flashed. It redraws from scratch unless the old text is an exact prefix, and every separator carried a running line count. The separators lost the count.
Long jobs broke two assumptions. A fixed timeout killed healthy multi-target jobs, so the budget now measures silence: it resets on every streamed record, with a five-minute floor. And the deploy guard once watched a job outlast its 15-minute drain, then deployed anyway. Now it stops. Five Pester cases cover that; an automatic deploy hasn't tested it yet.
Exactly once is a SQL problem. Claims use UPDLOCK and READPAST behind a guarded update: one winner, no waiting on locked rows. Then a pooled connection leaked an isolation level under which READPAST is illegal, so the procedures now pin READ COMMITTED. Nothing retries on its own; a re-run goes back through the gates.
-- One runner wins. The rest skip the locked row and move on. SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- never trust a pooled connection SELECT TOP (1) @JobId = JobId FROM ForgeJob WITH (UPDLOCK, READPAST, ROWLOCK) WHERE Status = 'Queued' AND EnvironmentCode = @EnvironmentCode AND CommandId IN (SELECT value FROM OPENJSON(@AdvertisedCommands)) ORDER BY QueuedAtUtc; UPDATE ForgeJob SET Status = 'Claimed' WHERE JobId = @JobId AND Status = 'Queued'; -- still ours? IF @@ROWCOUNT = 0 RETURN; -- lost the race; poll again in 5 s
◆ Public code-sample boundary
The hints and the guard are real; everything else is simplified or private. Ask me about the pattern →
// Operator surfaces
The queue and the live run.
No screenshots — the views, in words.
A real terminal, two separate verdicts
Six lifecycle steps, a searchable xterm.js terminal filtered by target, and separate status and result badges, so a failing command never looks like a platform outage.