How to Add NVMe Storage to Raspberry Pi 5 for OpenClaw Agents

The Raspberry Pi 5's PCIe 2.0 interface delivers up to 500 MB/s to an NVMe SSD via the official M.2 HAT+, roughly 10x the random read throughput of a typical consumer microSD card. The Raspberry Pi Foundation's own OpenClaw announcement specifically recommends this combination, calling the result "super snappy." That performance gap is the reason this guide exists: for an AI agent that reads workspace files, caches skills, and loads models on every task cycle, storage speed determines whether your agent feels responsive or sluggish.

OpenClaw stores its runtime state, workspace files, and skill cache under ~/.openclaw/. On a microSD card, these small random reads and writes compete with the OS itself for a storage bus that was designed for cameras, not continuous I/O. Write-heavy patterns like log rotation, model artifact caching, and workspace updates accelerate SD card wear. The failure mode is abrupt: the card's controller flips the filesystem to read-only, the agent keeps running in memory with no persistent state, and the next reboot never completes.

The OpenClaw installation documentation makes this explicit: "Use a USB SSD. SD cards are slow and wear out." The M.2 HAT+ takes that advice further by connecting a proper NVMe drive directly to the Pi 5's PCIe bus rather than routing through the USB 3.0 controller, which adds protocol overhead and caps practical throughput around 380 MB/s.

Three workload patterns make the difference especially noticeable:

• Skill installation and updates pull packages from the network and unpack them to disk. On NVMe, an install that takes 30 seconds on SD finishes in single digits.
• Local model inference through Ollama, llama.cpp, or LocalAI loads multi-gigabyte GGUF files from disk. Sequential read speed determines how fast the model is ready to serve requests.
• Workspace I/O during task execution involves many small random reads and writes as the agent reads context, writes intermediate results, and persists event logs.

If you plan to run your OpenClaw agent for more than a few days, NVMe storage is not an upgrade. It is the baseline.

The official Raspberry Pi M.2 HAT+ is the default recommendation, but third-party boards add features the official one does not have. Understanding the tradeoffs helps you pick the right board for your deployment.

Official Raspberry Pi M.2 HAT+

The standard HAT+ connects to the Pi 5's PCIe FFC connector with a ribbon cable and sits on top of the board using threaded spacers. It costs roughly $12 and is the simplest path to NVMe storage.

• PCIe 2.0, single lane, 500 MB/s peak transfer rate
• M.2 M-key slot supporting 2230 and 2242 form factors
• Up to 3A power delivery to the connected drive
• 16mm GPIO stacking header included for additional HAT compatibility
• Requires Pi 5 firmware dated December 6, 2023 or later
• Not certified for PCIe Gen 3.0 (the Foundation notes Gen 3 connections may be unstable)

A compact variant supports only 2230 drives and drops the GPIO stacking header. It also does not fit with the official Active Cooler, so plan your thermal management accordingly if you choose this version.

SupTronics X1208: NVMe Plus UPS in One Board

The X1208 combines an M.2 NVMe slot with uninterruptible power supply circuitry on a single board. For an OpenClaw agent running around the clock, the UPS protects against the filesystem corruption that sudden power loss causes on both SD cards and SSDs.

• M.2 M-key slot supporting 2230, 2242, and 2280 form factors
• PCIe 2.0 and 3.0 support
• 21700 lithium-ion battery slot (up to 5,000 mAh capacity, battery sold separately)
• 5V/5A USB-C input with 1.5A battery charge rate
• Safe shutdown on low battery triggered via GPIO signaling
• I2C fuel gauge chip for battery voltage and capacity monitoring
• Priced around $40 to $45

The 2280 form factor support is the big differentiator. Most high-capacity, high-performance NVMe drives ship as 2280, so the X1208 opens up a much wider selection of SSDs compared to the official HAT+. The UPS alone justifies the price premium for headless deployments in closets, sheds, or anywhere power is not perfectly reliable.

Choosing Between Them

For a desk setup with reliable power where you are experimenting with OpenClaw, the official M.2 HAT+ at $12 is the right call. It is well-documented, inexpensive, and the 2230/2242 constraint still covers good drives.

For an always-on agent deployment where uptime matters, the X1208's safe shutdown on battery prevents the filesystem corruption that otherwise requires a full reinstall. The extra $30 pays for itself the first time the power blinks.

