Manual server management does not scale. Each new physical server needs an operating system, network settings, and access keys, and configuring each one by hand takes time and is prone to errors. Over time, servers that should be identical end up with different settings.
With automation, administrators move those steps into code and apply them the same way every time. phoenixNAP's Bare Metal Cloud (BMC) supports server provisioning and management through APIs, so developers deploy and configure dedicated servers with the same tools they use for cloud resources.
This article presents 12 GitHub repositories for automating Bare Metal Cloud server management, from infrastructure-as-code tools to container orchestration integrations and CI/CD workflows.
Why Automate Server Management?
Server management includes every task in a server's lifecycle, from provisioning and configuration to deprovisioning. When a system administrator performs these tasks manually in a web portal, the outcome depends on applying the correct settings in the correct order every time.
Server automation involves replacing manual steps with code. Administrators define the required server settings in a configuration file or script, and an automation tool applies them through the provider's API. As a result, every deployment produces an identical server.
Automated server management provides the following benefits:
- Speed. Servers deploy with a single command or pipeline run instead of a sequence of manual steps.
- Consistency. Servers built from the same code have identical settings, which prevents configuration drift (unplanned differences in settings between servers).
- Version control. Infrastructure code is stored in a Git repository, where every change is reviewed, tracked, and reversible.
- Scalability. Deploying ten servers takes the same effort as deploying one, since only a value in the code changes.
- Short-lived environments. Test environments are created when a build needs them and removed after testing.
Infrastructure automation depends on platforms that expose their functions through an API. With full API access, organizations manage physical servers the same way they manage virtual machines in the cloud.
Note: phoenixNAP's Bare Metal Cloud is a dedicated server with the flexibility of the cloud. Servers deploy in minutes and scale up or down as business requirements change, with flexible billing models for both short-term and long-term needs. The Bare Metal Cloud API exposes server provisioning and management functions, making BMC fully automatable with the repositories below.
12 GitHub Repos to Automate BMC Server Management
phoenixNAP publishes its BMC integrations as open-source projects on GitHub. The developer portal lists the official BMC automation tools, while newer projects are available directly in the phoenixNAP GitHub account. The repositories fall into the following categories:
- Infrastructure as code (IaC) and configuration management. These tools define servers and their settings in code files, and phoenixNAP's IaC integrations connect them to BMC.
- Command-line and API tools. These tools send requests to the BMC API from a terminal, a script, or application code built with software development kits (SDKs).
- Kubernetes integrations. These components let a Kubernetes cluster create and manage BMC servers, bringing dedicated servers to Kubernetes use cases such as microservices and big data processing.
- CI/CD and demo scripts. These resources add BMC servers to GitHub workflows and show complete cluster deployments in Python.
All repositories authenticate with the same pair of credentials, a client ID and a client secret created under API Credentials in the BMC portal.
The following table lists each repository, its category, and its main use:
| Repository | Category | Best For |
| Terraform Provider | IaC. | Declarative server and network provisioning. |
| Pulumi Provider | IaC. | Provisioning with general-purpose programming languages. |
| Ansible Collection | Configuration management. | Playbook-based provisioning and configuration. |
| Chef Knife Plugin | Configuration management. | Server management from existing Chef workflows. |
| pnapctl | Command-line tool. | Server management from the terminal or shell scripts. |
| BMC SDKs | API tool. | Custom tools in Go, Python, or Ruby. |
| Postman Collection | API tool. | API testing without code. |
| Kubernetes Controller | Kubernetes integration. | BMC servers as Kubernetes resources. |
| Cluster API Provider | Kubernetes integration. | Kubernetes cluster creation and upgrades on BMC. |
| Kubernetes Cloud Provider | Kubernetes integration. | Load balancer services for Kubernetes on BMC. |
| GitHub Actions | CI/CD. | Server creation and deletion in GitHub workflows. |
| Demo Scripts | Sample automation. | Kubernetes and Spark cluster deployments in Python. |
1. Terraform Provider for BMC
The Terraform provider for BMC, named pnap, connects Terraform to Bare Metal Cloud. Terraform is an infrastructure-as-code tool that uses plugins called providers to manage resources across different platforms. The pnap provider is a verified provider in the Terraform Registry, so Terraform downloads it automatically during initialization. The provider manages BMC servers along with SSH keys, networks, and IP blocks. Developers can define a complete BMC environment in a single Terraform configuration file and use the same file to recreate that environment at any time.
2. Pulumi Provider for BMC
The Pulumi provider for BMC adds Bare Metal Cloud resources to Pulumi. Pulumi is an infrastructure-as-code platform that uses general-purpose programming languages instead of a dedicated configuration language. Developers define servers and networks in a language they already know and deploy them with the Pulumi command-line interface (CLI).
phoenixNAP publishes the provider through the standard package manager for each supported language:
- JavaScript and TypeScript. Installed from npm as pulumi-pnap.
- Python. Installed from Python Package Index (PyPI) as pulumi-pnap.
- Go. Installed with
go getfrom the provider's GitHub repository.
Pulumi programs support loops, functions, and unit tests, making Pulumi a good fit for deployments that need logic, such as varying the number of servers by environment.
3. Ansible Collection for BMC
The Ansible collection for BMC, published as phoenixnap.bmc, contains modules that create, manage, and delete Bare Metal Cloud resources. Ansible runs these modules through playbooks, which describe automation tasks in YAML, a plain-text format that is easy to read.
The collection is certified by Red Hat and available on Red Hat Ansible Automation Hub and Ansible Galaxy. Besides Ansible, the BMC Ansible module requires only the Python requests library. The modules call the BMC API directly, so playbooks do not need SSH access to create servers. After deployment, administrators can use the same playbooks to install software and configure the operating system, covering both provisioning and configuration with one tool.
4. Chef Knife Plugin for BMC
The Chef Knife plugin for BMC adds Bare Metal Cloud commands to Knife, the command-line tool of the Chef configuration management platform. The plugin is distributed as knife-bmc, a Ruby gem (a packaged Ruby library). After installation, Knife gains a knife bmc command group. Administrators use it to create, list, and delete servers, run power actions such as reboot and shutdown, and manage the SSH keys used to access servers. Organizations that already use Chef to manage configuration can provision BMC servers with the same tool.
5. BMC Command-Line Interface (pnapctl)
pnapctl is the official CLI for Bare Metal Cloud. It deploys new servers and manages existing ones from the terminal, with commands such as pnapctl get servers.
The CLI runs on Linux, macOS, and Windows AMD64 systems and works both in interactive sessions and inside automation scripts. phoenixNAP also publishes pnapctl as a Docker image on the GitHub Container Registry, so the CLI runs without a local installation.
For simple, repeatable tasks, such as deploying a test server or checking server status, administrators can call pnapctl from shell scripts instead of setting up a full infrastructure-as-code tool.
6. BMC SDKs for Go, Python, and Ruby
SDKs let developers call the BMC APIs from application code without writing HTTP requests by hand. phoenixNAP generates its SDKs from the API specifications, and each SDK has a separate module for every BMC API, from server management to networking and billing.
Three SDKs are available:
- Go SDK. Provides a Go module for each BMC API and authenticates through the standard OAuth 2.0 client credentials flow.
- Python SDK. Provides a Python package for each BMC API, installable from PyPI with
pip. - Ruby SDK. Provides a Ruby gem for each BMC API.
Developers use the SDKs to build custom tools, such as internal dashboards, scheduled maintenance jobs, or integrations with ticketing systems. phoenixNAP's own pnapctl is built on the Go SDK.
7. Postman Collection for BMC APIs
The Postman collection for BMC contains ready-made requests for the BMC APIs. Postman is an API platform for building, sending, and testing HTTP requests through a graphical interface, so the collection lets developers try API calls before writing any code.
Developers install Postman or use its web version, import the collection, and add their client ID and client secret as environment variables. The requests cover the main BMC APIs, from server status to billing information. phoenixNAP updates the collection on GitHub with every API change, so the requests match the current API documentation. Requests that create servers deploy real, billable resources, so each test session must end with a cleanup request.
8. Kubernetes Controller for BMC
The Kubernetes controller for BMC lets developers define, deploy, and manage Bare Metal Cloud servers from a Kubernetes cluster. It combines a custom resource definition (CRD), which adds a BMC server object type to the Kubernetes API, with a controller that creates and updates servers to match those objects.
With the controller installed, a BMC server becomes a Kubernetes resource defined in a YAML manifest and managed with kubectl. Organizations that already run applications on Kubernetes manage the underlying servers with the same Kubernetes tools and workflow. The controller reads its BMC credentials from a Kubernetes secret.
9. Cluster API Provider for BMC
The Cluster API provider for BMC implements Cluster API, a Kubernetes project for creating, upgrading, and operating clusters declaratively. With the provider, an existing management cluster (a Kubernetes cluster that manages other clusters) provisions Bare Metal Cloud servers and turns them into new Kubernetes clusters. Developers set up the provider with clusterctl, the Cluster API command-line tool. In the configuration, they specify the server types for control plane and worker nodes, the deployment location, and optionally kube-vip, a tool that keeps the control plane highly available through a shared virtual IP address. Since the cluster is defined as Kubernetes objects, adding worker nodes or upgrading the Kubernetes version requires only a configuration change.
10. Kubernetes Cloud Controller Manager for BMC
The Kubernetes cloud provider for BMC is phoenixNAP's implementation of the Kubernetes cloud controller manager (CCM). The CCM is the component that connects a cluster to the infrastructure it runs on, and it keeps each Kubernetes node matched to its BMC server.
The CCM also provides load balancers for Kubernetes services of type LoadBalancer. When such a service is created, the CCM requests a public IP block through the BMC API and assigns an address from it to the service, while kube-vip announces that address on the network. When the service is deleted, the CCM releases the IP block. The CCM supports Kubernetes 1.20 and later.
11. GitHub Actions for BMC
The GitHub Actions for BMC bring Bare Metal Cloud server management into GitHub workflows and make BMC part of a CI/CD pipeline. GitHub Actions is the automation platform built into GitHub, and it runs jobs in response to repository events, such as a push or a pull request.
phoenixNAP provides three BMC GitHub actions that work alongside any other action in a workflow:
- Create Server. Deploys a new BMC server with the specified hostname, server type, location, and operating system.
- Delete Server. Deletes an existing BMC server.
- Get Server. Retrieves basic information about a BMC server.
A typical workflow creates a server, runs tests on it, and deletes it when the tests finish, so test servers exist only for the duration of the job. Steps that follow the create action must first check that the server has finished provisioning.
12. Demo Automation Scripts
phoenixNAP's demo scripts use Python and direct BMC API calls to deploy complete environments on Bare Metal Cloud. Each script creates three Ubuntu servers, waits until provisioning finishes, and installs the required software.
Two demo scripts are available:
- Kubernetes cluster script. Installs a Kubernetes cluster with one master and two worker nodes and deploys WordPress as a sample application.
- Apache Spark cluster script. Automates the deployment of a Spark cluster with one master and two worker nodes and returns a link to the Spark dashboard.
The scripts are examples rather than production tools. Their code shows every API call behind a cluster deployment, making it a useful reference for building similar workflows with the SDKs or pnapctl.
From Repository to Running Server
Bare Metal Cloud works with the infrastructure-as-code, Kubernetes, and CI/CD tools many organizations already use, so physical servers fit into existing automation workflows. Start by creating API credentials in the BMC portal, choose a repository from the phoenixNAP GitHub account, and deploy your first server from code. To follow new releases and ask the BMC developers questions, join the Bare Metal Cloud Slack community and subscribe to the Developers’ Monthly newsletter.
