The tool is asbmutil, a CLI I wrote for the Apple School and Business Manager API. It’s a Swift program — SwiftUI app, credentials in the macOS Keychain, signed and notarized through Apple’s toolchain. You’d assume all that pins it to a Mac. Nope.

Every release ships a static Linux binary as a first-class sibling to the macOS build. The Mac binary and its SwiftUI app matter just as much — that’s how you use asbmutil locally. The Linux sibling exists for the other half of the job: headless automation — an Azure Function, an AWS Lambda, a CI job, anything that runs Linux with no one watching. This post is about that Linux side — how I run it in Ubuntu, what the moving parts are, and the things it’s good for.

Copy-paste-able CI samples

The whole pattern is in the repo as runnable samples, so you can lift it straight into your own CI: examples/ci/.

• setup-asbmutil.sh — downloads the latest Linux release and loads credentials from three env vars (steps 1 and 2 below).
• asbmutil-report.yml — a read-only GitHub Actions workflow that pulls the ASBM picture on a daily schedule and uploads it as an artifact: a standing “is ASBM drifting from my inventory?” heartbeat.
• asbmutil-assign.yml — reassigns a set of serials to a target MDM server: manual-trigger, dry-run by default, showing the current assignment before it changes anything.

We run the real thing in Azure DevOps Pipelines, but the steps are identical on any runner — the GitHub Actions files are just the most copy-pasteable form. The rest of this post is the walkthrough behind them.

How the Linux build works

Swift cross-compiles to Linux cleanly, and the whole build comes down to one flag:

swift build -c release --product asbmutil --static-swift-stdlib

--static-swift-stdlib folds the Swift runtime into the binary, so the result is a single self-contained asbmutil that runs on a bare Ubuntu image with no toolchain installed. The release workflow builds one on every tag and attaches it next to the signed macOS build as asbmutil-<version>-linux-amd64.tar.gz.

The only genuinely Mac-specific thing in the whole program is credential storage, and that’s behind a compile-time fork. When the Security framework isn’t importable — i.e. you’re not on Apple’s platforms — it swaps the Keychain for a file store:

#if !canImport(Security)
// File-based credential storage for Linux (no macOS Keychain available).
// Credentials are stored as JSON files in ~/.config/asbmutil/ with 0600 permissions.

That fork is the only Linux-specific line in the whole thing. Everything else is plain Swift that compiles as-is, so from here it’s just three steps.

Step 1 — get the binary into CI

The setup script asks the GitHub API for the latest release, grabs the asset whose name contains linux, and unpacks it onto PATH:

asset_url=$(curl -fsSL https://api.github.com/repos/rodchristiansen/asbmutil/releases/latest \
  | python3 -c "import sys,json; a=json.load(sys.stdin)['assets']; print(next(x['browser_download_url'] for x in a if 'linux' in x['name']))")
curl -fsSL -o asbmutil.tar.gz "$asset_url"
tar xzf asbmutil.tar.gz -C bin
chmod +x bin/asbmutil

That’s it — no apt install, no Swift on the runner. On our actual deploy pipeline it rides into the function zip alongside mdmctl (for the MicroMDM side), two little binaries in the same bin/ folder.

Step 2 — credentials without a Keychain

This is the step that bites you, and it bit me for an afternoon. On macOS you’d run asbmutil config set once and forget it; the secrets go in the Keychain. On Linux there’s no Keychain, so the file store expects its JSON in ~/.config/asbmutil/. Fine — except the store has to find that directory, and on Linux with musl, FileManager.homeDirectoryForCurrentUser calls getpwuid(), which returns the passwd home (for a service account that’s often /nonexistent) and flatly ignores $HOME. So the store reads $HOME explicitly first:

let homePath = ProcessInfo.processInfo.environment["HOME"]
    ?? FileManager.default.homeDirectoryForCurrentUser.path

