Direct Bare Metal access to GPU hardware

Configure Bare Metal access for an Ornn reservation to SSH directly into the GPU host with no virtualization overhead and no managed disk. Bare Metal access connects you directly to the physical GPU host, with no hypervisor, no managed VM, and no disk selection. You launch Bare Metal access from the reservation detail page, attach a registered SSH key, and connect over SSH once the host is ready.

When to use Bare Metal

Your workload is sensitive to virtualization overhead.
You need direct control over driver versions or kernel modules.
You’re running performance benchmarks or distributed training that benefits from bare physical networking.
You want to manage the full software stack yourself.

For most ML training and inference workloads, VM access is the simpler choice. Bare Metal is best when you need full hardware control.

Prerequisites

Before you can launch or switch to Bare Metal on a reservation:

You must hold a Confirmed or Active reservation from an accepted Reserve offer on a Bare Metal listing, visible in Nodes. Spot and relisted capacity are VM only.
You must have at least one active SSH public key registered on your account. Bare Metal does not use a VM disk, so the SSH key is the only credential pushed to the host.

If you have not registered a key yet, see Manage SSH keys for compute access. Reserved Bare Metal activation continues in the background after you request it. Wait for ready access details before connecting. If activation fails, customer access added during the attempt is removed and the reservation ends. Failed activation cleanup does not wipe the node’s disks. A reservation’s deployment date can record an administrative capacity assignment. It does not by itself confirm that the host is online or that SSH access is ready. Connect only once the host reports ready access details.

Set up Bare Metal access

Open the reservation detail page

From Nodes (/portfolio), click View on the reservation you want to configure. The detail page opens at /portfolio/[reservationId]. Access mode and state are managed here. The legacy /portfolio/access URL redirects to this page.

Select Bare Metal

Pick Bare Metal as the access mode. Bare Metal does not require a disk selection; you manage the OS and software stack directly. Refreshing node status or syncing SSH keys keeps your Bare Metal access mode and does not display a VM disk selector.

Add an SSH key and launch

In the SSH Keys section, use Add Key to add or confirm an SSH key on the reservation, then launch. Ornn pushes the active reservation keys to the host as part of the launch step.

Connect via SSH

Once the host is ready, the SSH Host and User fields (plus a ready-to-run Quick Connect command) appear in the Connect section. Copy that command, including its port:

ssh -p <ssh-port> <user>@<ssh-host>

Bare Metal is direct physical host access. There is no snapshot, no disk rollback, and no managed disk. You’re responsible for everything on the machine.

VM and Bare Metal can’t run on the same reservation at the same time. Switching modes after launch tears down the existing environment; anything not persisted off the host will be lost.

GPU metrics

View GPU metrics in the reservation Observability tab or with ornn check. Ornn’s agent collects these readings locally on the host.

Push additional keys

To add another key to an already-launched Bare Metal reservation, open the reservation’s SSH Keys section and use Add Key. Ornn queues the new key for every active machine in that grouped reservation. From the CLI, add the key directly to the reservation:

ornn ssh-keys add --public-key-file ~/.ssh/id_ed25519.pub --label laptop
ornn ssh-keys assignments assign <reservation-id> --key laptop

Active machines for that reservation automatically receive the updated key set. To re-sync the keys already attached to the reservation, run:

ornn ssh-keys assignments sync <reservation-id>

Reboot and Hard reset

Bare Metal hosts stay live for the reservation term. Use Reboot or Hard reset from the reservation detail page when you need to recover from a stuck workload without giving up the reservation:

Reboot cycles the operating system on the host. Your Linux user, home directory, authorized SSH keys, and any attached Ornn storage volumes stay in place. Ornn re-mounts volumes and reconnects the agent automatically.
Hard reset wipes tenant data on the host (Linux user, home directory, authorized keys, /tmp, /var/tmp, /dev/shm residue) and then reboots. Once the host is back, Ornn re-pushes the reservation’s active SSH keys, so you can reconnect once provisioning finishes. Use it to return the host to a clean state without releasing the reservation.

