PiKVM and JetKVM: Remote Console Access for Real Servers

The problem with managing physical servers remotely is that everything breaks at the worst possible time and at the OS level where your SSH session can’t reach. A kernel panic during a dist-upgrade, a BIOS misconfiguration that boots the machine into a PXE loop, a botched grub update that leaves you at a grub> prompt — all of these require console access, which ordinarily means being physically in front of the machine.

KVM-over-IP solves this. A small device sits between your server and the network, captures HDMI output, emulates a USB keyboard and mouse, and presents the whole thing as a web-accessible remote console. You get full out-of-band access: BIOS/UEFI configuration, OS installation from a virtual ISO, recovery from boot failures, all from a browser tab regardless of the server’s network or OS state.

Enterprise servers handle this with a dedicated BMC (Baseboard Management Controller) — iDRAC on Dell, iLO on HPE, IPMI on Supermicro. Consumer and prosumer hardware doesn’t have one, and even servers with BMCs sometimes have BMCs that are themselves broken or unreachable. A KVM-over-IP device is the universal fallback.

This post covers the current homelab-grade options, how to set them up, and how to get the most out of them — power control, virtual media, Tailscale for remote access, and the multi-server patterns that let one device serve a full rack.

The Landscape

The market for affordable KVM-over-IP is significantly better than it was three years ago.

PiKVM is the mature, fully open source option. The software is Apache 2.0 licensed, actively developed, and runs on Raspberry Pi CM4. The V4 Plus is the current top-of-line: 1080p60, HDMI passthrough so you can connect a local monitor simultaneously, internal USB 3.0, Wi-Fi, and a Mini-PCIe slot for an LTE modem if you need cellular out-of-band access. The V4 Mini drops the passthrough and PCIe slot but is otherwise identical.

JetKVM launched in December 2024 and has gained adoption faster than anything else in this category. At $70 it undercuts PiKVM significantly. It is a purpose-built ASIC device rather than a general-purpose SBC — smaller, lower power, and more polished out of the box. The firmware is partially open but the hardware design is not.

NanoKVM from Sipeed is the budget option. At $40–80 depending on the variant it gets you basic KVM functionality, but 1080p30 video and the less refined software put it behind the other two for serious use.

TinyPilot is well-built commercial hardware but at $350 it’s priced for small business rather than homelab. The software is open source; the hardware cost is hard to justify when PiKVM V4 Plus exists.

For a new build today: JetKVM if cost is the priority or you want something that just works with minimal configuration. PiKVM V4 Plus if you want the most capable device, full open source stack, or need HDMI passthrough for a workstation that also needs a local display.

PiKVM: Setup and Configuration

PiKVM V4 ships pre-assembled and pre-flashed. Initial setup is connecting cables and reaching the web UI.

┌──────────────────────────────────────────────────────────────┐
│                     PiKVM V4 Wiring                          │
│                                                              │
│  Target server                    PiKVM V4                   │
│  ┌────────────┐                   ┌────────────┐             │
│  │ HDMI out ──┼───── HDMI ────────┼─▶ Capture  │             │
│  │ USB-A    ──┼───── USB-C ───────┼─▶ HID emu  │             │
│  │            │                   │            │             │
│  │ ATX header─┼── ATX cable ──────┼─▶ ATX ctrl │  (optional) │
│  └────────────┘                   │            │             │
│                                   │ Ethernet ──┼─▶ LAN/PoE  │
│                                   └────────────┘             │
└──────────────────────────────────────────────────────────────┘

Initial access

Default credentials: admin / admin. Change these immediately — the web UI prompts you on first login. The device generates unique TLS certificates on first boot; the initial boot takes 3–5 minutes.

https://<pikvm-ip>/

SSH is available with the same credentials:

1
2
3

ssh admin@<pikvm-ip>
# Root is also available:
ssh root@<pikvm-ip>

The OS is Arch Linux ARM. The root filesystem is read-only by default (a ro overlay prevents writes from surviving reboots). To make changes:

1
2
3

rw          # Remount read-write
# ... make changes ...
ro          # Remount read-only

Updating PiKVM

1
2
3

rw
pikvm-update
ro

That’s it. The update command handles package upgrades and service restarts. Run it after initial setup and periodically thereafter — the February 2026 release shipped a significantly improved WebRTC H.264 pipeline with substantially lower latency.