The practical upshot: make sure your CI job has HOME set (GitHub and Azure runners do by default), and then the cleanest way to load credentials is to let the tool write its own store. Keep the ASBM client id, key id, and PEM private key as CI secrets, write the PEM to a temp file, and run config set:

printf '%s' "$ASBM_PRIVATE_KEY_PEM" > key.pem
asbmutil config set --client-id "$ASBM_CLIENT_ID" --key-id "$ASBM_KEY_ID" --pem-path key.pem
rm key.pem

No secrets in the repo, nothing persisted on the runner beyond the job. (In our production path — a Python Azure Function — I skip config set and lay the store’s JSON files down directly from app settings, 0600, because the function is already handling secrets from Key Vault. Both roads end at the same ~/.config/asbmutil/.)

Step 3 — script the commands

What makes asbmutil pleasant to drive from any script is a boring discipline: clean JSON on stdout, every diagnostic on stderr. Piping into jq or json.loads never breaks on a progress line. A handful of read-only commands cover most of what you’d want to watch — every MDM server and its id, the devices grouped by server, which server a given set of serials is on, and full per-device attributes (including AppleCare and assigned MDM):

asbmutil list-mdm-servers
asbmutil list-devices-servers --all
asbmutil list-devices-servers --serials A,B,C
asbmutil get-devices-info --serials A,B,C

list-devices-servers is the one worth calling out. The naive “which MDM is this Mac on?” is one API call per device; for a few thousand Macs that’s a rate-limit headache. This inverts it — it lists each server’s devices (four or five calls total, regardless of fleet size) and intersects against the serials you asked about.

The worked example: our MDM migration reconciler

Stack those three steps together and you can automate real work. We’re in the middle of an MDM migration right now, and it’s a good example.

I wrote a reconciler to keep the migration on track — a blob-triggered Azure Function. It reads the desired server (old vs. new) for each serial from an inventory CSV (we use Snipe), asks ASBM what’s true right now, diffs the two, and fixes the gaps. That’s four asbmutil verbs:

subprocess.run([ASBMUTIL, "list-devices-servers", "--serials", serials], ...)
subprocess.run([ASBMUTIL, "unassign", "--serials", movers, "--mdm", old_server], ...)
subprocess.run([ASBMUTIL, "assign",   "--serials", movers, "--mdm", new_server], ...)
subprocess.run([ASBMUTIL, "batch-status", activity_id, "--poll", "--interval", "10", ...], ...)

We change a device’s MDM server in our inventory, and the function makes Apple School Manager match.

Read current state, then — for the devices the diff says should move — unassign them from the old server and assign them to the new one, grouped by server so each side is one batch. The server names (old_server, new_server) come straight out of the diff, not hardcoded. Then poll the async batch to completion — one process, one OAuth token, instead of reimplementing the poll loop in Python.

Two things make this safe to run unattended. First, the diff is a four-way comparison — previous ASBM state vs current, previous inventory vs current — so it can tell who moved a device. Inventory changed and ASBM didn’t? Migrate. ASBM changed on its own (an admin did something in the portal)? Leave it, report drift. Both changed and disagree? Conflict — don’t touch it, flag a human. An automated reconciler that blindly enforces one side will happily undo a deliberate manual change every five minutes; the four-way diff is what stops that.

Second, every mutating call is wrapped so a DRY_RUN env flag turns it into a log line — so a full migration run can be rehearsed against real ASBM state without touching a single device.

Don’t take the API’s word for it

Two things about Apple’s API will burn an unattended job if you let them.

First, the activity endpoint accepts any serial you send it. Pass one that isn’t in your ASBM account — a reseller filed a shipment notice but never registered the device, or someone fat-fingered it — and the activity still comes back IN_PROGRESS, then COMPLETED, having done nothing. So assign and unassign pre-flight every serial against GET /v1/orgDevices/{id} and drop the 404s before submitting (pass --skip-verify to opt out).

Second, COMPLETED doesn’t mean the device landed on the server you asked for. --confirm closes that gap: after the batch finishes it re-queries each device’s assigned server, checks it against the intended end state, and exits non-zero if anything’s off — so the function can treat a partial run as the failure it is.