Select a node in the Nodes table to inspect its current IP, SSH user, port, and attached volume. A missing port appears as —. Your selection stays on that node when the list refreshes; a node that leaves the reservation is removed from the selection. Filter by Live, Offline, or Unknown to match the health shown in the table. Private nodes show their VPN address when it is available. To reboot one host, open Nodes in the reservation detail page, inspect the host, and click Reboot node. Select hosts in the Nodes table to reboot a subset, or use Reboot all nodes in the reservation menu when every host is eligible. Nodes in Kubernetes or Slurm clusters are managed through their cluster. The reboot button stays disabled and progress remains visible while Ornn waits for the host to return. Another request during that time uses the existing reboot. If the reboot fails or its return cannot be confirmed, the console shows an error. Check SSH access before retrying. Wait for SSH to reconnect and your volume to remount before resuming work. Reboot progress belongs to your current reservation. A previous reservation’s request does not block you from requesting a reboot. If Ornn cannot confirm reboot status, the console shows a status error; check SSH access before retrying.

Hard reset destroys everything on the host that isn’t persisted off it. Copy datasets, checkpoints, and any local state to object storage or an Ornn storage volume before you trigger it.

The equivalent CLI commands take a node id:

ornn machines reboot <node-id>
ornn machines reset <node-id> --erase-local-data

CLI equivalents

From an interactive terminal, the Ornn Compute CLI can queue Bare Metal access, wait for SSH readiness, and connect directly. The Linux login is tenant.

ornn ssh-keys add --public-key-file ~/.ssh/id_ed25519.pub --label laptop
ornn launch <reservation-id> --key laptop --mode bare-metal --wait
ornn machines list
ornn check <node-id>
ornn connect <node-id> --identity-file ~/.ssh/id_ed25519
ornn ssh-keys add --public-key-file ~/.ssh/id_ed25519.pub --label workstation
ornn ssh-keys assignments assign <reservation-id> --key workstation

ornn connect opens an interactive session. ornn check reports lifecycle, health, metrics, and logs. After you connect, verify GPUs with nvidia-smi on NVIDIA hosts or amd-smi list on AMD Instinct. --key accepts a saved key id, saved key label, inline public key, or public-key file path. If you pass a private key path by mistake and the matching .pub exists, the CLI uses the public key file and refuses to upload private key material. Because launch queues provisioning, use --wait or run ornn machines wait <node-id> to wait until the host is reachable. ornn connect <node-id> --print prints the SSH command without connecting. See the Ornn Compute CLI and Manage SSH keys for details.

Use the API

You can run the same flow over HTTPS with an organization API key. Each step shows the CLI command where one exists, the REST request, and Python with requests. The API reference has the full request and response schemas. The examples use fictional IDs. Before you start:

Your organization is approved and holds a Bare Metal reservation.
Your organization has at least one active SSH key. Note its ID; see Manage SSH keys.
Note your key’s fingerprint. ssh-keygen -lf ~/.ssh/id_ed25519.pub prints it as SHA256:..., the same format the API returns.

export ORNN_API_KEY="ornn_sk_example..."
export ORNN_API_URL="https://api.ornn.com"
export RESERVATION_ID="11111111-1111-4111-8111-111111111111"
export SSH_KEY_ID="88888888-8888-4888-8888-888888888888"
# Set after launch, from a node_id in the response:
export NODE_ID="33333333-3333-4333-8333-333333333333"

The Python examples share this setup:

import os
import time

import requests

API = "https://api.ornn.com"
HEADERS = {"Authorization": f"Bearer {os.environ['ORNN_API_KEY']}"}
reservation_id = os.environ["RESERVATION_ID"]
ssh_key_id = os.environ["SSH_KEY_ID"]
fingerprint = "SHA256:exampleFingerprint0000000000000000000000000"

1. Wait for activation

When the reserved window starts, Ornn activates the reservation and assigns its hosts. A non-null deployedAt on the reservation means hosts were requested. To start sooner within the window, or to retry when pendingOperation is activate, activate the reservation:

curl --fail-with-body -X POST \
  "$ORNN_API_URL/commerce/reservations/$RESERVATION_ID/activate" \
  -H "Authorization: Bearer $ORNN_API_KEY"

response = requests.post(
    f"{API}/commerce/reservations/{reservation_id}/activate",
    headers=HEADERS,
    timeout=60,
)
response.raise_for_status()
print(response.json()["deployedAt"])

Activating an already activated reservation returns it unchanged. If the response is 409 with runtime_pending, repeat the same request.

2. Launch access

Launch pushes your SSH keys to the reservation’s hosts. If the reservation has no hosts yet, launch selects them and starts provisioning.

ornn launch "$RESERVATION_ID" --mode bare-metal --key "$SSH_KEY_ID" --wait