ATX power control

The ATX adapter board connects to the motherboard’s front panel header (power switch, reset switch, power LED, HDD LED). This gives PiKVM the ability to power the target on and off, trigger a reset, and read power/activity state — without needing any OS-level access.

Motherboard front panel header:
  PWR_SW+  ──▶ ATX board PWR_SW+
  PWR_SW-  ──▶ ATX board PWR_SW-
  RST_SW+  ──▶ ATX board RST_SW+
  RST_SW-  ──▶ ATX board RST_SW-
  PWR_LED+ ──▶ ATX board PWR_LED+
  PWR_LED- ──▶ ATX board PWR_LED-

ATX board USB ──▶ PiKVM USB port

Once wired, the web UI shows a power panel:

• Power on — short-press the power switch
• Power off (graceful) — short-press (triggers ACPI shutdown if OS is running)
• Force off — long-press (5 second hold, hard cut)
• Reset — short-press reset

All of these are also available via the PiKVM API, which makes them scriptable:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Power on via API
curl -k -X POST https://<pikvm-ip>/api/atx/power \
  -u admin:your-password \
  -H "Content-Type: application/json" \
  -d '{"action": "on"}'

# Force off
curl -k -X POST https://<pikvm-ip>/api/atx/power \
  -u admin:your-password \
  -H "Content-Type: application/json" \
  -d '{"action": "off_hard"}'

# Get current power state
curl -k https://<pikvm-ip>/api/atx \
  -u admin:your-password

Virtual media (Mass Storage Drive)

PiKVM presents a virtual USB mass storage device to the target. Upload an ISO to PiKVM and the target sees a USB drive containing that ISO — enough to boot a Debian installer, a rescue environment, or a Ventoy-style multiboot image.

Upload via the web UI: KVM menu → Drive → Upload image. The image is stored on PiKVM’s internal storage (16–32 GB on V4).

Via command line:

1
2
3
4
5

# Upload an ISO
scp debian-12.iso root@<pikvm-ip>:/var/lib/kvmd/msd/

# List available images
ssh root@<pikvm-ip> ls -lh /var/lib/kvmd/msd/

Once uploaded, connect it in the web UI or via the API:

1
2
3
4
5
6
7

curl -k -X POST https://<pikvm-ip>/api/msd/set_params \
  -u admin:your-password \
  -H "Content-Type: application/json" \
  -d '{"image": "debian-12.iso", "cdrom": true}'

curl -k -X POST https://<pikvm-ip>/api/msd/connect \
  -u admin:your-password

The target can now boot from this virtual CD-ROM. This is the workflow for remote OS installation: upload the ISO once, boot as many times as needed, disconnect when done.

IPMI and Redfish

PiKVM implements an IPMI-over-LAN adapter via the kvmd-ipmi daemon. This allows legacy datacenter tooling that expects IPMI to control PiKVM-attached servers.

1
2
3
4
5
6
7
8
9

# Enable IPMI on PiKVM
rw
systemctl enable --now kvmd-ipmi
ro

# From a management host with ipmitool:
ipmitool -I lanplus -H <pikvm-ip> -U admin -P your-password power status
ipmitool -I lanplus -H <pikvm-ip> -U admin -P your-password power on
ipmitool -I lanplus -H <pikvm-ip> -U admin -P your-password power off

PiKVM also supports Redfish, which is the modern replacement for IPMI:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Redfish power status
curl -k https://<pikvm-ip>/redfish/v1/Systems/0 \
  -u admin:your-password | jq '.PowerState'

# Redfish power action
curl -k -X POST \
  https://<pikvm-ip>/redfish/v1/Systems/0/Actions/ComputerSystem.Reset \
  -u admin:your-password \
  -H "Content-Type: application/json" \
  -d '{"ResetType": "On"}'

The PiKVM documentation explicitly warns against exposing IPMI outside a trusted network — the IPMI protocol has known security weaknesses. Use Redfish or the native PiKVM API instead; reserve IPMI for legacy tooling on isolated management networks.

Tailscale for remote access

The most practical way to access PiKVM remotely is Tailscale. It gives you an authenticated, encrypted tunnel without opening any firewall ports or configuring a VPN server.

1
2
3
4
5

rw
pacman -S tailscale
systemctl enable --now tailscaled
tailscale up
ro

