How to Run Bare Metal Servers That Boot Entirely From Memory

Most bare metal servers carry state they shouldn’t. An OS installed to disk months ago, a few manual package installs, a config file someone edited during an incident. OpenMetal’s July 2026 release added ramdisk deployment configurations, which let a bare metal node boot its operating system directly into memory from a kernel and initramfs you provide. Nothing the running OS writes to its root filesystem survives a power cycle, and every node built from the same configuration starts from the same image.

Here’s the problem this solves: Say you run a fleet of Kubernetes workers or CI runners on dedicated hardware. You want every node identical. You want a bad node fixed by rebuilding it from a known image, not by SSHing in and repairing it. And you want to roll out a new OS version by changing one URL, not by reimaging servers one at a time.

On public cloud, you get most of this from golden images and autoscaling groups. On traditional dedicated servers, you usually don’t. The OS lives on the local disk, and drift starts the day the server goes live.

Ramdisk boot changes that for bare metal on OpenMetal. Below is how it works, what the image needs, and where it makes sense (and where it doesn’t).

What Changed In OpenMetal Central

OpenMetal Central has supported custom deployment configurations since the February 2026 release. A deployment configuration is a reusable template made of a custom OS image and a cloud-init script. You select it when provisioning new servers through checkout or when adding hardware to an existing cluster, so every server you order gets the same starting point.

The July 2026 release added a second deployment mode. Instead of writing an image to disk, a configuration can now specify a kernel URL and an initramfs URL. The node loads the OS into memory and then contacts a new internal metadata service at 169.254.169.254 to pull its cloud-init configuration.

According to the OpenMetal API documentation, configurations support two mutually exclusive modes:

The API docs are explicit that ramdisk deployments boot the OS entirely from memory and that no disk writes occur during deployment. Cloud-init user data can be combined with either mode.

One detail worth knowing up front: the docs note that ramdisk boot ISO deployments are not currently available. Ramdisk mode today means a kernel plus an initramfs.

How A Ramdisk Boot Works On OpenMetal

The flow has three parts: the image you host, the boot itself, and the configuration step after boot.

The Image You Host

You build a Linux kernel and an initramfs and host them at URLs the provisioning system can reach. The initramfs is the root filesystem your node will run from.

If you haven’t worked with initramfs directly, the Linux kernel documentation describes it as a compressed cpio archive that the kernel extracts into rootfs at boot. If the archive contains an init program, the kernel runs it as PID 1, and that process is responsible for bringing the rest of the system up. In a ramdisk deployment, the system never needs to hand off to a root filesystem on disk. It runs from memory for its whole lifetime.

The Boot

When a node is provisioned with a ramdisk configuration, it loads your kernel and initramfs and boots from them. Because the OS isn’t written to the disk, the local NVMe drives in the server are left alone by the deployment. They’re still physically there, and you can mount and use them for data, scratch space, or caches from inside your OS.

Configuration After Boot

A freshly booted ramdisk image doesn’t know its hostname, its network settings, or which SSH keys to trust. That’s what the Node Metadata service is for.

The API documentation describes it as an OpenStack-compatible metadata service at http://169.254.169.254 that serves cloud-init configuration to bare metal nodes over HTTP.

“OpenStack-compatible” refers to the data format, not the platform. Your ramdisk-booted server is a standalone bare metal node, and OpenStack isn’t running on it or managing it. The metadata service simply serves files in the same layout OpenStack made standard, because cloud-init already knows how to read that layout. Reusing a format cloud-init understands means your image doesn’t need a custom agent to configure itself.

A few properties matter for security and design:

• It’s reachable only from the node itself, at the link-local address. It isn’t routable from the public internet.
• No authentication is required. The service identifies the node by the source IP of the request.
• It serves files in the OpenStack metadata layout that cloud-init already supports: meta_data.json, network_data.json, user_data, vendor_data.json, and vendor_data2.json.

Here’s what each file does, per the OpenMetal docs:

• meta_data.json returns instance metadata, including a uuid that cloud-init uses as the instance identity for first-boot detection, plus hostname and public keys.
• network_data.json returns network configuration in OpenStack format, passed through from the node’s stored network configuration. Cloud-init renders it using the ramdisk’s configured network renderer, which the docs identify as systemd-networkd.
• user_data returns whatever user data you set in the deployment configuration, or a 404 if you didn’t set any.
• vendor_data.json and vendor_data2.json return vendor data, with settings in the second file overriding the first.

What Your Ramdisk Image Needs

This is the part that trips people up, so it’s worth being precise.

Cloud-init reads its configuration through “datasources,” which are named after the metadata format they understand. Because OpenMetal’s metadata service uses the OpenStack format, your image uses cloud-init’s OpenStack datasource, even though the server itself is plain bare metal.

Normally cloud-init picks a datasource automatically by reading hardware identifiers. On a physical server, those identifiers don’t point to any cloud platform, so auto-detection fails. The cloud-init documentation for the OpenStack datasource covers the datasource settings and notes that bare metal needs the datasource set explicitly.

OpenMetal’s API documentation spells out what that configuration looks like. Your ramdisk image must force the OpenStack datasource by including this file at /etc/cloud/cloud.cfg.d/99-datasource.cfg:

datasource_list: [OpenStack]
datasource:
  OpenStack:
    metadata_urls: ["http://169.254.169.254"]
    max_wait: 120
    timeout: 10
    retries: 5
    apply_network_config: true

Three settings are called out specifically:

• datasource_list: [OpenStack] is required. It forces the OpenStack datasource because hardware-based auto-detection won’t work on bare metal.
• max_wait: 120 is required. The cloud-init default makes only a single probe. Setting it to 120 seconds gives cloud-init time to retry if the metadata service isn’t reachable the instant the node comes up.
• apply_network_config: true is recommended. It tells cloud-init to configure networking from network_data.json.

If you skip this file, the most likely outcome is a node that boots into memory and then sits there unconfigured, because cloud-init never found its datasource. Bake the file into your initramfs build and you avoid that entire class of problem.

Kernel Arguments

Ramdisk configurations can also carry kernel_args, which are extra kernel command-line parameters appended to the platform defaults at boot. The docs give console=ttyS0,115200n8 as an example.

The platform prepends a %default% token so its own defaults are preserved. If your value already contains %default%, it’s passed through as written, which lets you control where your arguments land relative to the defaults. The documented constraints:

• Only valid on ramdisk configurations (kernel plus initramfs)
• Can’t contain newline or carriage return characters
• Can’t be empty or whitespace-only when set
• 1,024 characters maximum

Creating A Ramdisk Configuration

You can create deployment configurations in Central or through the OpenMetal API. Through the API, it’s a single POST to /v1/configurations. A ramdisk configuration with kernel arguments and a small cloud-init payload looks like this:

{
  "label": "k8s-worker-ramdisk",
  "description": "Stateless worker image, boots to memory",
  "fields": {
    "image_ramdisk_kernel": "https://images.example.com/worker/vmlinuz",
    "image_ramdisk_ramdisk": "https://images.example.com/worker/initramfs.img",
    "kernel_args": "console=ttyS0,115200n8",
    "cloud_init": {
      "data": "{\"packages\":[\"htop\"],\"runcmd\":[\"/usr/local/bin/join-cluster.sh\"]}"
    }
  }
}

The image URLs and the join script here are placeholders. Swap in your own.

Once the configuration exists, you reference its ID in the deployment_configuration field when you order bare metal, either through the checkout flow in Central or through a POST /v1/orders call. The same configuration can be used when adding hardware to an existing bare metal cluster, which is what makes it useful for fleets: new nodes join with exactly the same image as the ones already running.

Updating is also straightforward. The API supports PATCH on a configuration and merges only the fields you send, so pointing a configuration at a new initramfs URL is a one-field change.

Switching Existing Nodes

