Immich Setup Guide: Building a Self-Hosted Photo Library

Immich has become one of the most talked-about self-hosted apps because it tackles a problem many people feel acutely: modern photo libraries are valuable, deeply personal, and often trapped inside ecosystems that are convenient but not fully under your control. A self-hosted photo platform offers an alternative, and Immich is one of the most ambitious projects in that space.

The appeal is obvious. You get a modern photo library experience with mobile upload, browsing, albums, search-oriented features, and a design that aims to feel closer to consumer cloud photo products than to a rough admin panel. For self-hosters, that combination is rare and compelling.

But photo infrastructure is not lightweight in the same way as bookmarks or recipes. Photos accumulate fast, videos are large, and expectations are high because the data is emotionally important. That means an Immich setup should be approached more seriously than a casual weekend container experiment.

Plan before you deploy

Before deployment, decide what role Immich will play.

• Is it a primary family photo library?
• Is it only a secondary backup target?
• Will users upload directly from phones?
• Do you want remote access outside the home?
• Are you prepared for storage growth over years, not months?

These questions drive the setup. If Immich will hold irreplaceable memories, you need a real backup strategy from day one. Self-hosting a photo library without tested backups is not bold. It is reckless.

A practical Immich deployment usually includes:

• fast enough storage for library and database workloads
• separate persistent storage for uploads and application data
• regular backups of database and media
• HTTPS for any remote access
• enough CPU and memory for indexing, thumbnails, and library jobs

On hardware: plan for at least 2 CPU cores and 4 GB of RAM, and treat 8 GB as the comfortable floor if you enable machine-learning features like smart search and face recognition. The ML container downloads models on first use and works the CPU hard during the initial library scan, then settles down.

Installing Immich with Docker Compose

Use the official release Compose file and matching environment example, rather than mixing service images and database-extension versions from different tutorials:

mkdir immich-app
cd immich-app
curl --fail --location -o docker-compose.yml \
  https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
curl --fail --location -o .env \
  https://github.com/immich-app/immich/releases/latest/download/example.env

Read both files before starting. Set your media and database storage paths, a unique database password using the characters supported by that release, and a reviewed application version. Keep the database on supported local storage. For repeatable production installation, download both assets from the same selected release instead of relying on a moving latest URL.

Keep the initial web port private: adjust its host binding to localhost or a trusted LAN, or enforce an appropriate firewall policy. Complete account setup before exposing the application. Then inspect the configuration and start it:

docker compose config --quiet
docker compose up -d
docker compose logs -f immich-server

Confirm startup and database migrations finish before uploading irreplaceable media. These commands are a documented installation path, not a deployment we ran on your storage. Back up media and database together, and follow the selected release's upgrade notes before changing versions.

First run

Open http://your-server:2283 in a browser. The first account you create becomes the admin. From there:

1. Create your admin user and log in.
2. In Administration, check the storage template settings before uploading anything, if you care how files are organized on disk. Changing it later triggers a migration job.
3. Install the Immich mobile app, enter your server URL, and log in.
4. Enable background backup in the app and select which phone albums sync.
5. Upload a handful of photos and confirm they appear on the web, then delete one on the phone and see what happens, so you understand the sync model before trusting it.

If you want access from outside your network, put Immich behind HTTPS rather than exposing port 2283 directly. A reverse proxy for your self-hosted services handles TLS and gives phones a clean URL that works from anywhere.

One gotcha worth calling out: the official compose file defaults to the release tag, which means a routine docker compose pull can jump you multiple versions at once. Immich ships fast, and some releases include breaking changes that require reading the notes before upgrading. Pin IMMICH_VERSION to a specific version and upgrade on purpose, not by accident.

Storage and backups

Storage planning deserves special attention. Photos and especially videos can grow into terabytes far sooner than people expect. If your server currently runs on a nearly full SSD with vague plans for "more disks later," fix that before depending on the system. Capacity planning is part of the product choice here.

Backups should be treated in layers, along the lines of the 3-2-1 backup rule:

• primary storage for live library data
• local backup or snapshot path
• off-machine or off-site copy for disaster recovery
• restore testing so you know the process actually works

For the off-site layer, object storage such as Backblaze B2 pairs well with tools like restic or rclone: your originals and a database dump sync to a bucket on a schedule, and a lost server stops being a lost library. Immich also ships a built-in database dump job; make sure whatever backs up your media directory picks up those dumps too.

That may sound excessive for a home photo server, but it is exactly what serious personal data deserves. A beautiful gallery UI does not matter if one failed disk wipes out years of family photos.

Living with a fast-moving project

Mobile sync is one of Immich's biggest strengths. If uploads from phones are painless, the app becomes genuinely useful. If uploads are unreliable, trust disappears quickly. So after installation, do not just admire the web interface. Test the real workflow: take photos on a phone, let them upload, confirm they appear correctly, and verify how duplicates or organization behave.

You should also be realistic about project maturity and change. Immich has stabilized considerably since its early days, but it remains popular and fast-moving, which is exciting but also means operators should read release notes carefully. Rapid improvement is good, but it also means upgrades deserve more attention than they would for a sleepy utility app.

Access design matters too. A family photo library only feels trustworthy if login, sharing, and uploads are simple enough for normal users. Decide early whether the service is private to one account, shared inside a household, or available remotely to multiple people. Those choices affect authentication, storage growth, and support expectations more than the gallery layout ever will.

Who should use Immich?

Immich is a strong fit for self-hosters who want a modern private photo experience, especially if they value mobile backup and a polished browsing interface. It is less appropriate for people who do not want to think about backups, storage expansion, or update discipline. In that case, a managed provider may still be the safer home for irreplaceable memories.

My recommendation is to deploy Immich only if you are willing to treat it like important infrastructure. Give it durable storage, automate backups, test mobile uploads, and plan for growth before the library gets large. If you do that, it can become one of the most satisfying self-hosted services you run.

That satisfaction comes from more than avoiding vendor lock-in. A good self-hosted photo library gives you continuity. Your memories are organized where you want them, backed up the way you choose, and not subject to product decisions you did not make. For many people, that is worth the extra responsibility.