SPIS

Self-hosted private image serving, honestly reviewed. No marketing fluff, just what you get when you drop this on your home server.

TL;DR

• What it is: A lightweight, no-database media server written in Rust — designed for one job: serving your private photo collection over the web with a clean mobile-friendly UI [README].
• Who it’s for: People with a large local photo library who want private web access without Google Photos, iCloud, or the complexity of Immich/PhotoPrism. Especially useful on low-power hardware like a Raspberry Pi [README][3].
• Cost savings: Google Photos charges $2.99–$9.99/mo for 100GB–2TB after the 15GB free tier. SPIS is $0 in software and runs on hardware you may already own. A Raspberry Pi 4 can serve 40,000+ images [README].
• Key strength: No database setup, no heavy dependencies. Single binary or a one-line Docker run. Genuinely runs well on a Raspberry Pi CM4 with tens of thousands of images [README].
• Key weakness: 197 GitHub stars, one active maintainer, no community reviews found in the wild. GPL-3.0 license. Missing features that tools like Immich or Photoview have — no face detection, no machine learning, no sharing links, no multi-user support [README][3].

---

What is SPIS

SPIS stands for Simple Private Image Server. The author created it because they went looking for a lightweight solution to serve photos from a private server and found nothing: “Everything seemed way too feature heavy and slow, requiring you to setup databases and other unnecessary components.” [README] That frustration-driven origin story is the product’s clearest design brief.

The result is a Rust binary that scans a media directory, generates thumbnails, and serves a progressive web app with endless scrolling, favorites, slideshow mode, and filtering by year, month, or subdirectory. The entire stack runs without PostgreSQL, MySQL, or any external database — which is the thing that separates it from most of the gallery competition [README][3].

The project is maintained by a single developer (gbbirkisson on GitHub) and sits at 197 stars — niche, but active. CI passes, CodeCov coverage is tracked, and there are release tags. It is not a dead project, but it is also not a community with hundreds of contributors [README].

The author personally runs it on a Raspberry Pi Compute Module 4 hosting around 40,000 images. That’s a meaningful real-world data point: this is not a toy, and the Rust performance story isn’t marketing copy [README].

---

Why people choose it

There are essentially no third-party reviews of SPIS in the wild — the only external mention found was a one-line entry in a roundup of self-hosted gallery software: “A simple, lightweight and fast media server with decent mobile support. GPL-3.0 Rust” [3]. That’s it.

So the “why” comes directly from the README’s stated goals and the gap the author identified: every other self-hosted photo gallery either requires a database, runs heavy AI pipelines you don’t need, or has a UI that doesn’t work well on mobile.

The no-database argument is real. PhotoPrism requires MariaDB or PostgreSQL. Immich requires PostgreSQL plus Redis. LibrePhotos requires PostgreSQL. For someone who just wants to point a server at a folder of JPEGs and get a decent browsing experience, these requirements are overhead that doesn’t pay off [3]. SPIS skips all of it.

The Raspberry Pi angle is legitimate. Most of the competition is designed for x86 servers with 4–8GB RAM. SPIS was built on and for ARM, on constrained hardware. If your photo storage lives on a NAS or a Pi and you want web access to it, the alternatives either won’t run or will be sluggish [README].

The PWA matters for mobile. SPIS can be installed as a home-screen app on iOS and Android. Multi-select with long press works. The author explicitly called out mobile-friendliness as a design goal, and the interface is built around it rather than bolted on afterward [README].

What people don’t choose it for is everything else: AI tagging, face recognition, sharing albums with external people, multi-user accounts, or a mobile backup app that auto-uploads from your phone. Those use cases live in Immich or PhotoPrism [3].

---

Features

Based on the README:

Gallery and browsing:

• Endless scroll through your media collection [README]
• Filter by year, month, favorites, subdirectories [README]
• Slideshow playback [README]
• Multi-select with long press on mobile [README]
• Instant detection of newly added files — no manual rescan trigger [README]

Organization:

• Mark favorites [README]
• Archive support (with optional delete-on-archive) [README]
• Subdirectory-based organization (you keep your folder structure, SPIS respects it) [README]

Technical:

• REST API [profile]
• Progressive web app — installable on iOS/Android [README]
• Custom scripts that can be triggered from the UI [README]
• Configurable media processing schedule (default: 2am daily) or run-on-start [README]
• Configuration via TOML file, CLI flags, or environment variables — any of the three [README]
• Unix socket support for reverse proxy setups [README]

Deployment options:

• Docker / Docker Compose [README][profile]
• Debian apt package [profile]
• Standalone binary with external nginx/Caddy [README]

What it notably does not have:

• Face detection or AI tagging [README]
• Album sharing with external links [README]
• Multi-user accounts with separate libraries [README]
• Mobile backup app (no auto-upload from phone) [README]
• Geo-mapping of photos [README]

