Set Up Photoprism as a Self-Hosted Google Photos Alternative

Why Self-Hosting Your Photo Library Makes Sense

Google Photos changed the way people manage their memories – until it started charging for storage, enforcing compression policies, and making privacy-conscious users uncomfortable with how their images are processed. PhotoPrism steps in as a fully self-hosted alternative: an AI-powered photo management application you run on your own hardware, with no subscription fees, no data harvesting, and no storage caps beyond what your drives can hold.

Getting PhotoPrism running requires a bit more effort than downloading an app, but the payoff is a library that belongs entirely to you. The setup involves Docker, a web server, and some basic configuration – nothing that requires deep Linux expertise, but enough that a step-by-step walkthrough is genuinely useful. This guide covers the full process from installation to first login, including how to handle indexing, HTTPS, and mobile access.

What You Need Before You Start

PhotoPrism runs well on any modern Linux server, a Raspberry Pi 4 (with at least 4GB RAM), a home NAS device running Docker, or a virtual machine. You need Docker and Docker Compose installed, a static local IP for your server, and enough storage for your photo library. The application itself is lightweight, but photo indexing and AI face detection are CPU-intensive tasks, so a modern multi-core processor will make a noticeable difference in index speed.

You also need to decide where your photos will live on disk. PhotoPrism uses two main folders: an originals directory where your actual files are stored, and a storage directory for thumbnails, sidecar files, and its internal database cache. Both paths need to be mounted into the Docker container, so plan them out before writing your compose file. If you’re already using Syncthing for continuous cross-device file sync, you can point PhotoPrism’s originals folder directly at your Syncthing directory and get automatic library updates whenever new photos arrive on any device.

Installing PhotoPrism with Docker Compose

Create a new directory for the project – something like /opt/photoprism – and inside it create a file named docker-compose.yml. PhotoPrism’s official compose template is the cleanest starting point. The core service block defines the image, port mapping, environment variables, and volume mounts. At minimum, set PHOTOPRISM_ADMIN_PASSWORD to a strong password, PHOTOPRISM_ORIGINALS_PATH to /photoprism/originals, and PHOTOPRISM_STORAGE_PATH to /photoprism/storage. Map those container paths to real directories on your host machine in the volumes section.

PhotoPrism also depends on a database. The recommended setup pairs it with MariaDB rather than SQLite, especially if you have more than a few thousand photos. Add a second service block for MariaDB in the same compose file, set matching credentials in both service definitions, and link them using a shared Docker network. The environment variable PHOTOPRISM_DATABASE_DSN in the PhotoPrism service should point to the MariaDB container using its service name as the hostname – Docker’s internal DNS handles the resolution automatically.

Once your compose file is written, bring the stack up with docker compose up -d from your project directory. Docker pulls the images, starts both containers, and PhotoPrism begins its initial setup on port 2342 by default. You can follow the startup logs with docker compose logs -f photoprism. The first launch takes a minute or two while the application initializes the database schema. After that, opening http://your-server-ip:2342 in a browser brings up the login screen.

Log in with the admin credentials you set, then navigate to Settings > Library to configure your indexing options. The most important toggle is whether PhotoPrism should index originals in place or copy them into its own folder structure. Indexing in place is strongly recommended – it means your files stay exactly where they are and PhotoPrism reads them without moving anything. Click Index to start the first scan. On a large library this process runs in the background and can take several hours, but the photos become browsable as they’re indexed rather than waiting for the whole job to finish.

Setting Up HTTPS and External Access

Running PhotoPrism over plain HTTP on your local network is fine for testing, but you’ll want HTTPS for any kind of external access and for the mobile app to work properly. The standard approach is to put a reverse proxy in front of PhotoPrism – Nginx, Caddy, or Traefik all work. Caddy is the simplest option: it handles certificate provisioning automatically if you have a domain pointed at your server’s public IP. A minimal Caddyfile entry for PhotoPrism just needs your domain name and a reverse proxy directive pointing to the PhotoPrism container on port 2342.

If you want access from outside your home network without exposing a port, a VPN back to your home server is the cleaner and more secure option. Tailscale works particularly well here – install it on both the server and your phone, and PhotoPrism becomes reachable at the server’s Tailscale IP without any firewall configuration or public certificate. The PhotoPrism mobile experience relies on its PWA (progressive web app) rather than a native app, which works well in Chrome and Safari once you’re on HTTPS. For iOS, adding the site to your home screen gives you a near-native experience including offline caching of recent albums.

Back on the server side, there are a few PhotoPrism settings worth adjusting once the basic setup is stable. Under Settings > Advanced, you can enable experimental features like face recognition and object detection. These run as background tasks after indexing and require no additional configuration beyond toggling them on, though they add significant CPU load during the analysis phase. The PHOTOPRISM_WORKERS environment variable controls how many parallel indexing threads run – set it to half your CPU thread count to keep the server responsive during long index jobs.

PhotoPrism also supports WebDAV, which means you can mount your photo library as a network drive from Windows, macOS, or any WebDAV-compatible client. The WebDAV endpoint lives at http://your-server/originals/ when enabled in settings. This becomes useful for bulk uploads from a desktop without using the web interface, and it’s the same mechanism that allows some photo management apps to push directly to a PhotoPrism library. One friction point worth knowing upfront: PhotoPrism does not support the Google Photos API or any direct migration tool, so moving an existing Google Photos library means downloading your data via Google Takeout, extracting it, and dropping the folders into your originals directory before running a fresh index.

The Takeout export preserves original file quality and includes metadata JSON files that PhotoPrism can read to recover dates and location data that would otherwise be missing from the EXIF records. Not every photo survives the migration with perfect metadata – some Takeout exports have inconsistent sidecar files – but PhotoPrism’s indexing does a reasonable job of filling gaps using file modification dates and folder names when EXIF data is absent. The trade-off compared to Google Photos is real: smart search, shared albums, and third-party integrations are more limited, and you’re responsible for your own backups. But you also never lose access because a pricing tier changed or a policy shifted under you without warning.