Self-Hosting on a Raspberry Pi 2026

A Raspberry Pi can host useful services, but project popularity and the existence of a container do not prove that a specific release will run well on a specific board. Treat every tool as a workload to verify: inspect the release artifact or container manifest, stage it on the target hardware, measure it with representative data, and restore it from backup before relying on it.

This guide evaluates ten project families without carrying forward old hardware prices, memory estimates, or generic ARM labels.

Quick answer

Use conditional workload selection. Check exact artifact support, storage endurance, backup and restore, security, network exposure, measured resource use, upgrade behavior, and operator capacity.

For containers, inspect the exact image tag and container manifest for linux/arm64 or any other target architecture. Compatibility is dependency-specific: the application, database, add-ons, base image, and migration tools must all support the selected architecture and release.

Ratings, review counts, enrollment, user estimates, and marketplace signals are not applicable to this deployment test. Do not use popularity as a substitute for compatibility. Verify the exact image and workload.

Hardware and cost inputs

Use the current official product page or product brief to identify the selected Raspberry Pi model and its hardware features. Hardware pricing, tax, availability, power, storage, backup, and hosted alternatives vary by region, configuration, and date. Apply a region and tax caveat to any cost scenario and recheck before publication or purchase.

Do not size a deployment from the board specification alone. Storage media, cooling, power supply, operating system, architecture, network, and attached devices affect the result. Database-heavy services should be tested on the intended persistent storage rather than assumed to be suitable for a microSD card.

Ten projects to evaluate

These projects cover monitoring, passwords, DNS, home automation, application backends, newsletters, Git hosting, analytics, file synchronization, and recipes. Evaluate each project-specific capability through a staged test; the list is a starting point, not a ranking.

Uptime Kuma

Uptime Kuma provides monitoring and status-page features. The current release source identified 2.5.3. Inspect its release notes and the selected container manifest, then test checks, notifications, storage growth, and recovery on the target Pi.

For a focused setup, use the Uptime Kuma self-hosting guide.

Vaultwarden

Vaultwarden is an alternative server implementation for Bitwarden-compatible clients. Confirm the selected image architecture, client compatibility, TLS design, backup contents, and restore process. Password data raises the recovery and security bar; a successful container start is not sufficient evidence.

Pi-hole

Pi-hole provides DNS filtering. Test the exact image, network mode, host DNS behavior, DHCP design where applicable, and recovery. Because DNS can affect the entire network, retain a documented fallback resolver during changes.

For another DNS-focused option, see AdGuard Home on a self-hosted server.

Home Assistant

Home Assistant supports home-automation integrations. Hardware access, add-ons, databases, radio adapters, and integration dependencies can change the deployment shape. Test the selected release, device access, backups, and restore on the exact board and operating system.

PocketBase

PocketBase provides an application backend. Its documentation includes a PocketBase pre-1.0 caution: changes can require migration and changelog work, and the project advises against treating it as a no-review choice for critical applications. Version the binary, schema, hooks, and migration procedure together. The current release source identified v0.40.1.

Listmonk

Listmonk provides newsletter and mailing-list management. Verify the exact application and database artifacts, mail-provider configuration, queue behavior, bounce handling, backups, and restoration. Sending capacity depends on the full mail path, not the board or repository identity.

Gitea

Gitea provides Git hosting. Verify the selected release and architecture, SSH and HTTP exposure, storage, repository backup, database backup, and a clone from the restored system. Repository integrity and access controls belong in the acceptance test.

Plausible Community Edition

Plausible Community Edition dependencies make this a multi-service deployment rather than a generic lightweight container. Follow the current self-hosting documentation, inspect every required image and database dependency, and measure the whole stack on the target hardware.

Syncthing

Syncthing provides device-to-device file synchronization. Verify the current artifact, discovery and relay behavior, filesystem permissions, conflict handling, storage capacity, and restoration. Test representative file counts and sizes rather than extrapolating from an empty instance.

For a dedicated walkthrough, see the Syncthing file-sync guide.

Mealie

Mealie provides recipe management. Verify the current container architecture and dependency set, then test imports, attachments, search, user access, backup, and restore. Data migration and release notes should be reviewed before updates.

Release and repository evidence

At the dated access time, the ten canonical repository APIs returned successfully and reported archived=false. Sampled release sources identified Uptime Kuma 2.5.3, Vaultwarden 1.37.2, Home Assistant 2026.8.3, PocketBase v0.40.1, Gitea v1.27.2, and Syncthing v2.1.3. Pin exact versions and recheck before publication or installation.

The repository APIs also exposed stars and forks. These are dated repository counters within repository scope; they are not installations, Pi users, performance results, stability, or support evidence. They should not decide which service runs on your device.

Repository and documentation reachability is point-in-time and not an ARM or support guarantee. A project can be active while a particular image, tag, database, or add-on lacks the architecture needed by your deployment.

How to verify ARM compatibility

Docker's multi-platform documentation explains how image indexes can point to architecture-specific manifests. For each service:

Select the exact release and image tag.
Inspect the container manifest and confirm linux/arm64 for a 64-bit Pi operating system.
Repeat the check for databases, sidecars, exporters, and migration images.
Review release notes for architecture-specific issues.
Pull and start the image on the target Pi in a staged network.
Exercise application features with representative data.
Stop it, restore it from backup, and run the same checks again.

A source build may be possible when a published artifact is missing, but that creates a separate build, patch, and update obligation.

Measure the target system

There is no reproducible Pi benchmark receipt in this guide for universal memory, temperature, power, throughput, or workload limits. Measure the target workload with the exact Pi model and RAM, operating system, storage, image digest, dataset, network, cooling, warmup period, repetitions, and raw output.

Collect:

CPU and memory during idle, normal, and burst traffic;
disk latency, free capacity, and write growth;
application and dependency errors;
response time for representative user actions;
temperature and throttling reported by the board;
restart behavior after power loss;
backup duration and restored-service verification.

The result is valid for the tested system. Changing the image, dataset, database, storage, or cooling can change the result.

Storage, backups, and updates

Use durable storage appropriate to the write pattern. Keep backups off the Pi and include application data, databases, configuration, and required secrets. For encrypted remote backups, see the Duplicati guide.

Run a restore drill into a clean environment. Confirm user access and application-level data, not only that files exist. Keep the prior image and a tested rollback path until the new release passes acceptance checks.

Decision checklist

Before keeping a service on the Pi:

confirm the exact release asset or image architecture;
confirm every dependency and migration tool;
run representative application tasks;
measure resource and storage behavior;
restrict network exposure and administrative access;
pin the tested versions;
back up all required state off-device;
restore into a clean staged instance;
document upgrades and rollback;
name the operator who will respond to failure.

Monitoring should cover service health, disk capacity, backup completion, certificate expiry, and board-level resource signals. The Prometheus and Grafana guide can help when that stack itself passes the same architecture and workload checks.

Sources

Hardware and architecture:

Raspberry Pi 5 product brief

Project repositories:

Release and operational documentation:

The SaaS-to-Self-Hosted Migration Guide (Free PDF)