Changing your infrastructure should be boring. Not an event.

Automation & IaC Assessment

How much of your infrastructure could you rebuild without the person who built it? That's the first thing we measure.

• An as-is map of manual work — who changes what, and where — and an inventory of your source of truth: does one exist, or does the state of the estate live in people's heads and in text config files?
• Automation coverage per class of device and per environment — honest percentages, not yes or no — plus the drift gap: how many changes happen outside Git, and whether anyone notices.
• A toolset assessment (Terraform, OpenTofu, Ansible, Packer and your existing Git and CI base) — what to keep, what to consolidate, and what your licence exposure is — and a target GitOps model: desired state, dry run, and who approves what.
• A roadmap in three phases (quick wins, systematic approach, long-term projects) and a named key-person risk: what specifically stops when the person who builds the environment is away. Optionally, an independent read of an infrastructure audit you already paid someone else for.

From manual infrastructure into code

A script that ran once isn't automation. What we hand over is an environment you can build again.

• An automation platform — Git holding the desired state of the environment, plus a pipeline in your own environment (GitLab CI, Gitea Actions, GitHub Actions): a dry run that blocks on error, a real deployment after an approved merge. Self-hosted where the code must not leave your perimeter.
• Provisioning across the estate — Packer templates, Terraform or OpenTofu provisioning and deprovisioning, Ansible for Nexus, ASA, F5 and vSphere; Terraform for AWS and Azure, and a MaaS pipeline for bare metal. A network change is entered in Git instead of logged into six devices.
• Netbox as the single source of truth about the infrastructure itself — what exists, where, and how it's connected — integrated with vCenter and iLO, with an Ansible dynamic inventory wired to Git. An inventory that gets used when a machine is built, not a dead CMDB.
• Secrets out of the code — IaC without secrets management means credentials in a repository, and it is the most common real finding. A central store, Vault or the tool you already run, wired into the pipeline.
• Handover is the environment, the templates, a documented approval flow and a team that can work in the code.

Automation Maintenance & On-Demand

Automation isn't a project that finishes. It dies when nobody maintains it and the team quietly goes back to clicking.

• Drift tracked and returned to the code — what has diverged from Git, and why — plus maintenance of playbooks and templates as the estate moves under them: new vSphere, switch, operating system and image versions.
• Coverage extended class of device by class of device, starting where the volume of change is highest, and day-one and day-two configuration (hostname, NTP, user management, RADIUS).
• Troubleshooting for the pipeline and provisioning, and on-demand consulting blocks. Typically part of a wider support arrangement rather than a standalone line item.

Enablement inside the build

The goal is that your team owns the code after we leave — not that they sit through a course.

• Your admins work on the code alongside us and take it over during delivery.
• Deep dives on Git and Ansible and a lab environment on request, run inside the engagement.
• We don't sell this as a standalone automation course. Enablement lives inside the build, where the code is real.