Photoview

Self-hosted photo management, honestly reviewed. No cloud dependency, no subscription, no algorithm deciding what you see.

TL;DR

• What it is: Open-source (AGPL-3.0) photo and video gallery that mirrors your filesystem structure directly into a web interface — directories become albums, automatically [2][README].
• Who it’s for: Photographers and privacy-conscious households who want a fast, browsable web gallery over their own NAS or VPS, without giving Google, Apple, or anyone else custody of their images [4][README].
• Cost savings: Google Photos charges $2.99–$9.99/mo beyond the 15GB free tier. iCloud charges similarly. Photoview costs $0 in software and runs comfortably on a $5–10/mo VPS or a Raspberry Pi you already own [README][4].
• Key strength: Genuinely respects your file organization. No proprietary database of metadata, no album-first UX that ignores how you actually store photos. What’s on disk is what you see [2][README].
• Key weakness: Development is primarily one-person, the iOS app is officially abandoned, and the AGPL-3.0 license blocks commercial embedding. If you expect Google Photos-level polish or a managed cloud fallback, this isn’t it [3][README].

---

What is Photoview

Photoview is a web-based photo gallery you run on your own server. The core idea is simple: you point it at a directory, it scans for images and videos, generates thumbnails, and serves a clean browser interface. No cloud sync, no account required, no algorithm reordering your shots by “memory” relevance. Your directory tree becomes your album hierarchy, one-to-one [2][README].

The project was created by Viktor Strate Kløvedal and sits at 6,385 GitHub stars as of this review, with ongoing community contributions [3]. It’s written in TypeScript (frontend) and Go (backend), which makes for a reasonably fast binary and good ARM compatibility [2]. The license is AGPL-3.0 — free to use and self-host, but not embeddable in closed commercial products without open-sourcing your application.

The pitch on the homepage is modest and accurate: “Photo gallery for self-hosted personal servers” [README]. No AI superlatives, no “the last photo app you’ll ever need.” It’s a gallery. It scans files. It shows them in a browser. That restraint is either a virtue or a liability depending on what you need.

---

Why people choose it

The 2021 Ars Technica roundup of self-hosted Google Photos alternatives [4] captures the moment that put tools like Photoview on the map: Google ended unlimited free storage in June 2021, and a lot of people who had never thought about self-hosting suddenly did. The complaint was always the same — you give Google your entire visual memory, they change the deal, and there’s no exit that doesn’t feel painful.

Photoview answers this with a deliberately limited scope. It doesn’t try to be Google Photos. It tries to be a fast, private window into photos you already have organized on disk. Reviewers on LinuxLinks [2] and users on AlternativeTo [3] highlight the same things:

Filesystem fidelity. Most photo apps have their own concept of albums that sits on top of, and often in conflict with, how you’ve actually organized folders. Photoview doesn’t. Your 2024/Italy/Florence/ directory becomes exactly that album. If you rename a folder, Photoview reflects the rename on next scan. If you use Samba, FTP, or Nextcloud to manage files, Photoview reads whatever those systems put on disk [README][website].

Speed. Thumbnails are generated at scan time and lazily loaded as you scroll. High-resolution images don’t load until you open them. On a Raspberry Pi 4, browsing a library of several thousand photos is usable; on a proper VPS it’s fast [README][website].

Photographer-specific features. RAW file support via Darktable, EXIF metadata extraction, GPS-based map view, and face recognition are present out of the box or with minimal configuration [2][README]. These aren’t afterthoughts bolted on; the README opens with “made for photographers” [README].

Privacy. The website is explicit: “Your media is valuable, with Photoview nothing leaves your server” [website]. All media is protected with cookie tokens, passwords are properly hashed, CORS is strict [website][README]. For anyone who has spent time reading Apple or Google’s data-use terms, that sentence lands differently than it sounds.

What reviewers don’t highlight — because there’s not much to highlight — is community size. AlternativeTo lists it with no user reviews at the time of this writing [3]. SourceForge’s listing is thin [1]. This is a tool with quiet, satisfied users rather than vocal evangelists. The Discord server exists and is referenced in the README for setup questions, but you won’t find a forum full of “I rebuilt my entire workflow” threads [README].