And if you want proof from Apple’s own records rather than your logs, the 2.0 API exposes an org audit log that audit-events queries by time range and type — pulling DEVICE_ASSIGNED_TO_SERVER for the migration window gives you an independent record straight from Apple’s side. The catch: this one is Business Manager only. School Manager’s API is still at 1.5 and doesn’t expose the endpoint, so as a university on ASM I can’t lean on it yet — the tool fails fast with a clear message instead of a raw 404, and on the School side I fall back to --confirm and a re-query of assigned servers. On Business Manager it looks like this:

asbmutil audit-events --start 2026-07-01T00:00:00Z --end 2026-07-14T23:59:59Z --type DEVICE_ASSIGNED_TO_SERVER

What else it’s good for

A clean, scriptable window into ASBM is useful for a lot that has nothing to do with switching MDMs:

• A nightly ASBM ↔ inventory drift report — list-devices-servers --all diffed against your source of truth answers “what’s in ASBM that inventory doesn’t know about, and vice versa.” Catches devices bought but never enrolled.
• Fleet-wide AppleCare coverage — list-devices --include-applecare fans out per-device coverage lookups (Apple has no bulk endpoint, so it does a parallel pass plus a sequential retry for the ones Apple’s HTTP/2 endpoint drops). Feed that to a dashboard and see what’s about to fall out of warranty before a lab tech does.
• MAC addresses into inventory — recent API versions expose Wi-Fi, Bluetooth, and Ethernet MACs per device via get-devices-info, handy for network access control.
• Multi-tenant management — the profile system lets one binary drive several ASBM instances (--profile school-east, --profile business-unit-3). Manage more than one org and you’re passing a flag, not juggling logins — which is exactly what you want in a CI job.
• Bulk pre-staging — assign a cart of freshly-bought Macs to the right MDM server before they’re unboxed, straight from a CSV off the purchase order, so they enroll correctly on first boot with zero touch.
• Resumable audits of huge fleets — list-devices --resume checkpoints after each page, so a pull across tens of thousands of devices survives a transient timeout instead of starting over.

It’s pretty cool to have Apple School and Business Manager scriptable. Every device-to-server assignment, every server’s roster, whole-fleet AppleCare, MAC addresses, audit history — all of it is JSON you can pipe, diff, schedule, and act on. Point a cloud function or a CI job at it and let reconciliations run on their own. This used to mean clicking through a web portal one device at a time. Scripting it instead still feels a little bit magic.

asbmutil is open source and MIT, and the CI samples are ready to lift — if you run a fleet through ASBM, go automate the boring parts. PRs welcome.

When Apple finally released the API for Apple Business & School Manager last year I was thrilled. I took it as an opportunity to try and create a Swift CLI for it which ended up being asbmutil, a Swift binary that directly communicates with the Apple School & Business Manager API. I posted it in the MacAdmins Slack, didn't think much about it, and it ended up getting used by folks — along with requests to make it better.

Today I'm shipping ASBMUtil.app, a native SwiftUI front-end on top of the same engine. Same credentials store, same API client, same bulk operations — inside a native Liquid Glass Tahoe app.

Not every Mac admin wants to live in the terminal. Even a well-built CLI carries its own friction — "here's the command, make sure the profile is set, redirect jq somewhere, don't forget the –mdm flag…"

Hence the GUI app. Same engine underneath, same credentials store, same API client.

What's in the App

The main view is a single native table with every managed device in your Apple Business & School Manager account — Macs, iPads, iPhones, Apple TVs, all of it — right next to each other. Click a row and a sidebar slides in with the full device details: serial, order, status, MDM assignment, AppleCare coverage, MAC addresses, the works. Select a handful, right-click, reassign.