---

Pricing: SaaS vs self-hosted math

SPIS has no cloud tier, no freemium, no hosted version. It is pure self-hosted, $0 in software licensing.

Cloud photo services for comparison:

• Google Photos: Free up to 15GB (shared with Drive and Gmail). After that: $2.99/mo for 100GB, $9.99/mo for 2TB. At 100GB of photos that’s $35.88/year. At 2TB it’s $119.88/year.
• iCloud Photos: $0.99/mo (50GB), $2.99/mo (200GB), $9.99/mo (2TB). At 2TB: $119.88/year.
• Amazon Photos: Unlimited photo storage included with Prime ($139/year), otherwise $9.99/mo for 100GB.

Self-hosted SPIS:

• Software: $0 (GPL-3.0) [README]
• Hardware: $0 if you already have a NAS, home server, or Raspberry Pi. A new Raspberry Pi 4 2GB is around $35–45 one-time. Storage is whatever drives you already own.
• VPS if you want cloud hosting: $3–6/mo on Hetzner or Contabo for the smallest tier, which is more than enough for SPIS given its resource profile.

Concrete math: If you’re paying $9.99/mo for Google Photos 2TB storage, that’s $119.88/year. A Raspberry Pi 4 plus a 2TB USB drive runs ~$80–100 one-time. SPIS breaks even in under a year and your data stays on hardware you physically own. If you’re already running a home server or NAS, the cost of adding SPIS is essentially zero [README].

The honest caveat: this math only works if you’re comfortable with Docker or Linux. If you need to hire someone to set it up, that’s a one-time cost, not a recurring one.

---

Deployment reality check

The README is unusually honest about the architecture. There are two deployment paths:

Docker (recommended path):

docker run -v /your/media:/media -v /your/data:/data -p 8080:8080 ghcr.io/gbbirkisson/spis

Point it at your media directory, point it at a data directory for thumbnails and metadata, expose a port. That is genuinely the core of it. Add Docker Compose for persistence across reboots and you’re done [README].

Binary path (advanced): Requires a reverse proxy (nginx or Caddy) because the binary serves an API and static assets but not a full HTTPS-capable web server by itself. The README documents Debian + systemd + nginx setup explicitly, which signals the author uses this path themselves [README].

What you actually need:

• Any Linux machine — Raspberry Pi, NAS, VPS, old laptop
• 1–2GB RAM is sufficient (the author runs 40K images on a Pi CM4) [README]
• Docker or basic Linux knowledge for the binary path
• A domain + reverse proxy + SSL cert if you want HTTPS access outside your home network

What can go sideways:

• First run triggers media processing — on 40,000 images this will take time. The README has a --processing-run-on-start flag and a processing schedule (default daily at 2am). Don’t panic if nothing shows up immediately.
• No built-in HTTPS. You need Caddy or nginx in front of it for SSL. Non-negotiable if you’re exposing this to the internet.
• No authentication system documented in the README beyond network-level security. If you’re putting this on a public URL, you need a reverse proxy with auth or a VPN. This is not a multi-tenant app.
• GPL-3.0 means if you embed this in something you distribute, the GPL propagates. For personal use: irrelevant.
• Single maintainer. If gbbirkisson stops maintaining it, the project stops moving. 197 stars is not a large enough community to guarantee a fork picks it up [README].

Realistic setup time for someone comfortable with Docker: 15–30 minutes. For someone setting up a reverse proxy for the first time: 2–3 hours. For someone who has never touched Linux: this is not the right first project.

---

Pros and Cons

Pros

• No database required. This is the headline feature. No PostgreSQL setup, no migrations, no database maintenance. Drop it on a machine, point it at a folder, done [README][3].
• Actually runs on a Raspberry Pi. Not “theoretically possible” — the author’s production deployment is a Pi CM4 with 40K images [README]. The Rust backend makes this credible.
• Progressive web app. Works as a home-screen app on iOS and Android. Mobile is a first-class citizen, not an afterthought [README].
• Flexible configuration. TOML file, CLI flags, or environment variables — whichever fits your deployment style [README].
• Custom scripts from UI. You can wire up shell scripts that run on-demand from the gallery interface. Niche but powerful for power users [README].
• Instant new file detection. Drop photos into the media directory; they appear without manual rescans [README].
• Active CI, test coverage tracked. Not a project that was uploaded and abandoned [README].
• GPL-3.0 for personal self-hosting. Copyleft, but for personal use that means nothing [README].

Cons