If stacking additional HATs matters to your build (a PoE HAT, for instance), confirm GPIO header clearance before buying. The official HAT+ includes a stacking header; the X1208 routes power through GPIO and does not include one.

Form factor is the first filter. The official M.2 HAT+ accepts 2230 and 2242 drives. The SupTronics X1208 also accepts 2280. If you bought the HAT+ Compact, only 2230 fits. Check your board before ordering a drive.

How Much Capacity Does OpenClaw Need?

OpenClaw's base installation and workspace occupy less than 1 GB. The storage question becomes about what you plan to run alongside it. Local models through Ollama, llama.cpp, or LocalAI are the biggest disk consumers. A single 7B parameter model in GGUF format typically occupies 4 to 8 GB. Larger models like 13B or 70B quantizations can reach 10 to 40 GB.

Practical sizing:

• 128 GB covers the OS, OpenClaw, and two or three small models. Tight if you plan to experiment with different model sizes.
• 256 GB handles the OS, OpenClaw, several models, and room for workspace growth. This is the sweet spot for most single-agent deployments.
• 512 GB and above is only necessary if you store large models simultaneously or run the Pi as a local file server alongside your agent.

Drives That Work Well

Since the Pi 5's PCIe bus tops out at 500 MB/s in Gen 2 mode, buying a high-end Gen 4 drive will not improve performance. A mid-range Gen 3 drive at the right form factor gives the best value.

For 2230 (works with all HATs):

• WD SN740 (256 GB to 2 TB)
• Kingston NV3 2230 (128 GB to 512 GB)
• Sabrent Rocket 2230 (256 GB to 1 TB)

For 2242 (official HAT+ and X1208):

• WD SN520 (128 GB to 512 GB)
• Transcend MTE400S (128 GB to 1 TB)

For 2280 (X1208 only):

• Samsung 980 (250 GB to 1 TB, widely available)
• WD SN770 (250 GB to 2 TB, strong value per GB)
• Kingston NV2 (250 GB to 4 TB)

Expect to pay $15 to $25 for a 256 GB 2230 drive and $35 to $60 for a 1 TB 2280 drive.

What to Avoid

Skip DRAM-less NVMe drives if the price difference is small. While any NVMe drive is a massive improvement over SD, drives with a DRAM cache handle the random I/O patterns of agent workloads more smoothly. Also avoid unfamiliar no-name brands. A failing NVMe controller is harder to diagnose than a failing SD card because the symptoms (silent data corruption, intermittent hangs) are subtler and appear gradually.

Back up your Raspberry Pi agent's workspace to the cloud

Fastio gives OpenClaw agents 50 GB of free cloud storage with an MCP server for direct reads and writes. Index files for semantic search, hand off results to collaborators, and keep your agent's work safe beyond a single drive. No credit card required.

Start 14-Day Trial

There are two paths: a fresh install directly to NVMe, or migrating an existing SD card installation. A fresh install avoids carrying over accumulated filesystem cruft, but migration preserves your existing OpenClaw configuration and skills.

Fresh Install with Raspberry Pi Imager

Connect the M.2 HAT+ with the SSD installed. On another computer, open Raspberry Pi Imager and select the NVMe drive as the target storage device. Flash Raspberry Pi OS (64-bit, required for OpenClaw). Remove any SD card from the Pi, insert the NVMe-equipped board, and power on. The Pi 5 should boot directly from NVMe.

If it does not boot, the bootloader may still prioritize SD. Insert an SD card temporarily, boot from it, and update the boot order using the steps below.

Migrating an Existing Installation

If you already have a working OpenClaw setup on SD and do not want to reinstall from scratch:

1. Boot into Raspberry Pi OS with the desktop environment.
2. Open SD Card Copier from the Accessories menu.
3. Select the SD card as source and the NVMe drive as destination.
4. Wait for the copy to finish, typically 5 to 15 minutes.
5. Shut down, remove the SD card, and power on.

For headless setups without a desktop, use dd from the terminal:

sudo dd if=/dev/mmcblk0 of=/dev/nvme0n1 bs=4M status=progress

After copying with dd, expand the root partition on the NVMe drive using raspi-config or parted to fill the full drive capacity.

Updating Boot Order

If the Pi does not automatically boot from NVMe after migration:

1. Boot from the SD card.
2. Run sudo raspi-config.
3. Navigate to Advanced Options, then Boot Order, then NVMe/USB Boot.
4. Agree to update the bootloader when prompted.
5. Reboot, remove the SD card, and confirm NVMe boot.