• Device browser — every managed device in one paginated, sortable table with a details sidebar. AppleCare coverage enrichment is a toggle away.
• Powerful filters — filter by device status, by order number, by model family, by MDM server — stack filters to narrow to exactly the specific devices you want.
• MDM server list and assignments — see every server and what's assigned to it.
• Bulk assign / unassign — multi-select in the table, pick a destination server, go. Or import a CSV if that's how your desired state arrives.
• Export to CSV or JSON — selection or filtered results out through the macOS share sheet.
• Multi-profile switching — flip between Apple Business & School Manager instances from the sidebar; manage credentials in settings.

Filters

The filters match the web — same categories, same stacking behaviour — so if you already use the ABM filters, you already know how these work. The difference is that here they run against a native table with every device already loaded, so stacking is instant, the selection carries into bulk assign/unassign in one click, and the filtered set exports to CSV or JSON through the share sheet.

Filter by order number, device status, model family, or MDM server — and stack them, so "unassigned iPads from the last PO that haven't been routed to Intune yet" is three clicks.

Once you've narrowed to the right cohort, export (CSV/JSON) or bulk-reassign works on the filtered selection — not on the whole fleet.

What You Get

• Pure Swift 6 binary — no external runtime dependencies.
• Credentials stored in the macOS Keychain — data-protection class, no per-app ACL prompts.
• Multiple profile support — manage several AxM instances (school-district-east, business-unit-3, whatever) from a dropdown instead of –profile flags.
• Automatic OAuth 2 client-assertion handling — token lifecycle handled for you.
• Paginated device fetch — walks the full inventory without you worrying about page cursors.
• Bulk operations — CSV import or multi-select directly in the GUI table.
• StrictConcurrency enabled — actor-isolated, race-free by design.
• Bulk device-to-server resolution — server-side device listing gets the whole fleet in 4–5 API calls regardless of size, instead of per-device lookups.
• Bulk AppleCare enrichment — list-devices –include-applecare runs a two-pass fan-out across the whole fleet, no CSV required.

Recent API Coverage

I've kept the tool caught up with the AxM API as Apple has shipped new fields:

• API 1.5 — MAC addresses now support multiple values (array format) for devices with multiple network interfaces.
• API 1.4 — Wi-Fi, Bluetooth, and built-in Ethernet MAC addresses for macOS.
• API 1.3 — AppleCare coverage lookup for devices (single-serial via get-devices-info, whole-fleet via list-devices –include-applecare).
• API 1.2 — Wi-Fi and Bluetooth MAC addresses for iOS, iPadOS, tvOS, and visionOS.

Running in the Cloud

Alongside the GUI app, the other side of the coin — fully cloud, headless operations — has gotten a lot of work too. Fully static Swift runtime via –static-swift-stdlib, URLSession fixes for musl, and keychain-less credential provisioning from env vars so the same codebase runs cleanly on Ubuntu. One Swift 6 binary, one data model, one API client — running unchanged inside Azure Functions, AWS Lambda, or any Linux container.

Cloud automations that the Linux binary offers:

• Reconciliation (inventory → Apple) — a trigger fires off a desired-state list (a CSV, a DB query, an event), the function asks asbmutil what Apple Business & School Manager currently shows, diffs the two, and issues assign/unassign calls to close the gap. Anything the inventory system considers authoritative — MDM server, department, ownership tags — can drive the comparison.
• Enrichment (Apple → inventory) — a timer pulls the full device list plus AppleCare coverage via asbmutil, hashes the normalised payload per serial, stores the fingerprint in blob storage, and only writes back to inventory when the Apple-side data has actually changed. Warranty months, coverage status, order number, MDM assignment — all flow in automatically, and the hash cache keeps API traffic and downstream write-load proportional to real change, not fleet size.

Outcome: inventory and Apple Business & School Manager stay in lockstep without anyone opening either UI. Warranty data flows in one direction, MDM assignments in the other, both driven by the same Swift binary you'd run on your Mac.

I plan to write in more detail how I'm running these and the code behind them in follow-up posts.

How to Use All Three

The CLI has its place. It's the thing I'll use to check which MDM a device is assigned to when I need quick operations — asbmutil list-devices-servers –mdm "Intune" piped through jq and grep, done in a second.

