Projects grouped by the problem they solve
These projects cross tools and disciplines, so I group them by what the work was for. Start with three projects that show the platform working end to end, or jump to one of the four engineering groups below.
Three projects that show the platform in motion
Each story starts with the result, follows the workflow across the systems it changes, and keeps the failure that changed the design.
The grouped project index
A project may cross several disciplines, but it appears once under its primary engineering problem. The three featured projects remain in their groups so the index stays complete.
Build a consistent foundation and keep it describable
These projects create the compute, operating-system, and inventory base that other automation assumes.
- Automated server provisioningLive in AutomationLabFeatured aboveBuilds a server as one consistent fact across five systems at once, with a collision gate that refuses to reconcile a live host by accident.Read project →View the code →
- The template factoryLive in AutomationLabGolden Windows images are rebuilt from code on a schedule instead of hand-patched, and the build verifies itself before anything is promoted live.Read project →View the code →
- The platform mapLive in AutomationLabFeatured aboveCombines inventory structure with monitoring state, then publishes a sanitized projection. Its postmortem follows the identifier leak that reached that public projection.Read project →View the code →
Find failure early and leave a path back
These projects deal with unhealthy systems, destructive cleanup, and the evidence needed before a backup or remediation can be trusted.
- Restore verificationLive in AutomationLabRestores a protected guest into a fenced network, runs operating-system and service assertions, then destroys the copy and verifies that it is gone.Read project →View the code →
- Dead-man monitoringLive in AutomationLabPushes completion age into Zabbix and uses separate alarms for missed work and a stopped sender.Read project →View the code →
- Self-healing monitoringLive in AutomationLabClassifies a broken host, gathers the evidence, prepares the exact remediation plan, and performs only the action the operator approved. A separate monitoring-side verification loop is still needed before the pipeline can claim the host recovered.Read project →View the code →
- Decommission, with the gate that says noLive in AutomationLabDestroys a VM only after asserting the plan actually deletes something, so an empty plan can never pass as a successful teardown.Read project →View the code →
- AIOps morning triageLive in AutomationLabCollects overnight alerts, CI, and backup results, correlates them in code, and escalates only the hard cases to a subscription-backed model.Read project →View the code →
Renew trust before people or services feel the expiry
These projects manage the identities and trust relationships used by people, machines, and public services.
- Identity lifecycleLive in AutomationLabDrives directory account creation, group membership, disablement, and removal from definitions in code, with a reversible snapshot before destructive cleanup.Read project →View the code →
- Automated certificate and secret renewalLive in AutomationLabFeatured aboveThe shared public certificate reaches every registered consumer automatically. Credential paths rotate after their complete replacement and validation flow is proven, while exceptions remain visible.Read project →View the code →
Move requests and model work through recorded gates
These projects turn a request or data set into a reviewed output. Their main problem is orchestration: where evidence is collected, where judgment happens, which gate owns the decision, and how the result is recorded.
- Jenkins: the automation behind AutomationLabLive in AutomationLabRuns infrastructure requests, image builds, maintenance, and publication through versioned jobs, approval gates, isolated workers, and recorded results.Read project →
- CityAmbleBeta live at cityamble.comA web app that plans a city trip day by day on a map. It grew out of my Nashville, London and Paris planners and now plans every city in one app.Read project →
- The job reporting pipelineLive in AutomationLabJob search as a real pipeline: ingest, enrich, score, and report, with a truthfulness constraint hard-coded into the model prompt.Read project →View the code →
- API to usage-based AI pipelinesLive in AutomationLabRoutes unattended AI work through existing subscription headroom, with hourly provider selection, reserve thresholds, and a fail-closed path when neither provider is safe.Read project →View the code →
How the domains meet in one provisioning request
A server request is a useful example because it crosses all four groups without belonging to all four.
- Automation / Delivery receives the request. Jenkins or Backstage records the inputs, obtains approval, and keeps the run log.
- Platform allocates and creates the server. NetBox assigns the address, Terraform changes infrastructure state, Proxmox creates the VM, and Ansible configures the operating system.
- Identity / Security establishes trust. Vault supplies credentials at run time, Active Directory joins Windows where requested, Duo protects remote access, and machine identities limit each automation step.
- Reliability / DR observes the result. Zabbix begins monitoring, backup policy includes the new guest, and the generated map and NOC show its current state.
The project remains in Platform because the durable result is the recorded server. The domain labels describe the reader’s entry point, not walls between the systems.
What can be published
The complete operations repository remains private because it contains live configuration and network detail. A fail-closed publication check scans each finished public tree before it is pushed. Project cards link to their curated repositories where one is available. production-automation remains a separate de-identified reference implementation from earlier operational work.