---

Features

Based on the README and official website, here’s what Photoview actually does:

Core gallery:

• Automatic scanning of configured directories; rescan runs on a schedule or manually [README]
• Directory → album mapping, one-to-one with filesystem [2][README]
• Thumbnail generation with lazy loading; full-res loads on open [website]
• Timeline view across all media [README screenshot]

Media formats:

• JPEG, PNG, WebP, GIF, and most common image formats
• RAW support via Darktable — covers Canon CR2/CR3, Nikon NEF, Sony ARW, and many others [website][2]
• Video support via FFmpeg — common formats transcoded for web delivery [website][2]
• EXIF metadata extracted and displayed in sidebar [2][website]

Organization and discovery:

• GPS coordinates from EXIF used for automatic map view; photos taken near the same location are grouped [website]
• Face recognition — faces automatically detected, photos of the same person grouped [2][README]
• Image recognition features listed in canonical feature set [merged profile]

Users and sharing:

• Multi-user support; each user gets a configured root directory [2][README]
• Two-factor authentication [merged profile]
• Albums and individual media shareable via public URL or password-protected link [2][website][README]

Deployment and databases:

• Docker and docker-compose as primary install path [README]
• Portainer, Unraid, YunoHost support [merged profile]
• PostgreSQL (recommended, currently version 18), MySQL, SQLite [README][merged profile]
• ARM compatible — runs on Raspberry Pi [website]
• REST API [merged profile]

What it doesn’t have:

• No mobile upload client (the iOS app exists as source code but is no longer maintained and unavailable on the App Store) [website]
• No automatic mobile backup — Photoview reads what’s on disk, it doesn’t receive uploads from your phone
• No built-in duplicate detection
• No editing or non-destructive adjustments

---

Pricing: SaaS vs self-hosted math

Photoview has no SaaS tier and no paid version. The pricing math is simply: software costs $0, server costs whatever you’re running.

Cloud photo services for comparison:

• Google Photos: free up to 15GB (shared with Gmail/Drive), then $2.99/mo (100GB), $9.99/mo (2TB), $29.99/mo (5TB)
• iCloud Photos: $0.99/mo (50GB), $2.99/mo (200GB), $9.99/mo (2TB)
• Amazon Photos: free unlimited original-quality photos for Prime members, but only with a $139/yr Prime subscription

Photoview self-hosted:

• Software: $0 (AGPL-3.0)
• Raspberry Pi 4 (if you have one): effectively $0 ongoing
• Entry-level VPS: $5–10/mo (Hetzner, Contabo, DigitalOcean) with 20–80GB storage
• NAS with existing hardware: $0 ongoing, just electricity

Concrete savings example:

A family with 500GB of photos pays Google $9.99/mo for the 2TB tier. Over three years, that’s $360. A Hetzner VPS with 160GB storage costs €4.51/mo ($5–6), or you mount an external storage bucket. Over three years: ~$200 with room to grow — and you own the infrastructure [4][README].

If you already have a NAS (Synology, TrueNAS, or similar), the storage cost is effectively zero. Photoview adds a web interface to files you already control.

The case is less clear if you’re starting from scratch with no server experience and no existing hardware. The $9.99/mo Google plan starts working immediately; a self-hosted setup requires time and maintenance. Budget a few hours upfront, plus occasional updates.

---

Deployment reality check

The install story is Docker-first. You run a docker-compose.yml with three services — Photoview itself, a database (PostgreSQL recommended), and optionally a reverse proxy. The README links a working example compose file [README].

What you need:

• A Linux machine or VPS with Docker installed
• At least 2GB RAM (more if running face recognition at scan time)
• A domain and reverse proxy (Caddy, Traefik, or nginx) for HTTPS access
• PostgreSQL 18 (or 17, MySQL, SQLite for lighter installs)
• Storage — local disk, NFS mount, Samba share, or Nextcloud directory

What can go sideways:

The PostgreSQL 18 migration is a real gotcha for anyone upgrading an existing install. The README explicitly warns that the volume mount point changed — from /var/lib/postgresql/data in earlier versions to /var/lib/postgresql in version 18 [README]. If you miss this when updating your docker-compose.yml, you’ll get a fresh empty database. The README says to back up before upgrading, which is correct advice, but the kind of change that burns people who auto-pull image updates.

Face recognition requires extra setup and resources. It’s not on-by-default and will run the scanner slower on first pass through a large library.

The iOS app is source-available but dead. If your use case assumes a native mobile client for viewing photos, you’ll use the mobile web UI instead, which is functional but not native-app smooth [website]. There is no Android app.

Raspberry Pi deployment works, but face recognition and RAW processing at scan time are slow on a Pi 4. If your library is primarily JPEGs, it’s fine. If you’re scanning 50,000 RAW files, expect the initial scan to take hours [website][README].

Realistic time estimate: 30–60 minutes for a technical user on a fresh VPS. 2–3 hours for someone comfortable with Docker but unfamiliar with reverse proxy setup. For a non-technical founder with no server experience, budget a full day or pay someone to do the initial deployment.

---

Pros and Cons

Pros

• Filesystem-first design. Your folder organization is your album organization. No proprietary database schema to fight, no app-specific album concept that diverges from how files are actually stored [2][README].
• Photography-grade features. RAW support, EXIF parsing, GPS maps, and face recognition aren’t features you’d expect at this price point — which is zero [2][website][README].
• Genuinely private. Nothing leaves your server. No telemetry, no cloud dependency, no terms of service around your photo library [website].
• ARM support. Runs on a Raspberry Pi, making it accessible for hobbyists and low-budget home labs [website][README].
• Multiple database options. SQLite for simple single-user setups, PostgreSQL for serious use — the choice is yours [README].
• Sharing without accounts. Password-protected public links let you share albums or individual photos with people who don’t have Photoview accounts [2][README].
• Two-factor auth. Security feature you’d expect on a paid SaaS is present and available [merged profile].

Cons

• No mobile upload client. The iOS app is abandoned and unavailable on the App Store [website]. Photoview sees what’s on your filesystem; it doesn’t receive uploads from your phone. You need a separate sync tool (Syncthing, rsync, Nextcloud) to get photos onto the server first.
• AGPL-3.0 license. More restrictive than MIT. You can self-host freely, but if you’re building a commercial product that embeds or wraps Photoview, you must open-source that product. Not a concern for personal use; a deal-breaker for some business use cases [3].
• Primarily a one-person project. The project was created by a single developer [2][3]. Community contributions exist, but the maintenance bus factor is real. There are 172 open issues on GitHub at time of writing [3].
• PostgreSQL version migration complexity. The v18 upgrade changes the container volume mount path — a silent data-loss risk for users who auto-update [README].
• No managed cloud option. If your server goes down, your gallery is unavailable. There’s no hosted fallback, no cloud sync, no redundancy unless you build it yourself.
• No editing or organization tools. Photoview displays. It doesn’t crop, rotate, tag, star, or otherwise help you manage your library. It’s a viewer, not a manager.
• Face recognition is slow on low-power hardware. Initial scan of large libraries on ARM devices takes significant time [website][README].
• Limited third-party reviews. The tool has a small, quiet user base. If you hit an unusual configuration problem, community help is available primarily through Discord and GitHub issues, not a broad ecosystem of tutorials [README][3].

---

Who should use this / who shouldn’t

Use Photoview if:

• You already have photos organized in a sensible folder structure on a NAS, VPS, or home server, and you want a fast, private web interface over them.
• You’re a photographer who shoots RAW and wants EXIF, GPS maps, and format support without paying for Adobe or a cloud subscription.
• You’re comfortable running Docker and a basic reverse proxy, or you’ll pay someone to do the initial setup.
• Privacy is a hard requirement — you won’t accept your photos transiting a third-party cloud.
• You’re escaping Google Photos post-free-storage-cutoff and have existing hardware to run on [4].

Skip it if:

• You need automatic mobile photo backup from your phone. Photoview doesn’t receive uploads; you need Immich or Nextcloud Photos for that use case.
• You want to share, organize, and collaboratively manage a photo library with non-technical family members who expect a Google Photos-like experience.
• You’re building a commercial product that needs to embed a gallery — the AGPL-3.0 license will complicate that [3].
• You have no server experience and aren’t willing to spend time learning Docker basics.
• You want a living, actively maintained project with a large corporate backer. Photoview is community-maintained with a single primary author [2][3].

Consider Immich instead if:

• You want automatic mobile backup from iOS/Android.
• You want a closer Google Photos replacement with face recognition, albums you create manually, and a polished mobile app.
• You’re willing to accept more complexity in exchange for more features.

Consider Nextcloud Photos instead if:

• You’re already running Nextcloud for file sync, collaboration, and contacts — adding Photos integrates with existing infrastructure rather than adding another service.

---

Alternatives worth considering

• Immich — the fastest-growing self-hosted photo app right now. Automatic mobile backup, face recognition, album management, active development with a large contributor base. More complex to deploy than Photoview but significantly more featured. The realistic first alternative for most people.
• Piwigo — older, more mature, with plugin support and stronger multi-user/sharing features. PHP-based, heavier to maintain, but has a large community and hosted cloud option.
• LibrePhotos — open-source Google Photos alternative with timeline view, face recognition, and auto-albums. Less polished than Immich but closer in spirit to Google’s feature set.
• Nextcloud Photos — if you’re already on Nextcloud, this is built in. Not a standalone gallery solution, but good enough for many users who are already managing files through Nextcloud.
• Lychee — lightweight, clean photo manager with a focus on simplicity and sharing. Less photography-specific than Photoview but easier for non-technical users.
• Google Photos — the incumbent. If privacy isn’t a concern and you’re under 15GB, the free tier is genuinely good. Beyond that, the monthly bill starts and never stops [4].
• iCloud Photos — good if you’re in the Apple ecosystem and have a subscription anyway. Same caveats: you’re renting storage and trusting a platform.

For a photographer or privacy-focused household that wants to escape cloud photo storage, the realistic shortlist is Photoview vs Immich. Choose Photoview if your photos are already organized on disk and you want a viewer. Choose Immich if you need mobile backup, manual albums, and a more active development trajectory.

---

Bottom line

Photoview does one thing well: it takes photos you already have, organized the way you chose to organize them, and makes them browsable in a fast, private web interface. It doesn’t try to replace your file manager, your editing software, or your mobile camera app. For photographers with an existing directory structure on a NAS or VPS, it’s close to the ideal viewer — filesystem-faithful, RAW-aware, EXIF-complete, and zero ongoing cost.

The limitations are real. No mobile upload, an abandoned iOS app, a one-person primary maintainer, and a PostgreSQL migration that requires attention on upgrade. If you need automatic phone backup or a Google Photos-style organized experience, Immich is the better fit today. But if you’ve already got 80,000 photos organized in folders and you want a way to browse and share them through a browser without giving anyone your credentials or monthly subscription money, Photoview is a clean, low-maintenance answer.

If the deployment is the blocker, that’s exactly what upready.dev deploys for clients. One-time setup, you own the infrastructure, no recurring bill for software you already paid for with your time.

---

Sources

1. SourceForge — Photoview product page. https://sourceforge.net/software/product/Photoview/
2. LinuxLinks — “Photoview: photo gallery for self-hosted personal servers”. https://www.linuxlinks.com/photoview-photo-gallery-self-hosted-personal-servers/
3. AlternativeTo — Photoview listing (6,402 stars, 463 forks, 43 alternatives, AGPL-3.0). https://alternativeto.net/software/photoview/about/
4. Ars Technica — “Google Photos is so 2020 — welcome to the world of self-hosted photo management” (Jun 2021). https://arstechnica.com/gadgets/2021/06/the-big-alternatives-to-google-photos-showdown/

Primary sources:

• GitHub repository and README: https://github.com/photoview/photoview (6,385 stars, AGPL-3.0)
• Official website: https://photoview.github.io
• Demo site: https://photos.qpqp.dk/ (login: demo / demo)