For bulk operations I reach for the GUI app — load a CSV, select in the table, hit the button. Being able to see what's assigned, what's unassigned, and peruse the fleet side-by-side catches mistakes before they ship and surfaces clean-up opportunities you'd miss on the command line.

And for the continuous, unattended work — nightly syncs, warranty enrichment, inventory reconciliation — the Linux binary inside a serverless function quietly does it in the background, no interaction, automated.

Same data model, same trust store, same API calls underneath.

Grab It

Repo: github.com/rodchristiansen/asbmutil

Grab the latest .pkg or .dmg from the releases page. The installer drops both the app into /Applications and the asbmutil CLI into /usr/local/bin.

A note on signing: the released artifacts are unsigned and not notarized. On first launch Gatekeeper will complain — clear the quarantine attribute and you're good:

xattr -dr com.apple.quarantine /Applications/ASBMUtil.app
xattr -dr com.apple.quarantine /usr/local/bin/asbmutil

Or build and sign it yourself from source — make build in the repo will do the whole signing + notarization dance if you drop your own Developer ID into .env. As Mac admins you know the drill.

Requirements: macOS 14+, and an AxM API account with a client ID, key ID, and PEM. If you already have the CLI configured, the app reads the same keychain profiles — nothing to migrate.

More posts coming on the specific things this tool makes trivial that ABM's web UI makes painful — starting with the bulk device-to-server resolver, which I think is the most interesting piece of the codebase. For now: v1 of the app exists, it works, and I'd love to hear where it breaks for you.

A year ago, we were managing Macs the way most orgs still do: one shared Mac, VNC’d into, running a local copy of Munki with no real version control or workflow isolation. Git was an afterthought. Deployments were manual. It worked—until it didn’t scale.

We’ve since inverted the model. Git is the gate. CI is the deployer. Each admin works from their own machine. And the Munki repo is fully DevOps-native.

Here’s how we rebuilt everything using Git, Azure DevOps, Service Bus, pipelines, local caching servers, and inventory automation—all open source and cloud-integrated.

From Manual to DevOps

The legacy flow was:

• GitLab running on-prem
• One shared Mac as the deploy point
• One central repo, updated by many hands
• No pipeline. No hooks. No approval gates.
• Everyone stepped on everyone’s toes

Now we have:

• Azure DevOps Git repos and pipelines
• Git hooks that upload/download packages automatically
• Separate working copies per admin
• Local caching servers that sync intelligently
• A full CI/CD system that integrates with inventory and deploys via pull requests

Architecture Overview

We’ve split this into two core flows:

Munki DevOps Infrastructure

• Admins commit to a shared Azure DevOps repo with manifests/ and pkgsinfo/
• Git hooks (post-commit/merge) run azcopy sync to upload or download packages
• A pipeline (munki-push-production.yml) builds catalogs and updates Azure Storage
• Local caching servers (like PLUTO and PROTEUS) are notified via Azure Service Bus
• A daemon listens for commits and runs git pull and syncs assets
• CDN serves files globally or from on-prem caches
• It’s fast, redundant, and observable

Inventory-Orchestrated Enrollment

• A polling script checks Snipe-IT for inventory changes and builds new CSVs
• CSVs are committed to Git → triggers DevOps pipelines → runs enrollment-munki, enrollment-intune, enrollment-sharepoint, and more
• Each system (Munki, Intune, Fleet, TDX, Papercut) gets updated data
• Pull requests are the approval gate
• Everything is traceable, auditable, and CI-driven

Resources

• Presentation Repo: github.com/rodchristiansen/munki-devops

Want to talk shop or ask questions? Connect with me on BlueSky or on the GitHub.

Wiring Git Credential Manager (GCM) into your local global Git helpers you trade fragile over-scoped PATs for one-hour tokens that renew silently and leave no secrets on disk or in build logs.

What this guide helps you with