The February release added a Reprovision tool in Central that reinstalls a node already assigned to your cluster. You can choose an alternate operating system or deployment configuration without replacing the physical hardware. That’s the path for moving an existing node to a different deployment configuration, or rolling it forward to a newer image, without placing a new order.

Where Ramdisk Boot Fits

Booting from memory is a design choice with real tradeoffs. Here’s where it earns its place.

Immutable Kubernetes Worker Nodes

Kubernetes workers are a natural match. The node’s job is to run the kubelet and container runtime, join the cluster, and pull workloads. Nothing on the OS disk should be precious. If a worker misbehaves, you replace or reprovision it from the known-good configuration instead of debugging drift. Rolling out a new worker OS means updating the configuration’s image URLs and reprovisioning nodes in batches.

This pairs well with OpenMetal’s Kubernetes workload infrastructure, where dedicated hardware gives you full cores and predictable network performance without a hypervisor layer in between. Persistent volumes should live on storage designed for persistence, such as Ceph block storage or the node’s local NVMe mounted deliberately, not on the root filesystem.

One caution: some operating systems built specifically for immutable Kubernetes nodes use their own provisioning mechanisms rather than cloud-init. Check your OS documentation to confirm it can consume configuration from an OpenStack-style metadata service before building around it.

Ephemeral CI Runners

Self-hosted CI runners on dedicated hardware are a good cost fit for teams with steady build volume, which we covered in our article on optimizing CI/CD pipelines on an OpenStack-powered private cloud. The weak point of long-lived runners is contamination between jobs: leftover caches, credentials, and build artifacts from earlier runs.

With a ramdisk-booted runner, anything a job writes to the root filesystem lives in memory and is gone after a power cycle. Local NVMe can still serve as a fast build cache if you mount it on purpose, and you control exactly what persists.

Security-Sensitive Compute That Shouldn’t Keep an OS Disk

Some workloads process data that shouldn’t linger on an OS disk after the job finishes. With ramdisk deployment, the operating system itself isn’t written to disk during deployment, and runtime changes to the root filesystem live only in memory. You still need to control what your applications write to local drives, but the OS baseline doesn’t accumulate on disk.

This sits alongside the isolation OpenMetal already provides at the network layer. Every customer gets dedicated VLANs for both bare metal and private cloud, covered in detail in our network architecture explainer.

Fleet Consistency Across Regions

If you run bare metal in more than one OpenMetal location (Ashburn, Los Angeles, Amsterdam, or Singapore), a single deployment configuration pointing at the same kernel and initramfs gives you an identical OS baseline everywhere. For EU and APAC deployments where you’re building out a second or third footprint, that removes a common source of “works in one region, breaks in another” problems.

The Tradeoffs You Should Plan For

Ramdisk boot isn’t free. Be honest with yourself about these before you commit.

Memory Is Now Your Root Filesystem

Everything in the running OS lives in RAM. That includes the OS itself, plus anything written to the root filesystem at runtime, like logs, temp files, and container images if you store them on root. Every gigabyte there is a gigabyte your workloads can’t use.

This is where server sizing matters. OpenMetal’s current v5 lineup ranges from 256GB of DDR5-6400 on the Medium v5 to 512GB on the Large v5 and 1TB on the XL v5, per our hardware details page. A lean initramfs is a small share of that. A bloated one, or a root filesystem that fills with container layers, is not. The practical fix is to keep the image minimal and point high-volume writes (container storage, logs, caches) at local NVMe or network storage.

Nothing Persists Unless You Make It Persist

That’s the point, but it’s also the risk. Anything you forget to externalize disappears when the node loses power or restarts: log files you meant to keep, a certificate issued at runtime, a node-local database. Ship logs off the node. Store state in a real storage system. Test a full restart of a node regularly so you find missing state before an outage does.

Your Image Pipeline Becomes Critical Infrastructure

The kernel and initramfs URLs need to be reachable when nodes boot. If the host serving them is down, new nodes can’t provision from that configuration. Version your images, keep previous versions available so you can roll back by changing a URL, and put the image host somewhere reliable.

