Quick Summary (TL;DR):
The safest way to run Immich on a NASAliExpress price is to use the current official Docker Compose release, keep PostgreSQL on a local SSD-backed filesystem, and put uploaded photos and videos on a NASAliExpress price dataset with enough room for growth. Immich currently specifies 6GB RAM minimum (8GB recommended) and 2 CPU cores minimum (4 recommended) for the application host. Start with CPU-based face recognition and video conversion; GPU acceleration is optional and needs separate configuration for machine learning and transcoding. If your NASAliExpress price cannot comfortably run the containers, run Immich on a Linux mini PCAliExpress price and use the NASAliExpress price for its media and backups—but never put its PostgreSQL data directory on SMB/NFS. Back up both the media files and the Immich database; automatic database dumps alone cannot restore your photographs. This guide uses current upstream documentation checked on 11 October 2026, not an unmaintained NAS-specific container recipe.
Should You Install Immich Directly on a NAS?
Immich is a self-hosted photo and video library with mobile uploads, a web timeline, search, facial recognition and optional video transcoding. The NAS can supply storage, application compute, or both. Those are different jobs: a fast disk array does not guarantee that the NAS processor has enough headroom for photo indexing, and a powerful mini PC does not replace a resilient backup destination.
Our recommendation: run the official Compose deployment directly on a compatible x86-64 or Arm64 NAS when it has sufficient RAM, an SSD-backed location for the database, and a supported container environment. Use a separate Linux host when the NAS is low-powered, its container platform is restrictive, or you want to keep AI indexing separate from storage duties. There is no need to buy a discrete GPU simply to serve a family photo library.
| Host option | Where Immich runs | Where photos live | When it makes sense | Main caveat |
|---|---|---|---|---|
| Capable NAS | Containers on NAS | NAS dataset | Single-box, simpler administration | CPU/RAM load shared with NAS services |
| Linux mini PC + NAS | Containers on mini PC | NAS media share or attached storage | Better compute headroom; reuse existing NAS | Database stays on mini PC local SSD; network mounts need reliable startup |
| Linux VM + NAS | Docker Compose inside Linux VM | Passed-through or mounted NAS storage | Isolation and familiar VM backups | Do not confuse a VM snapshot with a consistent photo/database backup |
| Lightweight NAS without containers | Not on NAS | NAS as storage/backup only | Existing low-power backup appliance | Needs separate supported Linux/VM host |
A family of four with years of phone pictures usually benefits more from dependable storage, a sensible backup plan and good network connectivity than from an expensive graphics card. The most expensive error is building an attractive gallery with no recoverable database or off-site copy.
Immich NAS Requirements: RAM, CPU, Operating System and Storage
The following are upstream Immich requirements, not a guarantee that a particular NAS model or vendor firmware supports every container feature. Check the NAS maker’s supported architecture, available memory, container package and storage permissions before buying hardware.
| Component | Immich documentation | Practical implication |
|---|---|---|
| CPU | 2 cores minimum; 4 recommended | Allow spare CPU time for imports, thumbnails and other NAS jobs. |
| RAM | 6GB minimum; 8GB recommended | A 4GB NAS is below the published minimum, even if a community recipe appears to start. |
| Architecture | amd64 and arm64 | Check the actual processor/OS image, not just a product-family name. |
| Operating system | 64-bit Linux/*nix recommended | A Linux VM is a reasonable alternative; Docker inside LXC is not the recommended route. |
| Containers | Docker Engine with Compose plugin | Use docker compose, not legacy docker-compose. |
| PostgreSQL | Local filesystem, ideally SSD | Never use an SMB or NFS share for DB_DATA_LOCATION. |
| Media storage | Capacity for originals, generated files and backups | HDD pools can be sensible for bulk photos; plan for thumbnails and video derivatives. |
Immich’s requirements page notes that PostgreSQL files are often around 1–3GB, but this is guidance, not a fixed limit or an excuse to allocate only 3GB. Database growth depends on the library and features. If you impose container memory limits, its database container also needs sufficient memory; the official documentation specifies at least 2GB for PostgreSQL under resource limits.
An 8GB NAS with other active applications has less than 8GB available to Immich. Check actual free RAM and swap activity. During an initial import, image processing and machine learning can make a marginally specified machine feel much slower than ordinary browsing.
How to Lay Out Immich Storage Before You Install
The single most important design choice is separating the application database from the original photos. The database holds file paths, album relationships and other metadata. The originals are the irreplaceable files. Immich also produces thumbnails, video transcodes and machine-learning model caches that can be regenerated or redownloaded, at a cost in time and bandwidth.
| Data | Recommended location | Back up? | Why |
|---|---|---|---|
PostgreSQL live data (DB_DATA_LOCATION) | Local SSD filesystem on the container host | Use consistent database dumps; optional additional host protection | Network shares are not supported for the live database. |
Uploaded originals (UPLOAD_LOCATION) | Protected NAS dataset / local volume | Yes, essential | Includes original user-uploaded media. |
| External photo library | Separate existing NAS photo dataset, mounted read-only | Yes, separately | An external library is not copied into the managed upload folder. |
| Thumbnails / encoded video | Within upload location unless deliberately overridden | Prefer full backup; can be regenerated | Saves lengthy processing after recovery. |
| Automatic database dumps | Under UPLOAD_LOCATION/backups by default | Yes, copy off-box | Dumps do not include photos. |
Compose file and .env | Restricted application configuration folder | Yes, securely | Contains deployment settings and database password. |
| Machine-learning model cache | Local application storage | Usually optional | Can be fetched again, but needs free disk space. |
The official Compose file maps the host UPLOAD_LOCATION to the container’s managed media path. Do not rename or manually reorganise the internal upload/, library/, profile/ or thumbs/ directories. Immich tracks its files in the database; changing them behind its back can produce missing assets. Use Immich’s interface and documented storage-template controls for application-managed changes.
For a NAS running Immich directly, a practical design is an SSD-backed application volume for PostgreSQL and a large protected media volume for originals. For a mini PC, the local SSD holds PostgreSQL and Compose; the NAS holds media or an external read-only library. If a network mount is used for managed uploads, test reconnection and boot ordering carefully, because a missing mount can leave an apparently empty local directory in its place.
Install Immich on a NAS with the Official Docker Compose Files
These commands target a Linux shell with a working Docker Engine and Compose plugin. On Synology or QNAP you may use the vendor’s project/stack interface with the same upstream files instead; see the platform notes below. Do not paste a random all-in-one Compose file from an old tutorial: the Immich PostgreSQL image, dependencies and required environment can change across releases.
Step 1: Prepare the NAS and Application Directories
- Confirm your NAS can run containers and has enough spare memory; check the exact model against its vendor’s package support list.
- Create a dedicated media dataset/share with a backup policy, plus a separate local SSD-backed directory for the live database.
- Use a dedicated administrator account for the initial deployment; keep the configuration directory private to the NAS administrator.
- Check free space, NAS filesystem permissions, and that TCP port 2283 is not already in use.
- Create a backup of any existing photos before mounting or importing them into Immich.
The paths below are illustrative Linux paths, not universal NAS locations. Replace them with valid locations for your system. A Synology path might be under /volume1/; a TrueNAS dataset has a different path. Do not put the PostgreSQL folder inside a network-mounted share.
sudo mkdir -p /srv/immich/app
sudo mkdir -p /srv/immich/postgres
sudo mkdir -p /srv/immich/media
cd /srv/immich/app
# Verify where these directories actually reside:
df -T /srv/immich/postgres /srv/immich/media
The directory-creation commands do not grant access to the containers. Permissions and ownership depend on the host filesystem, Docker daemon and NAS ACLs. Avoid making the media tree world-writable as a quick fix; follow the NAS vendor’s container permissions guidance instead.
Step 2: Download the Current Official Release Files
Immich maintains a Compose file and a matching environment example in each release. Download both from the same latest release; using an old Compose file with a new application image is a common source of upgrade trouble.
cd /srv/immich/app
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
# Inspect before editing; do not publish .env online.
ls -la docker-compose.yml .envThese commands are from the official Immich Docker Compose installation guide. They fetch the current maintained configuration rather than embedding a potentially obsolete database image tag in this article.
Step 3: Edit .env for Your Storage and Credentials
Open .env and set the host paths. Keep the rest of the downloaded file intact unless the official instructions say otherwise. The following illustrates the fields to edit, not a complete replacement .env file.
# Example host-side settings — edit in the downloaded .env
UPLOAD_LOCATION=/srv/immich/media
DB_DATA_LOCATION=/srv/immich/postgres
TZ=Europe/London
DB_PASSWORD=REPLACE_WITH_RANDOM_ALPHANUMERIC_PASSWORD
# Retain the IMMICH_VERSION value supplied by the
# current matching official example.env file.Before starting: replace the password placeholder with a long random alphanumeric value. The official instructions recommend A–Z, a–z and 0–9 only to avoid Compose parsing surprises. Keep .env private: it contains secrets. The TZ value is an example; choose the timezone where you operate the server.
Do not put DB_DATA_LOCATION on //nas/share, /mnt/nas, an SMB mount or an NFS mount—even if the media folder is there. If your NAS cannot provide suitable local PostgreSQL storage, host the application and database on a separate Linux machine instead.
Step 4: Validate and Start the Stack
cd /srv/immich/app
docker compose version
docker compose config --quiet
docker compose up -d
docker compose ps
# Investigate failures without exposing your .env:
docker compose logs --tail=100 immich-serverIf docker compose config --quiet is unsupported by your installed plugin version, run docker compose config locally but do not paste its output publicly: it may resolve and display secrets. The official Compose stack starts the application, database and supporting services. Wait for the first start to finish downloading images and initialising the database.
Open http://NAS-LAN-IP:2283 from a computer on your trusted local network. The first account created becomes the administrator. Create a strong password, configure users, and test uploading one disposable photo before importing a whole archive. Do not expose port 2283 directly to the internet as a shortcut for mobile access.
Step 5: Check Storage, Jobs and a First Phone Backup
- Upload a small test photo from the browser. Confirm that it appears in the timeline and survives a container restart.
- In Administration, inspect the Jobs/Job Queues area for thumbnail, metadata and machine-learning activity. Names and layout can change by release.
- Check that originals appear under the intended host media directory and that the PostgreSQL directory is on the intended local filesystem. Do not manually edit these files.
- Install the Immich mobile application, point it at the server’s trusted address and sign in. Choose which albums should be backed up.
- Take a new test photo, allow the app to upload it, and confirm the server has received the original before relying on background uploads.
Immich supports foreground and periodic background mobile backup, but mobile operating systems can delay background work. A successful setup should be checked in the app and server—not assumed because a backup toggle is on. For a family archive, keep another backup source until the initial upload, indexing and verification are complete.
Synology, QNAP, TrueNAS, Unraid and UGREEN: What Changes?
The Immich team labels several vendor-specific instructions as community guides. That means they can be useful, but should not be confused with the officially recommended Compose deployment. NAS firmware, supported container packages and storage permissions vary by model and version.
| NAS platform | Deployment path | Important checks |
|---|---|---|
| Synology DSM | Container Manager project using official Compose files | Confirm Container Manager support for your exact model; separate app/database/media volumes and check ACLs. |
| QNAP QTS / QuTS hero | Container Station application/Compose | Check architecture, permissions and the community guide’s platform-specific steps. |
| TrueNAS | Apps catalogue/community route or supported Linux VM | Check the current TrueNAS edition, dataset permissions, storage mappings and upgrade support. |
| Unraid | Community app/template or Compose Manager | Community templates can differ from upstream Compose; confirm database/image requirements and persistent paths. |
| UGREEN NASync | Model/firmware-dependent Docker/containers, if supported | Verify Docker availability and sufficient RAM on the exact NAS model; use upstream Compose where feasible. |
| Other NAS | Linux Docker host plus NAS media/backup | Avoid assuming every ARM NAS supports Immich’s published container architecture. |
Synology’s Container Manager overview confirms support for multi-container Compose projects, but the package is not available on every model. The official Immich Synology community guide and QNAP community guide explain their respective interfaces. Do not treat those community paths as a guarantee of vendor or Immich-team support.
If you already have a powerful mini PC, a strong alternative is to run Immich on Linux there and keep the NAS focused on bulk storage and backups. This makes it easier to upgrade the photo application independently, but adds a dependency on the network share and on correct mount ordering. For a read-only existing archive, an external library can be a particularly clean split.
Import Existing Photos Safely: Uploads Versus External Libraries
Immich offers two conceptually different ways to bring in photographs. Managed uploads are files copied into Immich’s own storage and tracked by its database. An external library points Immich at files you already organise elsewhere. Choose deliberately: pointing Immich at an existing archive does not turn that archive into an Immich-managed backup.
| Approach | Who manages originals? | Best use | Watch out for |
|---|---|---|---|
| Mobile/web/CLI upload | Immich | New phone photos; one managed family library | Keep originals until upload verification; preserve original metadata. |
| External library, read-only | Your NAS/filesystem | Existing organised photo tree, shared with other software | Database-only album edits may not persist to original files; external backup remains your responsibility. |
| External library, writable | Immich may modify/delete accessible files | Only when deliberate editing is required | Higher risk to an established archive; require separate snapshots/backups. |
| Bulk import via supported CLI | Immich | Moving a large archive into managed storage | Use current CLI version; validate duplicates, EXIF and video handling. |
Example: Add a Read-Only NAS Photo Folder
On the Docker host, make sure the archive is mounted and readable first. Then add a read-only bind mount under the immich-server service’s volumes in the current Compose file. The snippet below shows only the extra line, not a complete service definition.
services:
immich-server:
# Keep all existing fields and mounts from upstream.
volumes:
- ${UPLOAD_LOCATION}:/data
- /mnt/nas/family-archive:/mnt/external-photos:roThis example assumes /mnt/nas/family-archive is an already mounted and verified host path. The mount must be available before the container starts. After saving the Compose file, run docker compose up -d to recreate affected containers. Then sign in as an administrator, open Administration → External Libraries, create a library, select its owner, add the import path /mnt/external-photos and start a scan.
Do not add the same directory both as UPLOAD_LOCATION and an external library. Do not remove :ro merely to silence a permission warning. Immich’s external-library documentation explains that a deleted file may be moved to trash on rescan and that some Immich-only metadata is stored in the database, not written back to the source. This is another reason database backups matter even for a read-only archive.
For a Google Photos Takeout migration, check filenames, EXIF timestamps, JSON sidecars and duplicate handling before bulk importing. The official Immich CLI can upload photos, while third-party Takeout migration tools have their own compatibility and metadata rules. Use a small representative sample first—live photos, videos, edited copies and photos without camera EXIF are good test cases.
How Much NAS Storage Does Immich Need?
Plan from the actual original data size, not from raw NAS disk capacity or a claim that an 8TB disk holds a particular number of photos. Phone videos can dominate space, and the size of generated video derivatives depends on codecs and transcoding settings. Your storage template and use of external libraries also affect where files reside.
For example, if a family has 1.4TB of photos and 0.6TB of videos, the current originals total 2.0TB. A planning allowance of 30% for growth would bring originals to 2.6TB. That is an illustrative capacity calculation, not a measured Immich overhead figure. Add further room for thumbnails, optional transcoded videos, temporary processing, snapshots and the NAS filesystem’s own free-space requirements. Then size an independent backup for that dataset.
| Storage item | Sizing method | What not to assume |
|---|---|---|
| Original media | Measure files already owned; project growth | Raw RAID size is not the same as used media. |
| Thumbnails and previews | Leave free space; inspect actual growth after indexing | No fixed percentage fits every photo/video collection. |
| Transcoded video | Depends on source codec, quality and settings | Hardware acceleration does not automatically mean smaller files. |
| PostgreSQL | Local SSD plus sensible headroom | A 1–3GB typical figure is not a capacity cap. |
| Snapshots and backups | Size by retention, changed data and off-site policy | RAID and snapshots do not replace a second copy. |
Do not overbuy NVMe cache for a photo library that is mostly sequential uploads and occasional browsing. A dedicated SSD-backed database and adequate RAM are often a more defensible first upgrade. If your NAS is already full, address capacity and backup integrity before enabling extra derived-video generation.
Hardware Acceleration: Machine Learning Is Not Video Transcoding
Immich has two separate acceleration paths. Machine-learning acceleration targets tasks such as smart search and facial recognition. Hardware video transcoding uses video encoders and decoders for compatibility copies. Enabling one does not automatically enable the other, and the GPU must be exposed to the correct container.
| Task | Typical backend / hardware | Configured in | Important caveat |
|---|---|---|---|
| Smart search and face recognition | OpenVINO on supported Intel GPUs; CUDA on supported NVIDIA GPUs; ROCm on supported AMD GPUs; ARM NN/Mali; RKNN/Rockchip | Machine-learning service | Experimental; not every model/backend combination works. |
| Video transcoding | Intel Quick Sync; NVIDIA NVENC; VAAPI on supported Intel/AMD/NVIDIA; RKMPP on Rockchip | Immich server + admin video settings | Codec support varies; acceleration can trade compression efficiency for speed. |
| CPU processing | Ordinary supported CPU | Default containers | No GPU passthrough required; initial indexing may take longer. |
A CPU that contains an Intel GPU is not a blanket guarantee of OpenVINO compatibility or Quick Sync support for every codec. Likewise, having a GPU physically present does not mean Docker can see it. The official machine-learning acceleration and video transcoding guides list backends, device requirements and limitations. Treat their current compatibility lists as authoritative rather than relying on an old NAS model comparison.
Enable Hardware Video Transcoding Only If You Need It
- First confirm that Immich works without acceleration and that a short test video plays.
- Check the exact GPU and video codec capabilities, including whether the host kernel exposes the device.
- Download the
hwaccel.transcoding.ymlmatching your current Immich release, following the official guide. - In the upstream Compose file, enable the documented
extendsblock for theimmich-serverservice and select the correct backend; some NAS UIs need equivalent inline device settings. - Recreate the container, then select the matching hardware acceleration option in Administration → Video Transcoding.
- Queue a test video and inspect device utilisation and logs. Compare the resulting output visually; do not assume hardware encoding improves quality.
On many Linux Intel setups, GPU access involves /dev/dri. Check the host first:
ls -l /dev/dri
# If Intel GPU tools are installed, observe utilisation
# while a video is being transcoded:
intel_gpu_topDo not blindly add /dev/dri on a NAS where the path does not exist, or claim that every Intel NAS supports every Quick Sync mode. The Immich documentation notes that hardware transcoding is still experimental and can produce larger files at similar visual quality. It also says that hardware encoding is enabled by default while decoding and tone mapping may still use the CPU unless configured separately.
Enable Machine-Learning Acceleration Separately
For compatible GPUs, the official machine-learning procedure uses the release-matched hwaccel.ml.yml and a matching machine-learning image suffix such as -openvino, -cuda, -rocm, -armnn or -rknn. The appropriate extends configuration must be enabled on immich-machine-learning. The details differ by backend, so copy the current release instructions rather than a static Compose fragment.
After deployment, trigger a small smart-search or face-detection job. Check the machine-learning container logs for the relevant execution provider and monitor actual device utilisation. For example:
docker compose logs --tail=150 immich-machine-learning
# Look for the selected execution provider while a job runs.
# No GPU use? Verify image suffix, device mapping and drivers.Machine-learning models consume RAM and disk cache. If a NAS struggles, first reduce simultaneous indexing work or use CPU mode while the library settles. An alternative is a separate compatible compute host for machine learning; that requires correct networking and configuration and should not be confused with relocating the PostgreSQL database.
A Reliable Immich Backup Plan: Files Plus Database
Immich is not itself your backup. Its automatic database dumps are useful, but the official documentation is explicit: those dumps do not contain photos or videos. Conversely, a plain copy of the photo folders is not enough to recover album memberships, users and other database-only information. Protect both, with consistent retention and an off-site copy.
| Backup component | What to capture | Recommended frequency logic | Restore consequence if missing |
|---|---|---|---|
| Original uploads | Full managed UPLOAD_LOCATION, or at least original-bearing folders | Daily or aligned to photo uploads | Missing irreplaceable media. |
| Immich database | Built-in database dump under backups/ plus off-box copy | Built-in daily schedule; adjust to acceptable metadata loss | Lost users, albums, paths and metadata. |
| External libraries | Original source datasets independently | Match source change rate; snapshot plus second copy | External assets cannot be restored by Immich alone. |
| Compose and .env | Versioned deployment config, stored securely | After each configuration change | Harder to recreate paths, credentials and versions. |
| Generated previews and transcodes | Prefer entire media directory when practical | Can be regenerated; backup saves time | Slow reprocessing after recovery. |
Current Immich documentation says built-in database backups are created daily at 02:00 by default and the default retention is the latest 14 dumps; both are configurable in Administration → Settings → Backup. Confirm the schedule in your own version. Copy those dumps to a different failure domain—a separate NAS, offline USB drive or appropriate cloud destination—because a dump sitting on the same failed volume is not protection.
Use the familiar 3-2-1 principle: three copies of important data, on at least two types of storage, with one copy off-site. A RAID mirror is availability, not a separate backup. NAS snapshots can help with accidental deletion and ransomware recovery but should complement, not replace, an independent copy.
Example Backup and Restore Drill
- Choose a quiet window after the initial import has finished. Trigger a database dump from the administration job interface and confirm the backup file exists.
- Take a consistent filesystem backup or snapshot of
UPLOAD_LOCATION, includingbackups/. Separately protect any external-library source datasets. - Copy both the dump and media backup off the primary NAS. Record the Immich version and save the matching Compose and environment files securely.
- On an isolated test host, provision the same release and restore the media paths. Keep the same container mount structure for external libraries.
- Use the documented Restore from backup onboarding or administration flow with a compatible database dump; follow its integrity checks.
- Verify representative originals, album memberships, users, dates, faces, videos and external-library visibility. Only then mark the recovery plan as tested.
Important: restoring a database can replace current application state. Never practise a restore on the only working production instance. Immich’s documented restore process may require a fresh installation and, in some command-line scenarios, special handling to avoid database migration conflicts. Follow the version-specific official backup and restore guide; do not delete a live PostgreSQL directory simply because a generic tutorial says to do so.
A practical retention policy might combine daily database dumps, frequent media snapshots, a weekly second-NAS copy and an offline or cloud copy. The right interval depends on how many new photos arrive and how much loss you could tolerate. A restored library should be checked with both recent uploads and older, rarely viewed photos—not just the front page.
Updating Immich Without Breaking Your Photo Library
Immich releases can change deployment requirements, database extensions and compatibility expectations. Back up first, read the release notes, then update the release-matched Compose stack. If you pin IMMICH_VERSION, deliberately select a supported release; if you follow a major-version tag, understand that it can move to newer minor versions.
cd /srv/immich/app
# 1. Back up media, database dumps, .env and Compose.
# 2. Read release notes and update release files if required.
# 3. Then, using the matching configuration:
docker compose pull
docker compose up -d
docker compose psThe Immich upgrade guide states that downgrades are not supported and that mobile clients should be compatible with the server’s major version. Do not assume that reverting only a Docker image tag is a safe rollback after database migrations. Preserve a consistent pre-upgrade database and media backup, and test upgrades on a copy when the library is important.
Keep Immich Private: Local Access, HTTPS and Remote Use
For initial setup, use the LAN address. For remote use, prefer a properly configured VPN such as WireGuard or Tailscale, or a carefully maintained HTTPS reverse proxy with authentication and timely security updates. Do not forward the Immich service port to the public internet without a considered security design. If a reverse proxy is used, follow the official proxy guidance for headers, upload limits and timeouts.
Give each family member their own account where appropriate, avoid sharing administrator credentials, and protect the NAS and host OS with updates and strong authentication. Keep the .env file out of public repositories and general file shares. An external read-only photo mount reduces accidental modification risk, but it does not protect the separate Immich database or make the original archive an off-site backup.
Troubleshooting: The Most Common NAS Installation Problems
| Symptom | Likely checks | Safer next step |
|---|---|---|
| Containers restart or database fails | Is DB_DATA_LOCATION a local supported filesystem? Are permissions and free space correct? | Move to supported local SSD storage; follow official database recovery guidance. |
| Browser cannot open port 2283 | Compose status, NAS firewall, IP address, port collision | Check LAN connectivity and logs before changing router rules. |
| Photos appear, but thumbnails never finish | Jobs queue, memory pressure, media permissions, disk free space | Check service logs and process a small sample. |
| External library shows no files | Host mount exists? Container sees the path? Correct read access? | Verify the read-only bind mount and rescan. |
| Photos disappear after restart | Host media mount missing or wrong UPLOAD_LOCATION | Stop imports; correct mount path before writing more data. |
| ML GPU is idle | Wrong image suffix, unsupported backend, missing device/driver | Return to CPU mode; test backend with official ML guide. |
| Video conversion is slow | Hardware path not enabled or unsupported codec | Check FFmpeg logs, admin setting and actual GPU usage. |
| Phone background uploads are intermittent | Mobile OS battery/network restrictions and app permissions | Open the app periodically; confirm server-side uploaded counts. |
| Changes to .env have no effect | Containers were restarted, not recreated | Run docker compose up -d to apply changed environment. |
| Backups exist but restore lacks photos | Only PostgreSQL dumps were copied | Restore media and database together from independent backups. |
For a persistent issue, capture the exact Immich version, container logs, NAS OS/CPU architecture, storage paths without secrets and the failing step. That evidence is more useful than swapping container images at random. If you have edited the official Compose file heavily, compare it with the current release’s maintained example before troubleshooting an application bug.
What Should You Buy or Upgrade for Immich?
This is primarily a configuration and recovery guide, not a hardware roundup. If you are still selecting a NAS, prioritise supported containers, sufficient RAM, predictable storage permissions and an independent backup route. For detailed model comparisons see our Best NAS for Immich and Family Photo Backups guide.
| Your bottleneck | Upgrade to consider | What to verify first |
|---|---|---|
| NAS below 6GB RAM / no containers | Compatible higher-memory NAS or Linux mini PC | Published Immich minimums and vendor package support. |
| Database on slow disk | Small reliable SSD-backed local application volume | Filesystem and backup coverage; do not move live DB blindly. |
| Media capacity nearly full | Larger CMR NAS disks or additional bays | Actual used data, RAID/SHR expansion rules and backup capacity. |
| Slow first import / face indexing | More CPU/RAM; optional compatible GPU | Whether the job queue is already CPU- or memory-bound. |
| Videos fail to play smoothly | Supported transcoding path or capable client | Actual codec, client direct-play capability and host GPU access. |
| No independent copy of photos | Second NAS, external USB backup or off-site storage | Restore process and ongoing backup schedule before more compute upgrades. |
A useful cost comparison includes the NAS or mini PC, disks, SSD, RAM, network accessories, backup storage, UPS, electricity and your time maintaining updates. Immich itself being self-hosted does not remove these costs. Avoid shopping by claimed “AI TOPS” alone: it does not establish compatibility with Immich’s current acceleration backends.
Frequently Asked Questions
Can Immich use a NAS share for photos but keep the database on a mini PC?
Yes, that can be a sensible design. Keep the live PostgreSQL directory on the mini PC’s local SSD, and use a reliably mounted NAS share for media or an external library. Test permissions, startup ordering, loss of network access and recovery. Do not place PostgreSQL itself on SMB or NFS.
Is an SSD necessary for every Immich photo?
No. HDD-backed NAS storage is reasonable for bulk originals. Immich recommends local SSD storage for PostgreSQL, which is a different requirement. Thumbnails and model caches may also benefit from faster storage, but plan from actual load and available capacity.
Does Immich require an Intel CPU or NVIDIA GPU?
No. The published supported architectures include amd64 and arm64, and CPU processing is supported. Compatible GPUs can accelerate selected jobs, but machine learning and transcoding have separate requirements. Always verify the exact GPU and backend rather than assuming support from a brand name.
Will a NAS RAID mirror protect the Immich library?
A mirror can keep data available after one drive failure, depending on the array and failure mode. It cannot recover everything from accidental deletion, malware, fire, theft or an unusable database. Maintain an independent versioned backup and a tested restore procedure.
Are Immich automatic database backups enough?
No. They contain metadata and database state, not the original photos or videos. Copy both the database dumps and the relevant media folders to independent storage; include external libraries separately.
Can I move an existing photo archive into Immich without duplicating it?
An external library lets Immich index files in their existing location without copying them into its managed upload tree. Mount it read-only initially, and keep the archive’s own backup. Managed uploads and external libraries behave differently, particularly for deletion and metadata.
Can I install Immich on a 4GB Synology or QNAP NAS?
Immich’s current published minimum is 6GB RAM for the application host, so a 4GB system is below specification. Even if a community deployment starts, reliability and indexing performance are not assured. Consider a supported RAM upgrade or a separate Linux host.
Related NAS and Backup Guides
- Best NAS for Immich and Family Photo Backups — choosing compatible storage hardware
- A 3-2-1 NAS Backup Plan — building a recoverable photo archive
- How to Back Up One NAS to Another — second-copy strategies
- Best External Hard Drives for NAS Backups — offline rotation options
Official Documentation and Further Reading
- Immich — supported hardware, memory and database storage requirements
- Immich — official Docker Compose installation
- Immich — environment variables and storage paths
- Immich — external library setup
- Immich — external library behaviour and limitations
- Immich — hardware-accelerated machine learning
- Immich — hardware video transcoding
- Immich — database and filesystem backup/restore
- Immich — upgrading and release compatibility
- Immich — Synology community installation
- Immich — QNAP community installation
- Immich — TrueNAS community installation
- Immich — mobile backup behaviour