Immich is the self-hosted answer to Google Photos: your own server, your own disks, a mobile app that backs up your camera roll. The install reads as if it takes five minutes, and mechanically it does. The decisions that determine whether you still have your photos in three years are all made in the file you edit before you run it.
What the official install actually is
Two downloads and one command. The documentation gives them verbatim:
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env
Note the asymmetry in that second line: the file is published as example.env and you save it as .env. Then, once the variables are filled in, the entire installation is docker compose up -d.
If that last command fails, the documentation names the usual cause before you have to search for it. It warns that if you get an error such as unknown shorthand flag: 'd' in -d, you are probably running the wrong Docker version, and that the correct form is docker compose with a space rather than the older docker-compose binary. It flags a second version trap separately: an error stating that can't set healthcheck.start_interval as feature require Docker Engine v25 or later, which it suggests working around by commenting out that line.
Both are version mismatches rather than mistakes in your file. Neither is worth an evening.
The two locations that decide whether you can recover
The compose file is short, but two of its variables are not interchangeable settings. They are the answer to "what do I back up" and "what will corrupt itself".
UPLOAD_LOCATION is described in the documentation as the location where your uploaded files are stored, and it tells you to populate it with your preferred location for storing backup assets. This is the directory that will hold every photo you ever upload. Choosing it casually is the most common way to end up with a library sitting outside every backup job you already run.
DB_DATA_LOCATION is the database, and the documentation attaches a hard constraint to it: network shares are not supported for the database. This is not a performance recommendation. Database engines rely on file locking and write ordering guarantees that network filesystems provide unevenly, and the failure mode is usually silent corruption discovered weeks later rather than a refusal to start.
The practical reading: your photo library can live on network storage if you accept it will be slower. The database directory stays on a local disk. And whatever you choose for the first one, write it down, because it is the path your backups have to include.
The warning the project puts on its own front page
Most self-hosting guides skip this, so it is worth quoting the project rather than paraphrasing it. The Immich repository carries, near the top, the line: "Always follow 3-2-1 backup plan for your precious photos and videos!"
That warning is doing something specific. It is not saying the software is unreliable. It is saying that running your own photo server is not itself a backup, and the people who wrote it know that self-hosters routinely believe otherwise. A single instance on a single machine holds exactly one copy of your library. A failed disk, a botched upgrade, an accidental delete or a mistyped path removes it, and there is no provider to ask.
The project is licensed AGPL-3.0, which is part of why you can audit and run it at all. It does not change the arithmetic of having one copy.
What self-hosting moves, and what it does not
Self-hosting is often described as the private option, full stop. It is more precise, and more useful, to say that it relocates trust rather than removing it.
What genuinely changes: no company holds your library, no provider can be legally compelled to hand it over, no terms of service can change under you, and there is no account to lose. For a lot of people that is the whole point, and it is a real gain.
What does not change by itself: encryption at rest on your own disks, physical security of the machine, keeping the thing patched, and having more than one copy. Those become your job the moment you take them from a provider. That is the trade, and it is a reasonable one to accept knowingly. It is a bad one to accept by accident because self-hosted was assumed to mean protected.
Want the private photo library without running the server? pCloud lifetime + Crypto
Swiss jurisdiction · Zero-knowledge with the Crypto add-on · One-time payment, no upgrades to maintain and no database to back up
Choosing honestly between the two
Self-host Immich if you want your photos on hardware you control, you are willing to own backups and updates, and the maintenance is something you find interesting rather than something you will resent in eight months.
Use a managed zero-knowledge service if what you actually wanted was for no company to be able to read your photos, without becoming the person on call when the disk fails. That outcome is available without a server, and choosing it is not a compromise on privacy so much as a different allocation of the same work.
The one answer that does not survive contact with reality is a single self-hosted instance with no second copy, which is precisely why the project says so itself before you install anything.
The install commands, the note that the environment file is published as example.env, the descriptions of UPLOAD_LOCATION and DB_DATA_LOCATION, the statement that network shares are not supported for the database, and the two Docker version errors are taken from the official Immich Docker Compose installation documentation. The 3-2-1 backup line and the AGPL-3.0 license are from the project's repository front page. Both were checked at the time of writing; verify against the release you are installing, since the compose file ships with each release. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.
Related guides
- Best cloud storage for photos - the managed side of the same question, including which services encrypt photos client-side.
- Self-hosted cloud storage - the same trade applied to files rather than photos, with Nextcloud, Seafile and ownCloud.
Frequently asked questions
- What do I actually need to download to install Immich?
- Two files, both published with each release. The documentation gives the commands directly: wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml and wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env. Note that the second one is published as example.env and you save it as .env. After filling in the variables, the whole install is a single command: docker compose up -d.
- Why does my docker compose command fail with an unknown flag error?
- You are almost certainly running the old standalone binary rather than the plugin. The documentation is explicit about this case: if you get an error such as unknown shorthand flag 'd' in -d, you are probably running the wrong Docker version, and the correct command is docker compose, with a space, not docker-compose with a hyphen. There is a second, unrelated version trap the docs mention: an error about healthcheck.start_interval requiring Docker Engine v25 or later, which they suggest working around by commenting out that line.
- Where do my photos actually end up on disk?
- Wherever you point UPLOAD_LOCATION, which the documentation describes as the location where your uploaded files are stored and tells you to populate with your preferred location for storing backup assets. This is the single most consequential line in the file, because it decides which directory you have to back up. Set it deliberately to a path you already protect, rather than accepting a default and discovering later that your library lives somewhere your backups never look.
- Can I put the database on my NAS?
- Not the database. The documentation states plainly that for DB_DATA_LOCATION, network shares are not supported for the database. Databases need consistent low-level file locking that network filesystems do not reliably provide, and ignoring this tends to produce corruption rather than a clean error. Your photo library can live on network storage if you accept the performance cost; the database directory should stay on a local disk.
- Is self-hosting Immich enough to keep my photos safe?
- The project itself says no, and it says so on its own front page: always follow 3-2-1 backup plan for your precious photos and videos. Running the server yourself changes who holds your library, it does not create a second copy of it. A self-hosted instance on a single machine is one disk failure, one bad upgrade or one mistaken delete away from total loss, which is exactly what the 3-2-1 rule exists to prevent.
Get pCloud
10-day money-back guarantee
