Self-hosted Google Photos alternative: run Immich or PhotoPrism on your own server

Nobody sets out to pay a subscription for their own photographs. It happens gradually: the free tier fills, the phone starts refusing to back up, and the cheapest way to make the warning go away is a monthly fee. A few years later the library is large enough that the fee has gone up a tier, and cancelling it means finding somewhere else for fifteen years of pictures in thirty days.

That is the moment most people start searching for a self-hosted Google Photos alternative. The good news is that the software is genuinely excellent now — Immich in particular does automatic phone backup, face and object recognition, albums, sharing and timeline search, and it is free. The bad news is the part nobody puts in the tutorial: the software is the easy half.

What running a photo library actually requires

Immich is not one program. It is a web server, a machine-learning service, a Redis instance and a PostgreSQL database with a vector extension, which have to start in the right order and stay started. PhotoPrism needs MariaDB. Neither will run usefully on the 1 GB server that the price-sorted list on a cloud provider's order page puts at the top.

Then there is the part that breaks silently. A photo library is the one workload where the defaults of a normal web server are actively wrong:

• Upload size. Nginx caps request bodies at 1 MB out of the box. A 4 MB photo fails. A 900 MB video from a modern phone fails several times over.
• Buffering. A proxy that buffers the whole request before passing it on will write your video to a temporary file first, then run out of disk doing it.
• Timeouts. A 60-second read timeout is fine for a web page and hopeless for an upload over hotel wifi.
• WebSockets. Without the upgrade headers, the upload progress bar never moves and live album updates never arrive — so the app looks broken even when it is working.

Every one of those is a five-line fix that you only learn about by losing an evening. Multiply by TLS certificates, a database that has to survive a reboot, and storage that has to survive the server itself, and the actual cost of self-hosting is not the machine. It is the weekend.

How Simplewala deploys it

We added Platforms for exactly this. A platform is a complete product we install whole — you pick it, name a domain, and the containers, the database, the storage layout, the proxy, the certificate and the admin account are ours to get right. The catalogue currently covers photos and video backup (Immich, PhotoPrism), files and sync (Nextcloud, File Browser) and streaming (Jellyfin).

The database comes with it

You are not asked to install PostgreSQL first. Each platform ships with the database engine it actually wants — Postgres for Immich, MariaDB for PhotoPrism, none at all for Jellyfin — as a multi-container deployment with startup ordering and health gates, so the web service does not come up before the thing it depends on.

The proxy is built for media, not for web pages

Platforms get a different vhost from a normal site: no request body limit at all, request and response buffering off, hour-long read and send timeouts, and the WebSocket upgrade headers. Nextcloud additionally gets its CalDAV, CardDAV and WebFinger discovery redirects, without which it shows a permanent setup warning and client auto-discovery quietly fails.

The library lives on block storage

Your photos go on a block volume, not on the server's boot disk. That is the difference between "the server was rebuilt" being an inconvenience and being a catastrophe. If you later remove the platform, the library stays — deleting it is a separate action you have to ask for explicitly.

It refuses to install where it will not work

Every platform card shows its RAM floor before you click anything, and the deploy runs a capacity check against the target server's memory and free disk. If the machine cannot carry it, the install is refused with the reason, rather than succeeding into a container that gets OOM-killed at 3am during your first big upload.

The admin password is not emailed to you

Credentials are generated platform-side into your secrets vault and revealed on demand. If your account runs an OpenBao instance, they are sealed under your own key.

What it costs, honestly

A photo server is bound by disk, then memory. The media_server flavour on the order form asks for 4 GB minimum, recommends 8 GB, and presets a 500 GB volume — and you can change all three. You pay the cloud provider's price for that machine plus our markup, which is the dashboard fee and does not change with the region. There is no per-photo charge, no storage tier, and no upgrade prompt when the library grows — when you need more disk, you add more disk, at the provider's price.

The comparison that matters is not month one. It is that a subscription is a fee that recurs forever and steps up every time your library does, whereas a volume is a cost that only changes when you decide it does.

What we have not built yet

We would rather you find this out here than after ordering.

• Hardware transcoding for Jellyfin is not wired up — there is no /dev/dri passthrough, so heavy 4K transcoding falls to the CPU.
• Reinstalling onto an existing library is not supported. Each install mints a new instance; the retained library is not adopted automatically.
• Library backup to object storage is not available. The library is on a block volume, which survives a server rebuild, but that is redundancy against one failure, not a backup. Keep a copy somewhere else as well.

The short version

The reason most people do not self-host their photos is not that the software is bad. It is that the gap between "docker compose up" and "a photo library my family can actually use, on a domain, over HTTPS, that survives a reboot" is about six hours of unglamorous configuration you would only do once.

That gap is the product. Create an account, order a media server, and deploy Immich from the Platforms catalogue — the photographs stay yours, and so does the disk they sit on.