Docker for Raspberry Pi: Install It, Pick ARM Images, and Protect the SD Card

Docker runs well on a Raspberry Pi when the OS and image architecture match, persistent data is mounted deliberately, and write-heavy workloads are kept off a fragile SD card.

The installation is straightforward. Reliability depends on architecture tags, power, cooling, storage, and container limits that desktop tutorials often skip.

Table of contents

• Choose the right operating system
• Install and verify Docker
• Use multi-architecture images
• Protect storage, memory, and thermals
• Operate a small Compose stack
• How this fits the rest of the stack
• FAQ

Choose the right operating system

Use a supported Raspberry Pi OS release and prefer 64-bit on modern Pi models unless a dependency requires 32-bit. Confirm architecture with uname -m and dpkg —print-architecture. An arm64 host can run arm64 images; older boards may require armv7 builds. The image manifest, not the marketing name, determines compatibility.

uname -m
cat /etc/os-release
dpkg --print-architecture

Keep the OS updated and confirm Docker’s current installation documentation for the supported release. Convenience scripts are useful for labs, while a documented package-repository installation is easier to audit and repeat.

Install and verify Docker

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
sudo usermod -aG docker $USER
# start a new login session
docker run --rm hello-world

Review downloaded scripts before running them and use the official repository path for managed fleets. Joining the docker group grants root-equivalent daemon control, so limit membership. Verify the service starts at boot and inspect docker info for architecture and storage-driver details.

Use multi-architecture images

Choose images that publish the Pi’s architecture. A manifest list lets Docker pull the correct variant automatically; a single amd64 image fails with an exec format error. Inspect manifests before building a stack around an image, and build your own application with a multi-platform pipeline when necessary.

docker buildx imagetools inspect nginx:stable
docker image inspect nginx:stable --format '{{.Architecture}}'

Avoid forcing —platform when the binary inside the image cannot run natively. Emulation can help builds and experiments but adds overhead and surprises on a small device.

Protect storage, memory, and thermals

Put databases and write-heavy volumes on a reliable USB SSD rather than the boot SD card. Mount persistent paths explicitly, back them up, and test restore. Set log rotation because unbounded JSON logs can fill the filesystem. Add memory and CPU limits thoughtfully so one container cannot make the device unusable.

Use a stable power supply and monitor throttling and temperature. Random container restarts under load are often power or thermal problems, not Docker bugs. Keep spare capacity for the kernel, filesystem cache, and remote administration.

Operate a small Compose stack

services:
  app:
    image: example/app:latest
    restart: unless-stopped
    ports:
      - '8080:8080'
    volumes:
      - /srv/app-data:/data
    logging:
      options:
        max-size: 10m
        max-file: '3'

Pin versions for important workloads instead of relying on latest, add health checks, and update one service at a time. Do not expose administrative dashboards directly to the internet. Use TLS, authentication, firewall rules, and a documented recovery path. A Pi is a capable small server, but it still deserves production basics.

Back up more than the Compose file. Record the image digests, environment-file locations, volume paths, firewall rules, and the commands required to rebuild the host from a fresh operating-system image. Store secrets outside the repository and confirm that the restore procedure can recreate ownership on the external disk. For services exposed beyond the home network, prefer a private tunnel or carefully configured reverse proxy over forwarding every container port. Disable password SSH login when key access is established, patch the host regularly, and remove unused images so limited storage does not disappear during an upgrade. Before adding another workload, check free memory, temperature, disk health, and power headroom. Small hardware encourages careful capacity planning; that discipline is a feature, not an inconvenience.

How this fits the rest of the stack

When a Pi experiment grows beyond one device, model the managed alternative with the RunxBuild hosting calculator. The RunxBuild dashboard provides a service runtime and logs without maintaining the board, storage, and network yourself.

Useful related references:

• Installation of Docker in Ubuntu: Step-by-Step for 22.04 and 24.04
• How to Install Docker on Ubuntu: 2026 Guide (22.04 and 24.04)
• Deploy a Docker Container for Free
• Docker services on RunxBuild

FAQ

Can every Raspberry Pi run Docker?

Supported models and OS releases vary. Check Docker documentation and confirm whether the board is arm64 or armv7.

What causes exec format error?

The image binary targets a different CPU architecture. Pull a matching multi-architecture image or rebuild for the Pi.

Should container data live on the SD card?

Light use may work, but databases and write-heavy data are safer on a reliable SSD with backups.

Is the docker group safe?

It is effectively root-level access to the host. Grant it only to trusted users.

Why do containers restart under load?

Check memory pressure, storage errors, power supply quality, and thermal throttling before assuming a Docker defect.