If the NVMe drive is not detected at all, add dtparam=pciex1 to /boot/firmware/config.txt to enable the PCIe interface explicitly.

Verifying the Migration

After booting from NVMe, confirm the root filesystem is on the right device:

lsblk

The root mount / should show /dev/nvme0n1p2. If it still reads /dev/mmcblk0p2, the boot order change has not taken effect.

For fresh installs, set up OpenClaw:

curl -fsSL https://openclaw.ai/install.sh | bash

Run the onboarding wizard and confirm the agent starts cleanly. If you migrated from SD, verify your existing skills and workspace are intact by running a simple agent task.

NVMe alone delivers a major speed improvement, but a few configuration adjustments get more out of the hardware for agent workloads.

Free Up RAM for Agent Workloads

On a headless Pi with no monitor connected, reduce the GPU memory allocation to 16 MB by adding this line to /boot/firmware/config.txt:

gpu_mem=16

This frees 60 to 240 MB of RAM that the GPU would otherwise reserve. On a 4 GB Pi running local models, that freed memory can be the difference between the model fitting entirely in RAM and thrashing swap constantly.

Disable Bluetooth and the desktop environment if you are not using them:

sudo systemctl disable bluetooth
sudo systemctl set-default multi-user.target

Enable Node.js Compile Cache

OpenClaw runs on Node.js, and the compile cache avoids re-parsing modules on every startup. Set this environment variable in your ~/.bashrc or in the systemd service file:

export NODE_COMPILE_CACHE=$HOME/.cache/nodejs

On NVMe, the cache loads fast enough that you will notice the difference on every agent restart compared to a cold start without the cache.

Configure Swap on NVMe Instead of SD

SD card swap is both slow and destructive to the media. NVMe swap is fast, and modern SSDs handle the write volume without meaningful wear. For a 4 GB Pi running local models, configure 2 GB of swap:

sudo dphys-swapfile swapoff

Edit /etc/dphys-swapfile, set CONF_SWAPSIZE=2048, then restart the swap service with sudo dphys-swapfile setup && sudo dphys-swapfile swapon. This prevents out-of-memory kills during model loading and large workspace operations.

Minimize Process Overhead

The OpenClaw documentation recommends setting OPENCLAW_NO_RESPAWN=1 in your environment to reduce unnecessary process handoffs during agent execution. Combined with a systemd service configuration for automatic restart on failure, this keeps the agent running efficiently without supervisor overhead eating into the Pi's limited CPU budget.

Local Model Placement

Ollama stores models in ~/.ollama/models/ by default. After NVMe migration, this directory sits on fast storage automatically. A 7B GGUF model that took 45 seconds to load from SD loads in under 5 seconds from NVMe. If you work with several models, the sequential read performance means switching between them no longer requires the long wait that makes SD-based setups impractical for experimentation.

NVMe is faster and more durable than SD, but it is still a single drive in a small computer sitting on a shelf. Drive failure, theft, accidental damage to the power supply, or a bad OS update can wipe everything. For an agent that accumulates workspace data, skill configurations, and task history over weeks or months, off-device backup is not optional.

The simplest approach is a cron job that rsyncs ~/.openclaw/ to another machine on your network. This works but gives you an unstructured file dump with no versioning, no search capability, and no way for someone else to pick up the agent's work without SSH access to the backup target.

Cloud object storage like S3, Google Cloud Storage, or Backblaze B2 adds geographic durability but still treats the files as opaque blobs. You get backup, but not collaboration or discoverability.

A more practical option for agent output is a cloud workspace that treats files as structured, searchable, and shareable objects. Fastio provides exactly this: generous storage with an MCP server that agents can write to directly. Files uploaded to a Fastio workspace are automatically indexed when Intelligence Mode is enabled, which means you can search agent output by meaning rather than just by filename.

The ownership transfer pattern is especially useful for Pi-based agents. The agent creates and populates a workspace, accumulates results over time, and a human collaborator accesses the same workspace through the web interface without needing SSH tunnels or port forwarding. The audit trail records exactly what the agent uploaded and when, which matters for debugging failed tasks and tracking agent activity across time.

For teams running several Pi-based OpenClaw agents, each agent gets its own workspace while team members see everything in one place. The free tier covers most single-agent setups without requiring a credit card.