• Enable seamless Single‑Sign‑On on macOS and Windows for:
  • Azure DevOps (https://dev.azure.com/ORG/…)
  • GitHub.com or GitHub Enterprise (https://github.com/…)

macOS

How to setup GCM for password‑free access on macOS:

Prerequisites

• Homebrew
• Git ≥ the version bundled with Xcode 15
• Git Credential Manager (installed below)

Install / upgrade components

brew install --cask git-credential-manager
brew upgrade git

Configure global helpers

git config --global --replace-all credential.helper manager
git config --global --add credential.helper osxkeychain
git config --global credential.msauthFlow devicecode
git config --global credential.guiPrompt false

Persist settings for shells & GUI apps

echo 'export GCM_MSAUTH_FLOW=devicecode' >> ~/.zprofile
echo 'export GCM_GUI_PROMPT=0' >> ~/.zprofile
launchctl setenv GCM_MSAUTH_FLOW devicecode
launchctl setenv GCM_GUI_PROMPT 0

• VS Code: add "git.terminalAuthentication": false to settings.json
• Git Tower: defaults write com.fournova.Tower5 UseCredentialManager -bool true

First run

git fetch   # single device‑code prompt, then silent

Windows

And here's how to setup on Windows, leveraging the Entra ID broker for silent SSO with Azure DevOps and device‑code for GitHub.

Prerequisites

• Git for Windows ≥ 2.45 (bundles GCM v2)
• Device joined to Entra ID (native, hybrid, or AAD‑registered)

Clean up old helpers

git credential-manager unconfigure
git credential-manager configure
git config –global –unset-all credential.helper
git config –global –remove-section credential

Enable Broker SSO (Azure DevOps) and Device Code (GitHub)

git config –global credential.helper manager-core
git config –global credential.microsoft.sso true
git config –global credential.msauthUseBroker true
git config –global credential.msauthFlow broker
git config –global credential.githubAuthModes devicecode

Strip hard‑coded usernames from remotes

git remote set-url origin https://dev.azure.com/ORG/PROJECT/_git/REPO
git remote set-url origin https://github.com/ORG/REPO

First run

git fetch   # one Windows dialog, then silent

Bulk‑fix existing repositories (optional)

Replace the sample paths below with the folder that contains multiple repositories.

PowerShell (Windows)

Get-ChildItem C:\Dev\Repos -Directory | ForEach-Object {
git -C $.FullName remote set-url origin (git -C $.FullName remote get-url origin -replace '://.@', '://')
}

zsh (macOS)

for d in ~/Dev/Repos/(.); do
url=$(git -C "$d" remote get-url origin | sed 's#://.*@#://#')
git -C "$d" remote set-url origin "$url"
done

Troubleshooting

Run git-credential-manager diagnose for a quick health check. Erase stale tokens with:

git credential-manager erase https://dev.azure.com
git credential-manager erase https://github.com

Need verbose output? Temporarily set:

export GIT_TRACE=1
export GCM_TRACE=1
git fetch

If GCM prompts twice on macOS, login.keychain-db may be read‑only. Unlock and purge stale entries, then retry:

security unlock-keychain ~/Library/Keychains/login.keychain-db
git credential-manager erase https://dev.azure.com
git credential-manager erase https://github.com

By switching from long-lived PATs to short-lived tokens through Git Credential Manager, you lock down your supply chain while making everyday Git activity faster and quieter:

• MFA is enforced automatically and refreshed in the background.
• Tokens rotate every hour, slashing the window for theft or replay.
• No secrets leak into scripts, CI logs, or dotfiles—nothing to scrub later.

Bake these GCM settings into your workstation images and onboarding scripts once, and every clone, fetch, and push runs hands-free from that point on. Stronger security, zero extra clicks, and no browser pop-ups—that’s a win on every front.

Publishing Like a Dev: Meet GhostPost

You use Ghost because it’s modern, open, and built for professional creators. It gives you newsletters, subscriptions, and a full publishing stack that doesn’t sell your soul to adtech.

You use Git because you want version history, branches, and working with the all mighty plain text.

ghostpost is a GitOps-style CLI for managing Ghost posts.

Each post lives as a Markdown file in your repo. The front-matter stores all metadata—including the Ghost post_id.

You edit locally. You commit. ghostpost publishes.

Why I Built This

I wanted a writing workflow that matched how one might ship code.

• No fragile CMS UI edits
• No "oops I deleted the draft"
• No back-and-forth between browser and source doc

The Ghost GUI becomes just a preview tool. Nothing gets edited in it.

Not necessarily a new idea—post2ghost laid out the same "Articles as Code" concept where content belongs in Git. The CMS should be a rendering layer, not an editing platform.

That post nailed the philosophy:

• Keep Markdown files under version control
• Write in your editor of choice
• Automate publishing with API calls

It was still a bit DIY and python based which is a dependency headache -- I love python, but not for cli tools...

ghostpost takes that same idea and wraps it in a clean CLI. One command and simple.

How It Works

You write a post in Markdown, with front-matter like this:

---
title: Your title here
slug: your-slug
custom_excerpt: Short summary here
tags: [DevOps, Ghost]
feature_image: images/cover.jpg
status: draft
---
Your content in Markdown.

Then you run:

ghostpost publish -f /path/to/post.md –editor

The tool takes care of:

• Creating the post if it’s new
• Updating the post if it already exists
• Uploading and rewriting image paths to proper Ghost URLs

There’s no runtime. No daemon. No need to open the CMS.

What You Get

• Real version control Posts live in Git. You get git log, pull requests, inline diffs, CI checks.
• Stateless deploys Posts can be published from anywhere. Just point to the Markdown file. Or automatically with CI/CD.
• Front-matter is the truth Titles, tags, status, authors, descriptions—everything is stored right inside the Markdown file.
• Smart images Use local paths. ghostpost uploads and rewrites them for you.
• CI-ready Validate structure. Block merges on bad metadata. Push on deploy.

Here’s a basic example using GitHub Actions:

# .github/workflows/publish.yml
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: ghostpost publish -f posts/hello-from-git.md –editor

Why Not Just Use the Ghost UI?

Because once you’ve versioned your posts, previewed with Markdown, and deployed with a single command—there’s no going back.

No clunky editors. No missing history. No surprises.

Get Started

Check out the repo and the readme at https://github.com/rodchristiansen/ghost-gitops-publishing

Install the binary, connect it to your Ghost API, and start treating your writing like the rest of your infrastructure: reproducible, testable, and versioned.

It worked—until it didn't.

We moved from running local scripts on a shared Mac to each admin working from their own local repo, committing changes through Git, syncing packages with az git hooks. We used to push changes first, then capture them in Git after the fact. Now, Git is the gate. Commits and PRs drive the entire process. Pipelines run automatically, and the cloud becomes the source of truth. Our local caching servers listen for updates—pulling down only when there are changes—fully inverting the workflow into something distributed, reliable, and scalable. All of it version-controlled. All of it traceable. All of it running on infrastructure provisioned with Terraform.

Every config, every profile, every software assignment that matters tracked in Git. It’s CI/CD deployed, reproducible by design, and logged automatically for traceability.

What This Blog Is About

This blog is about the journey—the migrations, the patterns that emerged, the decisions that held up, and the ones that didn’t. And about the new tools and ideas I'll be building and using along the way.

If you work in endpoint management with DevOps, you’ll find deep dives into:

• CI/CD pipelines that manage device tools, states, and configuration
• Every cloud resource under Infrastructure as Code with Terraform
• Inventory systems that drive deployment logic
• And Git at the center of it all

As I now manage both macOS and Windows endpoints, I’ll be writing about how I'm creating a cohesive, mirrored management system—where both platforms are driven by open source tools, DevOps, and Git, and where admins speak the same language on both sides.

Focused Systems. Grounded in what actually works and scales. Very opinionated.

Let’s get to it.