DevOps, CI/CD and Infrastructure as Code for On-Prem and Hybrid Infrastructure

Most DevOps writing assumes a public cloud. On-prem and hybrid teams have the same goals with different building blocks: hypervisors such as Proxmox VE or VMware, bare-metal servers, physical networks, storage arrays and Kubernetes clusters they run themselves. The practice is the same. Write the desired state down as code, review it like application code, apply it through a pipeline, and keep production matching what is in Git.

Four layers usually emerge. Provisioning creates machines, networks and DNS records. Configuration management sets up what runs inside them. Delivery builds, tests and ships applications. A GitOps agent keeps Kubernetes in line with the repository. Teams that skip a layer tend to fill the gap with scripts that only one person understands.

The Infrastructure Automation Ledger scores infrastructure as code engines, the platforms that run them, configuration management and bare-metal provisioning tools on capability since 2015, credibility, commercial risk, lock-in and AI. These are the tools on-prem teams compare most often.

Source: Infrastructure Automation Ledger 2026. Scorecards: Spacelift, Red Hat Ansible Automation Platform, HashiCorp Terraform, Pulumi, Ansible, Crossplane, Puppet, OpenTofu, Semaphore UI, Chef, Salt.

Our verdicts. Red Hat Ansible Automation Platform has the highest capability score in this group, 76.6, and suits organisations that want supported Ansible with a controller, access control and audit. The free ansible-core engine scores 60.4 on the index and is enough for small teams, often with Semaphore UI or AWX as a front end. Spacelift tops the index at 69.0 because it adds policy, orchestration and self-service above the engines it runs. Puppet, Chef and Salt still manage large fleets, but their index scores of 57.0, 49.1 and 47.5 carry the highest commercial risk scores in this table, 17.5, 17.0 and 15.5 where lower is better.

Bare-metal fleets need a provisioning layer below all of this, because something has to install the operating system before Terraform or Ansible can reach the machine. On the Ledger's bare metal and day-2 operations domain, OpenStack Ironic scores 4.5 out of 5, and Canonical MAAS, The Foreman and Red Hat Satellite score 4 each. Pick the one that matches the distribution you standardise on: Satellite and The Foreman for RHEL estates, MAAS for Ubuntu, Ironic where OpenStack is already in place.

HashiCorp moved Terraform from the MPL to the Business Source License in August 2023. A group of vendors forked the last open source version as OpenTofu, which joined the Linux Foundation in September 2023 under the MPL 2.0. IBM completed its acquisition of HashiCorp in February 2025. Both tools read the same HCL and most providers work with either.

Our verdict: stay on Terraform if you use HCP Terraform or Terraform Enterprise, or depend on features that only exist there. Choose OpenTofu for new on-prem projects where an open source licence and a foundation governance model matter more than the managed service. Whichever you pick, keep state remote with locking, never commit it to Git, and run a plan step in the pipeline before every apply.

Proxmox VE exposes a REST API, so it fits the same pattern as a cloud. Terraform and OpenTofu create VMs and containers through community providers. The bpg/proxmox provider is published for both and states that it is not affiliated with Proxmox Server Solutions. Ansible then configures the nodes themselves and the guests on them. Cloud-init templates make new VMs come up ready for Ansible.

Teams leaving VMware often miss a self-service portal. The usual replacements are AWX or Ansible Automation Platform job templates, a CI pipeline that runs Terraform on merge, or a small internal form in front of the API. The Proxmox automation guide covers the options in more depth, and Windows guests built this way are covered in the Windows VMs hub.

GitOps keeps the desired state of a system in Git and lets an agent apply it. Argo CD and Flux are the two common agents for Kubernetes, and both graduated from the CNCF in late 2022. Argo CD suits teams that want a web interface and application views. Flux suits teams that prefer controllers driven entirely from Git. Plan for emergencies: an agent with automatic self-healing will revert a manual hotfix unless the fix also lands in Git or sync is paused on purpose.

A useful pipeline for infrastructure code has four steps: format and lint, plan, review, then apply from the pipeline instead of a laptop. For application delivery, one team on this site cut its pipeline from 58 to 14 minutes by tiering tests and fixing flaky ones, without new hardware. Zero-downtime deployment is possible without Kubernetes, using a load balancer, blue-green releases and careful database migrations. For running Kubernetes itself on your own hardware, see the On-Prem Kubernetes Ledger and the Kubernetes hub.

Platform engineering packages these tools into self-service. Developers request a VM, a namespace or a database through a form or a pull request, and the platform applies quotas, approvals and naming rules before automation runs. On-prem, that platform is usually Terraform or OpenTofu, Ansible, Kubernetes and a GitOps agent behind a portal or a Git workflow.

Automation also makes mistakes faster. Separate read-only actions from changes, require approval for anything destructive, scope credentials per pipeline, roll out to a canary first and keep a rollback that has been tested. Measure the result with toil, MTTR and SLO error budgets so the team can show the automation is paying off. Linux hosts under all of this have their own hub at Linux server administration.

Every post below covers DevOps, automation or delivery for self-run infrastructure, grouped by topic.