Authenticate via the printed URL, then access PiKVM at https://<tailscale-ip>/ from anywhere on your tailnet. Because Tailscale handles authentication, you can reasonably leave the PiKVM web interface accessible without additional VPN configuration.

JetKVM: Setup and Configuration

JetKVM is a purpose-built ASIC device, not a general-purpose SBC. It is smaller than a pack of cards — approximately 75mm × 45mm × 20mm — and ships with a USB-C cable (HID), an HDMI cable, and a short Ethernet cable.

┌─────────────────────────────────────────────────────────────┐
│                     JetKVM Wiring                           │
│                                                             │
│  Target server            JetKVM                           │
│  ┌───────────┐            ┌──────────┐                      │
│  │ HDMI out ─┼── HDMI ───▶│          │                      │
│  │ USB-A    ─┼── USB-C ──▶│          │─── Ethernet ─▶ LAN  │
│  └───────────┘            │          │                      │
│                           │ [screen] │  (1.5" front display)│
│                           └──────────┘                      │
└─────────────────────────────────────────────────────────────┘

Initial access: connect cables, wait for the front display to show the IP address, open http://<jetkvm-ip>/ in a browser. No static IP configuration needed by default — it uses DHCP.

JetKVM’s web interface is more polished than PiKVM’s out of the box, with a touch-optimised mobile UI and lower-friction first run. The 1.5-inch front display shows current resolution, connection status, and IP — useful when the device is rack-mounted and you need to find it.

Virtual media on JetKVM

JetKVM handles virtual media via its web UI: Upload Image → Connect. ISO files are stored on internal flash. The workflow is identical to PiKVM’s once you’re past the UI differences.

Wake-on-LAN

JetKVM includes Wake-on-LAN support in the web UI — a “Wake” button that sends a WoL magic packet to the target’s MAC address. This covers the power-on case without needing an ATX wiring harness. The caveat: the target machine must have WoL enabled in BIOS and must not have had its power physically cut — WoL works for shutdown/sleep states, not for true power-off on most consumer hardware.

For hard power control (power-on from truly off, hard reset), JetKVM offers a PoE expansion hat that adds an ATX control interface. This brings JetKVM’s power control capability to parity with PiKVM at additional cost and complexity.

JetKVM vs PiKVM: detailed comparison

The decision comes down to what you value. JetKVM wins on price and simplicity. PiKVM wins on capability, extensibility, and open source purity. If you want to SSH into your KVM device, install custom packages, write automation scripts against the API, or extend the hardware, PiKVM is the only real option. If you want to unbox it, plug it in, and have it work, JetKVM is hard to beat at $70.

Covering a Rack with One Device

Neither PiKVM nor JetKVM is a multi-port KVM — each device connects to one target at a time. For a rack with six servers, you have options:

Option 1: One device per server

The simplest and most reliable approach. At $70 per JetKVM, six servers cost $420 plus six short HDMI and USB-C cables. Each server is always accessible without any switching. The per-device cost is the whole argument.

Option 2: HDMI/USB switch + one KVM device

A 4- or 8-port USB+HDMI KVM switch sits between one PiKVM and multiple servers. You select the active server via the switch (either physical button, IR remote, or keyboard hotkey). PiKVM sees whichever server the switch is pointed at.

Server 1 ──┐
Server 2 ──┤ HDMI+USB ──▶ PiKVM ──▶ Network
Server 3 ──┤   switch
Server 4 ──┘

The limitation: you can only access one server at a time, and switching requires either physical access to the switch or a switch that supports remote switching (these exist but add cost). For emergency use, this is fine — you’re unlikely to need simultaneous access to two machines in crisis.

PiKVM has a switch plugin that supports some HDMI switches. With a compatible device, you can switch targets from the PiKVM web UI without touching the switch physically.

Option 3: Servers with native BMC

If you’re running Supermicro, Dell, or HPE server hardware, they have their own BMC with IPMI/iDRAC/iLO. These are better than a KVM device for their host server — deeper integration, power control, sensor data, fan control, system event logs. Add a KVM device only for hardware that doesn’t have one, or as a BMC fallback when the BMC itself becomes unreachable.

Practical Hardening

KVM-over-IP is high-value access — it can control machines at BIOS level with no OS-level authentication standing in the way. Treat the access path accordingly.

Change default credentials immediately. Both PiKVM and JetKVM ship with default admin passwords. These should be changed before the device is accessible on any network.

Use Tailscale or a VPN for remote access. Do not expose PiKVM directly to the internet on any port. Tailscale is the cleanest option: it adds no open ports and no firewall rules, and access is tied to your Tailscale identity.

Isolate on a management VLAN. KVM devices belong on a dedicated management network, not the main LAN. This limits blast radius if the device is compromised and makes it easier to restrict access by source IP.

Disable IPMI if you’re not using it. The IPMI protocol is old and has known weaknesses. If you don’t need IPMI compatibility with legacy tooling, leave kvmd-ipmi disabled.

Keep firmware updated. Both PiKVM and JetKVM ship security patches through their update mechanisms. Run pikvm-update regularly; watch for JetKVM firmware releases on their GitHub.

Two-factor authentication. PiKVM supports TOTP 2FA via the web UI settings. Enable it. A KVM device on a management VLAN behind Tailscale with 2FA is well-defended.

Automation and Scripting

PiKVM’s REST API makes it scriptable for homelab automation workflows.

Automated power sequencing

When bringing a rack up after a power event, you often want to start servers in order — the NAS before the compute nodes that mount NFS, the switches before everything else. A simple script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/usr/bin/env bash
PIKVM_NAS="192.168.10.20"
PIKVM_COMPUTE="192.168.10.21"
PASS="your-password"

pikvm_power_on() {
  local host=$1
  curl -sk -X POST "https://${host}/api/atx/power" \
    -u "admin:${PASS}" \
    -H "Content-Type: application/json" \
    -d '{"action": "on"}'
}

pikvm_power_state() {
  local host=$1
  curl -sk "https://${host}/api/atx" \
    -u "admin:${PASS}" | jq -r '.result.leds.power'
}

# Boot NAS first
pikvm_power_on "$PIKVM_NAS"
echo "NAS powering on..."

# Wait for NAS to come up
until [ "$(pikvm_power_state "$PIKVM_NAS")" = "true" ]; do sleep 5; done
sleep 60  # Allow NFS exports to come up

# Now boot compute nodes
pikvm_power_on "$PIKVM_COMPUTE"
echo "Compute node powering on..."

Ansible integration

For fleets managed with Ansible, the PiKVM API can be called as a pre-task to ensure machines are powered before running plays:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# ensure_power_on.yml
- name: Check power state via PiKVM
  uri:
    url: "https://{{ pikvm_host }}/api/atx"
    user: admin
    password: "{{ pikvm_password }}"
    validate_certs: false
    return_content: true
  register: atx_state

- name: Power on if off
  uri:
    url: "https://{{ pikvm_host }}/api/atx/power"
    method: POST
    user: admin
    password: "{{ pikvm_password }}"
    validate_certs: false
    body_format: json
    body:
      action: "on"
  when: not atx_state.json.result.leds.power

The Build-It-Yourself Path

PiKVM’s hardware designs are fully open. If you have a Raspberry Pi 4 or CM4 and want to build rather than buy, the V3 HAT design files and bill of materials are on GitHub. For a Pi 4:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Flash PiKVM OS to SD card
# Download from: https://pikvm.org/download/

# Raspberry Pi 4 image
# Follow: https://pikvm.github.io/pikvm/v2/

# Required hardware for a Pi 4 build:
# - Raspberry Pi 4 (2GB minimum)
# - PiKVM V2 HAT or compatible HDMI capture card
# - HDMI capture: CSI-2 bridge (preferred) or USB UVC capture card
# - USB splitter or "OTG Y-cable" for HID emulation

The DIY path is meaningfully more involved than buying a V4, and the total cost difference after buying all the components is smaller than you’d expect. For a homelab where your time has value, the pre-assembled V4 or a JetKVM is usually the right call. Build it yourself if you want to learn the internals, have spare Pi hardware, or need a quantity of units where the cost difference adds up.

Sources:

• PiKVM V4 Plus — pikvm.org
• PiKVM Handbook — docs.pikvm.org
• PiKVM ATX Board — docs.pikvm.org/atx_board
• PiKVM IPMI & Redfish — pikvm.github.io
• JetKVM Review — hostbor.com
• JetKVM vs PiKVM Comparison — oreateai.com
• Which KVM over IP in 2025? — itproexpert.com
• Out-of-Band, Part 1: IP KVMs — runzero.com