OpenStack on bare metal
A machine here arrives with a Linux distribution, root, and a console that works when the network does not. OpenStack is not one of the images we install, so the control plane is yours to deploy and yours to operate. This page is what the hardware and the network will and will not do underneath it, written down before you order rather than discovered afterwards.
Thirty-three images go on a blade at build time: Ubuntu up to 26.04, Debian up to 13, AlmaLinux 8, 9 and 10, Windows Server up to 2025, VMware vSphere Hypervisor 7 and 8, and Proxmox VE 9. OpenStack has never been one of them and is not on the order form. That is not a gap we are apologising for. OpenStack is a deployment, not an image: the version, the services, the network driver and the storage backend are decisions about your cloud, and a vendor who made them for you at install time would have made them wrong.
So the sequence is: choose a distribution the deployment tool supports, take root over SSH about half an hour after the order clears, and run Kolla-Ansible, OpenStack-Ansible or your own playbooks against it. Kolla-Ansible's support matrix names Debian 13, Rocky Linux 10 and Ubuntu 24.04. We install two of those three. Rocky Linux 10 is not an image here, so a Kolla deployment on our hardware is a Debian or an Ubuntu one.
Nobody at Server Room is on call for a broken agent or a failed upgrade. Support is 24/7 for the machine, the disks and the network, and the line is drawn there. Better to read that on the page than to find it during an outage.
The installation guide's example architecture gives the controller and every compute node a minimum of two network interfaces. Every machine we sell has one connected port. There is no second-port product, no private VLAN and no cross-connect in the catalogue, so the second interface has to be made on the host in software, and management, API and tunnel traffic share the wire with instance traffic. Kolla-Ansible's quick start asks for two interfaces, 8 GB of memory and 40 GB of disk per host; the memory and the disk are trivial here and the interface is the one to plan around.
That is the sentence to read twice before ordering. If your design needs an isolated storage network or a management plane that instance traffic cannot see, this hardware will not give it to you, and finding that out now costs nothing.
The ProLiant blade lines put their drives behind an embedded disk controller, so the operating system sees one logical volume and a RAID 1 pair is what you get. That suits a controller and it suits Cinder on LVM. It does not suit Ceph: the project asks for whole devices, and a controller that hides them behind a logical drive is the arrangement every Ceph and ZFS document tells you to avoid.
The NVMe cartridge lines are the answer to that. The m510 and the m710x carry no RAID card at all, so their disks arrive raw and an OSD gets the device it wants. They are also small, which is the honest shape of a first Ceph cluster: three cartridges cost less than one blade and teach you more.
Nothing below is a bundle and none of it is stock. Every line is built to the specification you pick and priced by the configurator, which is the only place a total is authoritative.
| Role | Lines | What decides it |
|---|---|---|
| Controller, or a single all-in-one | D104, D105 | 32 GB up to a terabyte, a mirrored SSD pair behind the disk controller, and an out-of-band console. The all-in-one case wants the memory rather than the cores. |
| Compute | D105, D157, D158 | Instances are bounded by memory long before cores. Two sockets reach a terabyte; the four-socket lines reach a terabyte and two terabytes, and cost nothing per socket to virtualise because you are not licensing a hypervisor. |
| Ceph OSD | m510, m710x | NVMe with no RAID controller in front of it, which is what Ceph asks for. Both carry a console. Start with three. |
| A laboratory you can break | m710x | One cartridge, 32 or 64 GB, NVMe, a console, and a reinstall button in the panel. DevStack on a machine nobody else is on, for the price of a large virtual server. |
Cities differ by line. The D104, D105, D157, m510 and m710x are in all five: New York, Miami, San Francisco, Amsterdam and Bucharest. The D158 is in New York, San Francisco and Bucharest. Put the nodes of one cloud in one city; the tunnels are not built for a hop across an ocean.
An OpenStack deployment takes the host's networking apart and puts it back together differently, and the step that gets it wrong takes the machine off the network with it. The blade lines and the m510 and m710x cartridges carry an out-of-band console, reached from the control panel, which means a bad bridge is a console session rather than a support ticket. The small cartridges, the m300, m700, m710 and m710p, have power control and nothing else, so the same mistake there is a reinstall. Reinstalling is self-service, unlimited, and takes about as long as the first build.
The rest of the arrangement is the same as any dedicated machine here. Failed hardware is replaced within four hours under the service agreement, fifteen consecutive minutes of network unavailability earns a credit, billing is monthly with no contract, and paying three, six or twelve months ahead takes 5%, 10% or 15% off. There is no setup fee on any line above.
2026.1 Gazpacho is the current coordinated release, published on 1 April 2026, and it is a SLURP release, so an upgrade may skip to it directly from 2025.1 Epoxy rather than passing through 2025.2 Flamingo. Both of the distributions we install carry packages new enough to deploy it, and the containerised deployments do not care what the host ships as long as the host is on the support matrix.
The project's own installation guide says it is a learning document rather than a production reference, which is the correct warning. What people put in production here is Kolla-Ansible or OpenStack-Ansible, and both want the same thing from us: a clean distribution, root, and addresses that behave.
No. We build the machine, install the distribution you chose, and hand over root and the console. Everything above that is yours. If you would rather buy the deployment than build it, hire an OpenStack integrator and rent the hardware here; that combination works and we are happy to be the second half of it.
No. There is no VLAN, no second port and no cross-connect to buy, so every node has one public port and one address on it, and the management, tunnel and storage traffic all cross that port. Encrypt what matters, use the host firewall to keep the API and the database endpoints closed to everything but your own addresses, and treat a design that assumes an isolated back plane as a design for other hardware.
Extra IPv4 addresses come from the same /24 as the machine's primary and arrive on the same port, so Neutron can hand one to an instance directly or route a whole tenant behind the host. The ladder is two for $6 a month, four for $18, six for $30 and eight for $42 on the Scalable and four-socket lines; the entry blade goes to four and the NVMe cartridges to two. Beyond that, instances live behind NAT on the host, which is what most people do anyway.
On the cartridge lines, yes. The m510 and m710x have no RAID controller, so an OSD gets the raw NVMe device Ceph expects. On the ProLiant blades the disks sit behind an embedded controller as one logical volume, which is the arrangement Ceph's own documentation tells you not to use, so those are the wrong machines for storage and the right ones for everything else. Three cartridges is the smallest cluster worth having.
One, if you are learning: an all-in-one on a single machine is a real OpenStack and it fails in all the interesting ways. Three is where it becomes an environment somebody else can depend on, with the control plane on its own machine and two compute nodes beside it. There is no minimum order and no bundle, so start with one and add the next when the first proves the design.
On the blades and on the m510 and m710x you open the out-of-band console from the control panel and fix it, exactly as you would in front of the rack. On the m300, m700, m710 and m710p there is power control and no console, so the recovery is a reinstall, which is self-service, unlimited and takes about as long as the original build. Order a line with a console if the machine is going to be experimented on.
Whichever you deploy. 2026.1 Gazpacho is the current release, dated 1 April 2026, and it is a SLURP release, so you can skip to it from 2025.1 Epoxy in one upgrade. Nothing in our build pins you to a version, and reinstalling the host is a button rather than a request.
Yes. It is your hardware, your hypervisor and your cloud. Windows guests need your own licences, as they would anywhere. If the arithmetic against renting from a hyperscaler is the question, that comparison has its own page.
A racked machine is live about 30 minutes after the order is approved, and a build to order takes 4 to 24 hours. Billing is monthly, there is no contract and no minimum term, and cancelling from the control panel ends the service at the close of the billing month.
