Bare Metal Should Be Programmable

Why automation should begin at the hardware layer, not above it

When organizations talk about infrastructure automation, the conversation usually starts with the cloud, containers, orchestration, or CI/CD. But there is another layer underneath all of it: the physical infrastructure. And too often, that layer is still managed manually. An engineer walks up to a server. A technician plugs in a USB drive. Someone installs an operating system, configures the machine, loads the required applications, and prepares it for its intended purpose. 

For one system, that may not seem like a major problem. At enterprise scale, it becomes one. 

That is why I believe bare metal deployment should be treated as part of an organization’s automation strategy, not simply as an installation process. 

The Goal Is to Remove the Manual Step

At its simplest, bare metal deployment allows an organization to provision a physical machine without requiring an engineer to physically interact with that machine. Instead of traveling to a data center, manually installing an operating system, and configuring each server or workstation individually, the process can be automated. A task that may otherwise take hours or even days can potentially be reduced dramatically when the environment is designed correctly. 

That is especially important for distributed organizations. 

Earlier in my career, I worked for a managed service provider supporting customers across the United States. We had a relatively small team supporting a geographically dispersed customer base. Being able to remotely provision and rebuild systems meant we did not need to physically travel to every location simply to reinstall a workstation or prepare a machine. 

The value was immediate. 

But the bigger benefit was repeatability. 

Automation Creates Standardization

Speed is important, but standardization may be even more important. 

If an engineer manually configures every workstation or server, each deployment creates another opportunity for variation. Automation allows you to define what a system should look like and repeatedly deploy that configuration. If a workstation is intended for a particular type of user, the applications and configuration that user requires can already be part of the deployment process. If a server requires a particular base configuration, that can be standardized as well. 

The engineer is no longer spending hours performing the same installation and configuration steps over and over. 

The environment handles them. That becomes especially valuable in large enterprises and environments where systems are frequently deployed, rebuilt, reimaged, or repurposed. 

We Have Come a Long Way From Golden Images

Bare metal deployment itself is not new. 

Historically, organizations often relied heavily on technologies such as disk imaging and golden images. 

Those approaches worked, but they came with limitations. 

Images require storage. They can become tied to particular hardware configurations. A large image created for one system may not translate cleanly to another machine with different storage characteristics. 

Modern deployment methods provide much more flexibility. 

Tools such as Kickstart in the Linux ecosystem allow an engineer to dynamically define how a machine should be configured during installation instead of simply copying a static image. 

You can define partitions based on the available hardware, determine how storage should be allocated, establish system configurations, and then layer additional automation on top of that deployment. 

The result is a more portable and adaptable approach. 

There are still challenges. 

Different operating systems have different deployment ecosystems. What works in a Red Hat environment is not necessarily the same process you would use for Ubuntu or Windows. There is no single universal method that makes every platform behave identically. But the underlying principle remains the same: the deployment of physical infrastructure can and should be automated. 

Bare Metal Can Become a Programmable Resource

This is where I think bare metal becomes particularly interesting. 

When a PXE environment is designed correctly, you can do more than simply automate the installation of an operating system. You can begin changing how the physical compute resource itself is used. Technologies such as iPXE support network storage protocols including AoE SAN, iSCSI, and FCoE. That creates the ability for a server to boot from storage delivered across the network rather than relying entirely on a locally installed disk. 

That means you can create a diskless server that boots programmatically into an environment. 

Conceptually, you begin gaining some of the flexibility that engineers normally associate with virtual machines, except you are doing it with a bare metal node. Lightweight Linux distributions can extend that idea even further. An environment such as Alpine Linux can be booted into a fully functional operating system while maintaining a high degree of portability. 

Now the physical server is no longer just a static box with one operating system permanently installed on it. It becomes a resource that can be programmatically provisioned for a particular purpose. 

That is a very different way of thinking about bare metal. 

In my own homelab, I have experimented with some of these concepts. In my experience, I have not encountered a commercial platform that fully packages this level of programmable, diskless bare metal capability into a complete solution. That does not mean such products do not exist. It means there is still a lot of room for engineers and organizations to explore what is possible at this layer of the infrastructure. 

Automation Should Start at the Bottom of the Stack

Cloud environments already demonstrate what infrastructure can look like when compute resources are treated programmatically. 

Organizations should apply the same thinking further down the stack. 

DevSecOps, Kubernetes, cloud-native architectures, and highly automated application environments all depend on the idea that infrastructure can be deployed consistently and predictably. 

There is no reason that philosophy should stop when you reach the physical hardware. 

The bare metal layer should be part of the automation strategy. 

Architecture Matters More Than the Tool

Organizations interested in bare metal automation should not begin by asking only, “Which product should we buy?”. They should start with architecture. 

There are free and open-source tools that can provide powerful capabilities, but they may require engineers with the experience to design and maintain the environment. There are also commercial platforms that can simplify portions of the process but introduce additional licensing and long-term costs. Neither approach is automatically correct. 

The important question is how the organization wants the environment to operate over time. 

My preference is to invest in skilled engineers and design the architecture correctly from the beginning. One week spent building the right automation can eliminate hundreds of repetitive manual tasks later. 

That is the real value. 

Bare metal deployment is not just about installing an operating system faster. 

It is about creating repeatable infrastructure, reducing unnecessary engineering effort, and making physical compute resources behave more like the programmable infrastructure we have come to expect everywhere else. 

Bare metal should not be the manual layer underneath automation. 

Bare metal itself should be programmable.

About the Author

Kerley is a DevSecOps Engineer at DeNOVO Solutions with a strong focus on automation, bare metal deployment, and scalable infrastructure design. His experience includes designing and implementing automated deployment environments that reduce manual engineering effort, improve standardization, and support distributed enterprise operations. 

Kerley is particularly interested in pushing automation further down the technology stack, including the use of PXE, iPXE, network booting, and lightweight operating environments to make physical infrastructure more programmable. 

Editorial Note

This article was developed from an interview with Kerley and additional written input he provided following the discussion. The article was drafted by DeNOVO Solutions to reflect Kerley’s technical perspective and was reviewed by him for accuracy and alignment with his views.