Automating Bare Metal Provisioning with APIs and CI/CD Pipelines

For many years, automated provisioning was a capability associated mostly with cloud infrastructure. Define resources in code, call provider APIs, and trigger infrastructure changes through automated workflows. No waiting and no manual clicks required. 

Bare metal has traditionally existed outside that loop. Provisioning a physical server has often meant a separate request process, longer deployment times, and a handoff between the DevOps team and the infrastructure team or service provider.

That gap is closing. As bare metal providers (like Rackdog) offer access to their infrastructure through APIs, the same automation patterns that power cloud-native CI/CD can be extended to physical servers.

For platform and DevOps teams already comfortable with automating the rest of their stack, this means bare metal can be incorporated into infrastructure-as-code and CI/CD workflows, no longer requiring a manual exception for dedicated compute.

Why automate bare metal provisioning?

Manual server provisioning creates friction in several ways. Request queues, ticket handoffs, and approval chains can lead to delays and bottlenecks. Repeating setup steps manually also makes infrastructure harder to reproduce consistently across environments.

Automating provisioning removes much of that friction. Instead of treating infrastructure requests as a separate manual process, teams can define provisioning logic in code and trigger it through infrastructure workflows or CI/CD pipelines when new capacity is needed.

Servers can then be requested the same way, every time, with infrastructure definitions stored in version control and reviewed alongside other changes. This makes provisioning more consistent, easier to audit, and easier to integrate with the rest of the deployment process.

Where APIs fit in infrastructure provisioning

Automating bare metal provisioning only works if the underlying infrastructure can be accessed programmatically. 

This is where an API comes in. The API connects your automation tooling to the provider’s infrastructure platform, allowing you to request servers, select available configurations and locations, install an operating system, and manage supported server lifecycle actions without relying on manual setup.

You can integrate with the API in one of two ways: 

1. Calling it directly from a script or pipeline

2. Using it indirectly through an infrastructure-as-code tool that provides a declarative configuration layer on top of the API.

In plain terms, the second approach means using a tool like Terraform or Pulumi to describe the infrastructure you want, rather than writing each API request yourself. The IaC tool then uses the provider’s API behind the scenes to create or change resources so they match that defined state.

Common approaches: IaC tools vs. direct API calls

Most teams take one of a few approaches to automating bare metal provisioning, depending on what they already use elsewhere in their infrastructure stack:

• Terraform: This is a declarative approach where infrastructure is defined in code. You use Terraform to create and manage server resources based on the configuration you define. Teams already using Terraform for cloud infrastructure can extend the same workflow to bare metal without introducing a separate provisioning process. Rackdog offers an official Terraform provider.

• Pulumi: Pulumi takes a similar infrastructure-as-code approach but lets teams define infrastructure using general-purpose programming languages such as TypeScript, Python, Go, and C#. Rackdog does not currently offer a native Pulumi provider, but Pulumi can use Terraform providers directly, which means teams can potentially use Rackdog’s Terraform provider from a Pulumi project.

• Direct API calls: Rather than using an infrastructure-as-code tool, teams can call the provisioning API directly from scripts, internal tooling, or pipeline jobs. This can be a good fit for simpler provisioning workflows or custom logic that does not map cleanly to a declarative configuration.

None of these options is inherently better than the others. The best fit depends on what your team is already using and how complex the provisioning logic is. 

Whichever approach you use, the provisioning logic can be stored in version control and reviewed like other code. For teams using pull requests, adding or changing a server can then go through the same review process as other infrastructure changes.

Example of using APIs to provision bare metal

Once provisioning is exposed through an API, requesting a physical server can become just another automated step. Instead of submitting a ticket or clicking through a portal, the workflow can send a request with the required server plan, location, and operating system.

A direct API call makes that process easy to see. At its simplest, a workflow might include a step like this:

curl --fail-with-body --silent --show-error \
  --request POST "https://metal.rackdog.com/v1/ordering/allocate" \
  --header "x-rd-key: ${RACKDOG_API_KEY}" \
  --header "Content-Type: application/json" \
  --data "{
    \"hostname\": \"app-node-${DEPLOYMENT_ID}\",
    \"planId\": ${PLAN_ID},
    \"locationId\": ${LOCATION_ID},
    \"osId\": ${OS_ID}
  }"

curl --fail-with-body --silent --show-error \
  --request POST "https://metal.rackdog.com/v1/ordering/allocate" \
  --header "x-rd-key: ${RACKDOG_API_KEY}" \
  --header "Content-Type: application/json" \
  --data "{
    \"hostname\": \"app-node-${DEPLOYMENT_ID}\",
    \"planId\": ${PLAN_ID},
    \"locationId\": ${LOCATION_ID},
    \"osId\": ${OS_ID}
  }"

curl --fail-with-body --silent --show-error \
  --request POST "https://metal.rackdog.com/v1/ordering/allocate" \
  --header "x-rd-key: ${RACKDOG_API_KEY}" \
  --header "Content-Type: application/json" \
  --data "{
    \"hostname\": \"app-node-${DEPLOYMENT_ID}\",
    \"planId\": ${PLAN_ID},
    \"locationId\": ${LOCATION_ID},
    \"osId\": ${OS_ID}
  }"

A step like this could be triggered from an infrastructure or CI/CD pipeline when new capacity is needed, allowing the workflow to request a server with the required plan, location, and operating system.

The exact implementation will vary depending on the tooling and workflow, but the underlying idea stays the same. 

By connecting a CI/CD pipeline or infrastructure automation workflow to a bare metal API, teams can automate server requests and make physical server provisioning faster, more consistent, and easier to repeat.

Getting started with automated bare metal provisioning

Whether your team is extending an existing Terraform setup or calling the API directly from a pipeline, the starting point is the same: identify which parts of the bare metal lifecycle you want to automate and how they fit into your existing infrastructure workflow.

Rackdog’s API and Terraform provider give teams a programmatic way to provision and manage dedicated servers without treating bare metal as a separate manual process. From there, those actions can be incorporated into the same infrastructure-as-code, CI/CD, and deployment workflows your team already uses.

Ready to automate your bare metal infrastructure? Create an account to start deploying, or get in touch with an infrastructure expert on our team to discuss the right bare metal solution for your needs.