curl --fail-with-body -X POST \
  "$ORNN_API_URL/v1/orchestrator/nodes/reservations/$RESERVATION_ID/launch" \
  -H "Authorization: Bearer $ORNN_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"access_mode\": \"bare-metal\", \"ssh_key_ids\": [\"$SSH_KEY_ID\"]}"

response = requests.post(
    f"{API}/v1/orchestrator/nodes/reservations/{reservation_id}/launch",
    headers=HEADERS,
    json={"access_mode": "bare-metal", "ssh_key_ids": [ssh_key_id]},
    timeout=60,
)
response.raise_for_status()
node_ids = [node["node_id"] for node in response.json()["nodes"]]
print(response.status_code, node_ids)

A 202 response means the hosts already exist and your keys are queued for them. A 201 response means launch started provisioning. Neither means SSH is ready. Once the reservation has hosts, repeating launch sends the keys again; it does not reprovision them. In scripts, the CLI also needs the flags described in automation mode. Bare Metal launch takes access_mode, ssh_key_ids, network_mode, network_id, node_count, and request_id; see Launch VM or Bare Metal access. Set network_mode to private to join your organization’s private network, and add network_id to choose a specific network. Do not send disk_id: Bare Metal returns 422 with bare_metal_disk_not_allowed.

3. Wait for SSH

Poll each node every five seconds with a deadline. A host is ready when health_readiness.ready is true and your fingerprint is in authorized_key_fingerprints. ready: true with heartbeat:unknown in advisory_reasons is not proof that the host is reachable, so confirm with SSH. Stop if authorized_key_metadata reports failed for your key.

ornn machines wait <node-id> --timeout 30m

curl --fail-with-body \
  "$ORNN_API_URL/v1/orchestrator/nodes/$NODE_ID" \
  -H "Authorization: Bearer $ORNN_API_KEY" \
  | jq '{health_readiness, ssh_endpoint, port, authorized_key_fingerprints, authorized_key_metadata}'

deadline = time.monotonic() + 30 * 60
pending = set(node_ids)
while pending:
    for node_id in sorted(pending):
        response = requests.get(
            f"{API}/v1/orchestrator/nodes/{node_id}", headers=HEADERS, timeout=30
        )
        response.raise_for_status()
        node = response.json()
        for key in node["authorized_key_metadata"]:
            if key["fingerprint"] == fingerprint and key["status"] == "failed":
                raise RuntimeError(f"{node_id}: {key['failure_reason']}")
        if node["health_readiness"]["ready"] and fingerprint in node["authorized_key_fingerprints"]:
            print(f"ssh -p {node['port'] or 22} {node['ssh_endpoint']}")
            pending.discard(node_id)
    if pending and time.monotonic() > deadline:
        raise TimeoutError(f"Hosts still starting: {sorted(pending)}")
    if pending:
        time.sleep(5)

The node IDs come from the launch response, or from List reserved GPU nodes. A timeout means the outcome is unknown, not that launch failed. Check the reservation in Nodes before launching again.

4. Connect

Use the node’s ssh_endpoint (tenant@<host>) and port. Like the CLI, the examples fall back to port 22 only when port is null.

ornn connect <node-id> --identity-file ~/.ssh/id_ed25519

curl --fail-with-body -s \
  "$ORNN_API_URL/v1/orchestrator/nodes/$NODE_ID" \
  -H "Authorization: Bearer $ORNN_API_KEY" \
  | jq -r '"ssh -p \(.port // 22) \(.ssh_endpoint)"'

Run the printed command, then verify GPUs with nvidia-smi or amd-smi list.

Reboot or hard reset through the API

Reboot or hard reset takes a host’s node_id, not a VM ID. Send a stable request_id so a retry does not reboot twice.

ornn machines reboot <node-id>

curl --fail-with-body -X POST \
  "$ORNN_API_URL/v1/orchestrator/nodes/$NODE_ID/reboot" \
  -H "Authorization: Bearer $ORNN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"mode": "reboot", "request_id": "reboot-2026-10-16-a"}'

response = requests.post(
    f"{API}/v1/orchestrator/nodes/{node_ids[0]}/reboot",
    headers=HEADERS,
    json={"mode": "reboot", "request_id": "reboot-2026-10-16-a"},
    timeout=30,
)
response.raise_for_status()
print(response.json()["reboot"]["status"])