Debugging Looks Different

When a ramdisk node fails to configure, the usual culprit is cloud-init not finding its datasource. Check that 99-datasource.cfg is present in the image. The metadata service also exposes a root endpoint that simply returns latest, which the docs describe as a convenience for manual debugging with curl. From the node, a request to http://169.254.169.254/openstack/latest/ should return the list of available metadata files. If you can’t get a shell over the network, IPMI console sessions are available through Central and the API.

Who Ramdisk Boot Is For

A good fit if you:

• Run fleets of interchangeable nodes, like Kubernetes workers, CI runners, or batch compute
• Want to fix a bad node by rebuilding it from a known image rather than repairing it
• Already build images in a pipeline, or are ready to start
• Want OS rollouts to be a URL change instead of a reimaging project
• Need an identical OS baseline across multiple OpenMetal regions

Probably not the right fit if you:

• Run stateful services that expect a persistent root filesystem, like a traditional database server
• Need a large OS footprint that would eat into memory your workloads require
• Don’t have (or don’t want) an image build and hosting process
• Plan to run a hypervisor such as Proxmox VE, which expects a persistent install. Our guide to running Proxmox VE on OpenMetal bare metal covers that path instead.

The Short Version

A bare metal server that boots from memory gives you cloud-style immutability on dedicated hardware: runtime state never piles up on an OS disk, and every node in the fleet starts from the same image. The cost is RAM and discipline, and for fleets of interchangeable nodes, that trade is usually worth it.

If you want to test ramdisk deployments against your own image and workload, apply for a proof of concept or review bare metal pricing to size the servers. You can also talk with our team about your fleet design.

Frequently Asked Questions

What is a ramdisk deployment on OpenMetal?

A ramdisk deployment is a bare metal deployment configuration that loads the operating system into memory from a kernel and initramfs you provide, instead of writing an OS image to the server’s disk. According to OpenMetal’s API documentation, no disk writes occur during a ramdisk deployment.

How does a ramdisk-booted server get its configuration?

It uses cloud-init to query OpenMetal’s Node Metadata service at 169.254.169.254. The service provides instance metadata, network configuration, SSH public keys, user data, and vendor data in the OpenStack metadata format. It’s reachable only from the node itself and isn’t routable from the internet.

Why does my ramdisk image need a special cloud-init datasource file?

Cloud-init normally detects its platform from hardware identifiers, which doesn’t work on bare metal. OpenMetal’s documentation requires a file at /etc/cloud/cloud.cfg.d/99-datasource.cfg that forces the OpenStack datasource, points it at 169.254.169.254, and sets max_wait to 120 seconds so cloud-init retries if the service isn’t immediately reachable.

Can I still use the NVMe drives in a ramdisk-booted server?

Yes. The deployment doesn’t write the OS to disk, but the server’s NVMe drives are still installed. You can mount and use them from inside your OS for data, caches, or scratch space.

Can I switch an existing server between disk and ramdisk deployment?

OpenMetal Central’s Reprovision tool reinstalls a node already assigned to your cluster and lets you choose an alternate operating system or deployment configuration without replacing the hardware. That’s the path for moving an existing node to a different configuration, including one that uses a different deployment mode.

Are ramdisk boot ISOs supported?

Not currently. OpenMetal’s API documentation states that ramdisk boot ISO deployments aren’t available. Ramdisk mode uses a kernel plus an initramfs.

How much RAM does a ramdisk-booted server lose to the OS?

It depends on your image and on what gets written to the root filesystem at runtime. Everything in the running OS lives in memory, so a minimal initramfs uses little, while logs, temp files, or container images stored on root add up. Keeping the image lean and directing heavy writes to local NVMe or network storage keeps most of the server’s memory available for workloads.

Does ramdisk boot require OpenStack?

No. Ramdisk deployment is a bare metal feature, and OpenStack isn’t installed on or managing the server. OpenMetal’s metadata service uses the OpenStack metadata format because cloud-init already supports it, which is why the image config refers to the OpenStack datasource.