• 197 stars, one maintainer. Small project. If the maintainer moves on, so does active development [README].
• No authentication built in. You need a VPN or reverse proxy with auth to safely expose this to the internet. Not a dealbreaker but it is extra work [README].
• No mobile backup app. Unlike Immich, SPIS does not have a phone app that auto-uploads your camera roll. You still need to get photos onto the server yourself [README][3].
• No face detection, AI tagging, or geo-mapping — if those features are why you’re looking at self-hosted galleries, look at PhotoPrism or Immich instead [3].
• No multi-user support. This is a personal gallery, not a family sharing platform [README].
• GPL-3.0 is restrictive for commercial use. If you’re building something you want to distribute or sell, read the license carefully [README].
• No external review data. Zero independent reviews found. Every assessment you read (including this one) is based on the README and one-line mentions in roundup lists [3]. That’s a risk factor when choosing infrastructure.
• No native HTTPS. Requires external reverse proxy for anything beyond LAN use [README].

---

Who should use this / who shouldn’t

Use SPIS if:

• You have a large personal photo library on a home server or NAS and want a clean web UI to browse it.
• You want the absolute minimum setup overhead — no database, no accounts system, no config bloat.
• Your hardware is a Raspberry Pi or similarly constrained ARM device.
• You’ve already escaped Google Photos for local storage and just need a viewer.
• You’re comfortable with Docker and a basic reverse proxy setup.

Skip it (use Immich instead) if:

• You want automatic phone backup — upload from iOS/Android camera roll directly to the server.
• You want face recognition, people albums, or AI-assisted search.
• You want a proper multi-user setup where family members have separate accounts.
• You want an experience that closely replicates Google Photos.

Skip it (use Photoview instead) if:

• You want multi-user support with per-user libraries.
• You want EXIF-based location maps.
• You want a more mature project with a larger community behind it.

Skip it (use PhotoPrism instead) if:

• You want ML-powered auto-tagging and face clustering.
• You want a comprehensive metadata editing system.
• You’re willing to run PostgreSQL in exchange for those features.

Skip it (stay on Google Photos) if:

• You have no Linux experience and no technical person to help you.
• You have fewer than 100GB of photos and are on the free tier.
• Your primary use case is sharing albums with family who don’t have accounts.

---

Alternatives worth considering

From the DevOpsSchool gallery roundup [3] and the broader self-hosted gallery category:

• Immich — the current community darling for Google Photos replacement. Auto-upload from phone, face recognition, multi-user, active development. MIT license. Requires PostgreSQL + Redis, significantly heavier than SPIS. Pick this if you want features over simplicity.
• Photoview — clean UI, multi-user, EXIF location maps, mobile-friendly. GPL-3.0, written in Go. More complex setup than SPIS but more mature community. Pick this if you need multi-user without PhotoPrism’s complexity.
• PhotoPrism — the feature-maximal option. ML tagging, face clustering, geo-maps, full EXIF editing. AGPL-3.0, Go + TensorFlow. Requires more RAM (2–4GB recommended), needs a real database. Pick this if you want the closest self-hosted equivalent to a premium photo management suite.
• PiGallery 2 — directory-first, no database, MIT license, Node.js. Similar philosophy to SPIS but TypeScript instead of Rust, and more features (maps, video support, face detection). Pick this if SPIS’s feature set feels too minimal but you still want no-database simplicity.
• Lychee — PHP-based, album-focused, good multi-user support, MIT license. Pick this if you want an album-oriented sharing experience.
• Piwigo — mature, GPL-2.0, PHP. Community of plugins and themes. Better choice if you want an established project with a track record and commercial hosting option.

For the specific audience of “I have a Raspberry Pi, I have a folder of photos, I want a clean mobile-friendly viewer with zero fuss,” the realistic shortlist is SPIS vs PiGallery 2. SPIS is simpler and lighter. PiGallery 2 has more features (maps, face tags) and a larger community.

---

Bottom line

SPIS does one thing: it turns a folder of images on a low-powered server into a clean, mobile-friendly web gallery without requiring a database, a cloud account, or a multi-hour setup. On that narrow brief, it delivers. The Rust backend running 40,000 images on a Raspberry Pi CM4 is a real data point, not marketing copy.

The honest limitation is that the project is one person maintaining 197-star software with essentially no external review ecosystem. If you’re looking for something with a community you can ask questions in, bug reports that get triaged by more than one person, or feature velocity, look at Immich or Photoview instead. SPIS is for people who find those tools over-engineered for their actual need — which is: I have photos, I want to look at them from my phone, I don’t want to maintain a database.

If the setup is the blocker, that’s exactly what upready.dev deploys for clients — one-time, on your hardware, you own the result.

---

Sources

1. DevOpsSchool — “List of Top Free Open Source & Self Hosted Application for Photo and Video Galleries”. https://www.devopsschool.com/blog/list-of-top-free-open-source-self-hosted-application-for-photo-and-video-galleries/

Primary sources:

• GitHub repository and README: https://github.com/gbbirkisson/spis (197 stars, GPL-3.0 license)
• Live demo: https://spis.fly.dev