The response includes reboot.status, which starts as in_progress. Poll the node until reboot.status is succeeded or failed, then confirm SSH. A second reboot request while one is in progress returns the existing reboot. Nodes in a Kubernetes or Slurm cluster return 409 with cluster_worker_reboot_blocked. For a hard reset, send "mode": "hard_reset"; the CLI equivalent is ornn machines reset <node-id> --erase-local-data. A hard reset returns reboot: null. Ornn wipes tenant data, reboots, and then restores the reservation’s SSH keys, so the reservation needs at least one key. Wait until the node’s keys_pushed_at is later than your request and your fingerprint is listed again. A hard reset requested during a reboot returns 409 with reboot_in_progress.

Change the network

To move the reservation between public and private networking, switch access with the new network_mode. SSH is interrupted until access is ready again. The CLI equivalent is ornn machines switch <reservation-id> --network private.

curl --fail-with-body -X POST \
  "$ORNN_API_URL/v1/orchestrator/nodes/reservations/$RESERVATION_ID/switch-access" \
  -H "Authorization: Bearer $ORNN_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"network_mode\": \"private\", \"ssh_key_ids\": [\"$SSH_KEY_ID\"]}"

Expect 202, then wait for SSH as in step 3.

Stop the reservation

Stopping ends the reservation now and releases its hosts. Ornn revokes your access. This cannot be undone. Copy data off the hosts first.

Stop the reservation with POST /commerce/reservations/{reservationId}/stop. The CLI has no stop command. A 202 response means the stop is accepted and the hosts are still being released; read the reservation until endsAt is set.

curl --fail-with-body -X POST \
  "$ORNN_API_URL/commerce/reservations/$RESERVATION_ID/stop" \
  -H "Authorization: Bearer $ORNN_API_KEY"

What’s next

Access overview

Compare VM and Bare Metal and understand the prerequisites for each.

VM access

Use a managed VM booted from an Ornn, created, or uploaded disk.

An attached Ornn object-storage volume is shared with all local Linux users on your machine. On a writable volume, users can read, create, edit, and delete files regardless of which user mounted the volume or created the file. Read-only volumes remain read-only for every user. Use the same mount path for each user. If you choose a custom path, its parent directories must allow those users to traverse them. Avoid simultaneous writes to the same file from multiple users or nodes; object storage does not provide POSIX file locking.

Delete an attached bucket

In Storage, Detach & delete detaches the bucket from every node in the reservation, then deletes its files and the bucket. The work continues on the server, so you can reload or close the page. The progress shows two steps: detaching from the nodes, then deleting files. If a node refuses the detach, or does not answer in time, the bucket is not deleted. The page shows the reason. Try again later. A detach that does not finish does not confirm that pending writes reached storage. If a node in the reservation is offline, the detach stops at once and offers Force detach. Force detach releases the bucket from every node in the reservation now. Writes that a node did not save are lost.

Changing access modes

Switching from VM to Bare Metal removes your VMs and their disk encryption keys before enabling physical host access. Data in those VMs is not retained. Older VMs may require additional sanitization before Bare Metal is ready. Switching from Bare Metal to VM restores a trusted host operating system and verifies the host before creating the VM. Installed software and local data are not retained. If preparation is still pending, retry the same access mode change when cleanup or restoration finishes. Releasing Bare Metal capacity sanitizes the host before it can be assigned again.

Get Started

Buy and sell

Supplier

Accessing Compute

Storage

Nodes

Account

Direct Bare Metal access to GPU hardware

When to use Bare Metal

Prerequisites

Set up Bare Metal access

GPU metrics

Push additional keys

Reboot and Hard reset

CLI equivalents

Use the API

1. Wait for activation

2. Launch access

3. Wait for SSH

4. Connect

Reboot or hard reset through the API

Change the network

Stop the reservation

What’s next

Access overview

VM access

Delete an attached bucket

Changing access modes

​When to use Bare Metal

​Prerequisites

​Set up Bare Metal access

​GPU metrics

​Push additional keys

​Reboot and Hard reset

​CLI equivalents

​Use the API

​1. Wait for activation

​2. Launch access

​3. Wait for SSH

​4. Connect

​Reboot or hard reset through the API

​Change the network

​Stop the reservation

​What’s next

Access overview

VM access

​Share an attached volume between Linux users

​Delete an attached bucket

​Changing access modes

When to use Bare Metal

Prerequisites

Set up Bare Metal access

GPU metrics

Push additional keys

Reboot and Hard reset

CLI equivalents

Use the API

1. Wait for activation

2. Launch access

3. Wait for SSH

4. Connect

Reboot or hard reset through the API

Change the network

Stop the reservation

What’s next

Share an attached volume between Linux users

Delete an attached bucket

Changing access modes