Hoeveel RAM en schijfruimte heeft Immich nodig?

Hoeveel RAM heeft Immich nodig?

Immich vereist 6 GB RAM (random access memory) als gedocumenteerd minimum en 8 GB als aanbeveling, op 2 CPU-cores aan de onderkant en 4 voor een comfortabele installatie. Dit cijfer heeft betrekking op de gehele stack, aangezien Immich uit vier containers bestaat in plaats van één enkele applicatie. Het bladeren door een reeds geïmporteerde bibliotheek is licht qua belasting. Het geheugenverbruik vindt plaats tijdens het importeren, en het grootste deel daarvan wordt verbruikt door één container die u kunt uitschakelen.

[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

Dit zijn de gepubliceerde cijfers van de Immich-vereistenpagina per augustus 2026. Het is een aanbeveling voor de dimensionering, geen controle of de software bij het opstarten draait. Immich start ook met minder. Wat verandert op een kleinere server is welke achtergrondtaken worden voltooid en wat een import doet wanneer het geheugen opraakt.

Er bestaat één echte harde limiet. Immich versie 3 en later vereist een x86-64-v2 CPU op amd64-hosts, wat de meeste processors dekt die sinds ongeveer 2012 zijn verkocht. Op oudere hardware start de container niet in plaats van dat deze traag draait.

Als de installatie nog moet plaatsvinden, begin dan met de volledige Immich-installatie op een VPS met Docker Compose en keer hier terug om de servergrootte te bepalen.

Waar het geheugen blijft: vier containers

Het officiële Compose-bestand start vier services. Elke service heeft een ander geheugenprofiel, waardoor één totaalcijfer de relevante details verbergt.

immich-server bedient de webinterface en de API, en voert tevens de achtergrondtaken uit. Twee workers bevinden zich in die ene container. api beantwoordt verzoeken van de browser en de mobiele app. microservices beheert de wachtrijen, inclusief het genereren van miniaturen en het coderen van video's. De variabelen IMMICH_WORKERS_INCLUDE en IMMICH_WORKERS_EXCLUDE splitsen deze twee in afzonderlijke containers; op die manier kunt u de intensieve helft een eigen geheugenlimiet geven zonder de helft die uw foto's serveert te beperken.

database is een PostgreSQL 14-image met de ingebouwde VectorChord-extensie. Deze bevat alle metadata en één zoekvector per asset. De documentatie van Immich geeft deze service als enige een expliciete ondergrens in de stack: als u Docker-resourcebeperkingen toepast, heeft de database minimaal 2 GB nodig. Dezelfde pagina stelt dat de database op lokale SSD-opslag moet staan en nooit op een netwerkshare, omdat vector- en index-lookups kleine willekeurige leesacties zijn. Een netwerkvolume verandert elke actie in een vertragende round-trip. Als een keuze voor een abonnement hiervan afhangt, is het verschil tussen NVMe- en SATA SSD-opslag op een VPS hier belangrijker dan waar dan ook in deze stack.

redis draait de Valkey-image en beheert de wachtrijen voor taken. Dit is veruit de kleinste van de vier, omdat het taakrecords opslaat in plaats van fotodata.

immich-machine-learning is de service die de omvang van uw plan bepaalt. Deze laadt modellen voor slim zoeken, gezichtsherkenning en tekstherkenning, en een geladen model blijft in het geheugen aanwezig. MACHINE_LEARNING_MODEL_TTL staat standaard op 300, waardoor een model na vijf minuten zonder verzoeken wordt verwijderd en bij het volgende verzoek opnieuw wordt ingelezen vanaf het /cache-volume. Tijdens een bulkimport is er nooit een pauze van vijf minuten, waardoor de modellen van de eerste tot de laatste asset geladen blijven.

Wat verandert er tijdens een import

Een inactieve Immich-instantie is stil. Imports zijn het moment waarop kleine servers bezwijken, omdat het uploaden van één asset een keten van taken in de wachtrij plaatst en er meerdere wachtrijen tegelijkertijd draaien.

Het extraheren van metadata leest de bestandsheader en is licht. Het genereren van thumbnails is zwaarder. Immich produceert drie thumbnail-outputs per asset: een wazige thumbhash-placeholder, een WebP-preview en een JPEG-thumbnail, plus nog een extra thumbnail voor elk gedetecteerd gezicht. Elk van deze taken decodeert een afbeelding, en de taak-concurrency bepaalt hoeveel er tegelijkertijd worden gedecodeerd. Concurrency is de vermenigvuldiger die de geringe kosten per taak omzet in een belasting voor de gehele server; daarom noemt de Immich FAQ dit als het eerste wat u moet verlagen op een systeem met beperkte middelen. Stel de concurrency voor de zware wachtrijen in op 1 onder Administration, Settings, Job Settings.

Video-assets voegen transcodering toe. Elke transcode-taak is een afzonderlijk FFmpeg-proces met eigen geheugengebruik, en het zal elke CPU-thread gebruiken die u toestaat.

Smart search stuurt elke nieuwe asset naar de machine learning-container om één embedding-vector te berekenen. Gezichtsdetectie voert een tweede model uit over dezelfde afbeelding. Bij de eerste import van een bestaande fotobibliotheek draaien beide wachtrijen urenlang over elke asset die u bezit. Dat is het meest kritieke moment voor het geheugengebruik van de gehele installatie, en dit gebeurt slechts één keer.

Waarom gezichts- en objectherkenning het meeste RAM vereisen

Het verwerken van gezichten bestaat uit twee taken. Gezichtsdetectie voert een model uit in de machine learning-container en bepaalt de kaders. Gezichtsherkenning groepeert deze detecties vervolgens in personen, waarbij deze stap de vectorindex in Postgres bevraagt. Een grote bibliotheek belast beide services na elkaar: de modelcontainer tijdens de detectie, en de database tijdens het groeperen.

Vier instellingen bepalen wat de machine learning-container in het geheugen houdt.

• Het gezichtsmodel. Immich levert standaard buffalo_l mee, en de FAQ adviseert buffalo_s voor een kleine server. Dit is een kleiner model, waardoor het minder geheugen inneemt en sneller draait, ten koste van de nauwkeurigheid bij kleine of zijwaartse gezichten.
• Het aantal workers. MACHINE_LEARNING_WORKERS staat standaard op 1. Elke worker is een afzonderlijk proces dat zijn eigen kopie van de modellen laadt; het verhogen naar 2 verdubbelt dus ruwweg het resident geheugengebruik van de modellen. Laat dit op 1 staan, tenzij u RAM over heeft.
• De batchgrootte. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION begrenst hoeveel gezichten er tegelijk worden verwerkt. Een batch wordt in zijn geheel in het geheugen gehouden, dus een groepsfoto met veertig gezichten kost meer geheugen dan een portret.
• Welke modeltypen überhaupt actief zijn. Slim zoeken, gezichtsdetectie en tekstherkenning laden elk hun eigen modellen. Door de functies die u niet gebruikt uit te schakelen onder Administration, Settings, Machine Learning Settings, wordt het geheugengebruik hiervan permanent verwijderd in plaats van alleen tussen imports door.

Er is ook MACHINE_LEARNING_MODEL_ARENA, gedocumenteerd als het vooraf toewijzen van CPU-geheugen om fragmentatie te voorkomen; dit staat standaard aan. Wijzig dit als laatste. Het effect hangt af van de onderliggende geheugenallocator, dus de enige betrouwbare manier om dit te beoordelen is door docker stats voor en na de wijziging te monitoren.

Drie uitgewerkte profielen: 2 GB, 4 GB en 8 GB

[
  {
    "label": "2 GB VPS",
    "server_limit_mb": 768,
    "db_limit_mb": 768,
    "ml_limit_mb": 0,
    "redis_limit_mb": 128,
    "notes": "machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 1280,
    "ml_limit_mb": 1024,
    "redis_limit_mb": 192,
    "notes": "machine learning on, job concurrency 1, buffalo_s"
  },
  {
    "label": "8 GB VPS",
    "server_limit_mb": 2048,
    "db_limit_mb": 2048,
    "ml_limit_mb": 2560,
    "redis_limit_mb": 256,
    "notes": "everything on at default settings"
  }
]

Beschouw deze waarden als limieten die u in Compose invoert, niet als metingen van wat Immich daadwerkelijk verbruikt. Een limiet is een bovengrens. Het reserveert niets en maakt een service niet kleiner. Het bepaalt welke service de kernel beëindigt wanneer het systeem zonder geheugen komt te zitten; dat is een beslissing die u beter zelf kunt nemen dan de kernel op basis van zijn eigen scoring.

De 2 GB-server: verwijder de machine learning-container

2 GB ligt onder het gedocumenteerde minimum van 6 GB, dus dit is een compromis en het is belangrijk dit als zodanig te benoemen. Zet de gehele immich-machine-learning-service in docker-compose.yml in de commentaarstand, of laat deze draaien en schakel elk model uit onder Administration, Settings, Machine Learning Settings. Het verwijderen van de container is de betere optie, omdat een uitgeschakeld model nog steeds een Python-proces in het geheugen houdt.

U behoudt uploads, albums, delen, mobiele back-ups, miniaturen en zoeken op datum, locatie en bestandsnaam. U verliest het zoeken op beschrijving, het automatisch groeperen van gezichten in personen en tekstherkenning in afbeeldingen.

De vier limieten tellen op tot ongeveer 1,7 GB, wat de host ongeveer 300 MB overlaat. Merk op dat 768 MB voor de database onder de gedocumenteerde ondergrens van 2 GB ligt. Dat is precies het compromis dat 2 GB afdwingt, en daarom is Postgres de service die hier het meest waarschijnlijk wordt beëindigd.

Wat als eerste faalt is het importeren, niet het browsen. Een bibliotheek met enkele tienduizenden foto's is acceptabel te doorzoeken zodra deze is ingeladen, omdat het tonen van een pagina een metadata-query plus een bestandlezing is. Een import met veel video's op dezelfde server zal leiden tot swapping, omdat een transcode- en miniatuurwachtrij op hetzelfde moment geheugen vereisen. Stel elke zware wachtrij in op concurrency 1 en voeg een swap-bestand toe.

De 4 GB-server: machine learning aan, één taak tegelijk

4 GB is de kleinste omvang waarbij gezichts- en objectherkenning de moeite waard zijn om in te schakelen. Begrens de machine learning-container op 0 MB, schakel gezichtsherkenning naar buffalo_s en stel de taak-concurrency in op 1 voor het genereren van miniaturen, gezichtsdetectie en slim zoeken.

De eerste scan van een bestaande bibliotheek zal vele uren duren, en bij een grote bibliotheek meer dan een dag. Dit is eerder een CPU-beperking dan een geheugenbeperking, dus meer RAM zal dit niet versnellen.

Wat hier als eerste faalt, is de machine learning-container tijdens die eerste bulk-scan. Zonder limiet groeit deze terwijl een transcode-taak ook groeit, en de kernel beëindigt de grootste van de twee. U ziet Exited (137) in docker ps -a en een herstartende container, waarbij de wachtrij stilletjes verder achterloopt dan toen u voor het laatst keek.

De 8 GB-server: de gedocumenteerde aanbeveling

8 GB met 4 cores komt overeen met wat Immich aanbeveelt, en alles draait op de standaardinstellingen: slim zoeken, gezichtsdetectie, tekstherkenning en transcodering, op de standaard concurrency. Bibliotheken met meer dan honderdduizend assets draaien hier comfortabel, en de druk verschuift van geheugen naar schijfsnelheid, omdat de vectorindex en de metadata-query's zijn wat de database de hele dag doet.

Stel de limieten desondanks in. Op een server met ruimte voorkomen de limieten dat één uit de hand gelopen wachtrij de database mee omlaag trekt. Als u dit prijstechnisch vergelijkt met de kleinere opties, maakt wat een VPS daadwerkelijk kost per geheugencategorie het 8 GB-abonnement meestal de goedkoopste manier om niet meer te hoeven finetunen.

Geheugenlimieten per service instellen met Compose

Bewerk docker-compose.yml hiervoor niet. Dit bestand wordt bij elke upgrade overschreven door wget. Plaats de limieten in docker-compose.override.yml naast dit bestand, aangezien docker compose deze automatisch samenvoegt.

services:
  immich-server:
    deploy:
      resources:
        limits:
          memory: 1024M
  immich-machine-learning:
    deploy:
      resources:
        limits:
          memory: 1024M
          cpus: '1.5'
  database:
    deploy:
      resources:
        limits:
          memory: 1280M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

docker stats zou nu uw limiet in de kolom MEM USAGE / LIMIT moeten tonen in plaats van het totale geheugen van de host. Als de limietkolom nog steeds de volledige grootte van de host aangeeft, is het override-bestand niet ingeladen: controleer de bestandsnaam en voer docker compose config uit om het samengevoegde resultaat te bekijken.

Een te lage limiet verandert een trage service in een niet-functionerende service; verhoog deze dus als een container in een opstartcyclus terechtkomt. Meer informatie over de werking vindt u in geheugenlimieten per service instellen in Docker Compose, inclusief de reden waarom deploy buiten Swarm werkt met Compose v2.

De machine learning-container uitschakelen of verplaatsen

Op een kleine server is het verplaatsen van deze container de meest effectieve wijziging die u kunt doorvoeren. Immich ondersteunt het draaien van deze container op een andere machine. Maak dit bestand aan op de tweede host, wat bijvoorbeeld een desktop kan zijn die alleen 's avonds aan staat:

name: immich_remote_ml
services:
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    restart: always
    ports:
      - 3003:3003
volumes:
  model-cache:

docker compose up -d
curl -s http://localhost:3003/ping

Ga vervolgens in de webinterface naar Administration, Settings, Machine Learning Settings, klik op Add URL en voer http://<host>:3003 in. Zorg dat de versie op beide hosts gelijk is, aangezien de documentatie van Immich waarschuwt dat versieverschillen tussen de twee leiden tot bugs en instabiliteit.

Deze poort verstuurt uw foto's onversleuteld naar de andere machine. Houd het verkeer daarom binnen een privénetwerk of laat het lopen via een WireGuard-tunnel tussen de twee hosts. Stel poort 3003 nooit bloot aan het internet.

Als het hele concept van een actieve model-container het probleem vormt, is dat een valide reden om te vergelijken hoe PhotoPrism en Immich verschillen in hun resourcegebruik in ruststand voordat u een definitieve keuze maakt voor de schaal van uw opstelling.

Hoeveel schijfruimte heeft een Immich-bibliotheek nodig?

Er is geen eenduidige vermenigvuldiger, omdat vier verschillende factoren in verschillende mate groeien. Hieronder volgt de berekening voor een bibliotheek met 50.000 foto's en 500 korte video's.

[
  {
    "label": "Originals: 50,000 photos at 4 MB",
    "gb": 200
  },
  {
    "label": "Originals: 500 videos at 120 MB",
    "gb": 60
  },
  {
    "label": "Thumbnails and encoded video at 15%",
    "gb": 39
  },
  {
    "label": "Postgres database",
    "gb": 3
  },
  {
    "label": "Machine learning model cache",
    "gb": 2
  }
]

De 200 GB aan foto's en 60 GB aan video zijn aannames. Vervang deze door uw eigen gemiddelden voordat u hardware aanschaft, aangezien video de doorslaggevende factor is: één minuut aan video van een telefoon is groter dan honderd foto's.

find /srv/immich/upload -type f -printf '%s\n' \
  | awk '{n++; s+=$1} END {printf "%d files, %.1f MB average\n", n, s/n/1048576}'

De rij van 39 GB is de enige gepubliceerde verhouding die Immich hanteert: gegenereerde thumbnails en getranscodeerde video voegen gemiddeld 10 tot 20 procent toe aan de omvang van de bibliotheek. Dit is een bereik omdat het afhangt van hoeveel van uw bestanden video's zijn die opnieuw moeten worden gecodeerd voor browsercompatibiliteit. Een bibliotheek met JPEGs valt aan de onderkant van dit bereik.

De database is 3 GB, wat nagenoeg een vaste waarde is. Immich documenteert databasebestanden doorgaans als 1 tot 3 GB, omdat deze metadata en zoekvectoren bevatten in plaats van pixels. De model-cache is 2 GB en groeit als u meerdere modellen inschakelt of verschillende modellen test. De FAQ markeert dit volume om precies die reden als een ruimteverbruiker.

De vijf rijen tellen op tot iets meer dan 300 GB, dus een volume van 500 GB biedt ruimte voor groei, terwijl een volume van 250 GB dat niet doet. Monitor de verdeling met:

grep UPLOAD_LOCATION .env
du -sh /srv/immich/*

Zes mappen bevinden zich onder UPLOAD_LOCATION. upload en library bevatten de originelen, thumbs bevat previews en gezichts-thumbnails, encoded-video bevat opnieuw gecodeerde kopieën, profile bevat avatars en backups bevat automatische database-dumps. Alleen upload, library en profile zijn onvervangbaar, aangezien al het overige daaruit opnieuw kan worden gegenereerd.

Twee zaken verrassen gebruikers vaak. Verwijderde bestanden gaan eerst naar de prullenbak en blijven ruimte innemen totdat de prullenbak wordt geleegd; een grote opschoonactie levert dus op de dag zelf geen extra ruimte op. Daarnaast bevat een database-dump alleen metadata en is deze waardeloos zonder de bijbehorende bestanden:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

Combineer dit met een kopie op bestandsniveau van de originelen naar een locatie buiten de server, waarvoor restic-back-ups van een VPS naar externe opslag bedoeld zijn.

Transcoding verbruikt CPU, geen RAM

Het toevoegen van RAM versnelt transcoding niet. Immich voert transcoding uit met FFmpeg en op een standaard VPS wordt elk frame gedecodeerd en gecodeerd door de CPU. Zelfs wanneer hardwareversnelling beschikbaar is, documenteert Immich dat alleen het coderen wordt versneld; de CPU voert dus nog steeds softwarematige decodering en tone mapping uit.

Hardwareversnelling vereist het extra hwaccel.transcoding.yml Compose-bestand en een apparaat om door te geven, waarbij gebruik wordt gemaakt van NVENC, Quick Sync, RKMPP of VAAPI. De meeste VPS-abonnementen bieden geen van deze opties, dus houd rekening met de CPU-belasting.

De praktische instelling is het aantal threads. Onder Administration, Settings, Video Transcoding Settings betekent een thread-waarde van 0 dat alle cores worden gebruikt, waardoor één video de webinterface kan laten vastlopen op een abonnement met 2 cores. Stel dit in op 1 of 2, zoals de Immich FAQ adviseert, zodat een transcode traag wordt in plaats van verstorend.

Waarom swap thrashing eruitziet als een vastloper

Dit is de fout die het vaakst verkeerd wordt geïnterpreteerd. Wanneer Immich onvoldoende geheugen heeft, zijn er twee uitkomsten, en slechts één daarvan ziet eruit als een fout.

Zonder swap beëindigt de kernel een proces. De container herstart binnen enkele seconden, waardoor de takenwachtrij vanuit de browser simpelweg stagneert en vervolgens hervat. Het bewijs staat in docker ps -a:

docker ps -a --filter name=immich
docker inspect immich_machine_learning | grep -i oomkilled
sudo dmesg -T | grep -i -E 'out of memory|oom-kill'

Exited (137) betekent dat het proces werd beëindigd met signaal 9. 137 is 128 plus 9. Een OOMKilled-waarde van true bevestigt dat het proces werd beëindigd vanwege geheugengebrek in plaats van een crash.

Met swap wordt er niets beëindigd en treden er geen fouten op. De kernel begint geheugenpagina's naar de schijf te verplaatsen, de import vertraagt aanzienlijk en de webinterface reageert niet meer binnen de normale time-out. Elke container draait nog steeds. Elke health check kan nog steeds slagen. Het lijkt op een vastloper, en gebruikers herstarten op dit punt de server, waardoor de voortgang van de wachtrij verloren gaat en er niets verandert.

free -m
vmstat 1 5

Aanhoudende waarden die niet nul zijn in de kolommen si en so van vmstat betekenen dat de machine continu swap leest en schrijft; dit is de definitie van thrashing. De free -m-rij voor Swap used zal op hetzelfde moment oplopen.

Voeg hoe dan ook swap toe op een machine met 2 GB of 4 GB geheugen, omdat een trage import die u kunt diagnosticeren beter is dan een beëindigde container die u niet kunt herstellen:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Los daarna de oorzaak op. Verlaag de job concurrency naar 1, beperk de machine learning-container of verplaats deze naar een andere host. Swap geeft u de tijd om dit te doen. Het is op zichzelf niet de oplossing.

FAQ

Kan ik Immich draaien op een 2 GB VPS?

Ja, mits de immich-machine-learning-service is uitgeschakeld in docker-compose.yml en de job-concurrency is ingesteld op 1. Dit is minder dan de gedocumenteerde vereiste van 6 GB, dus beschouw dit als een bewuste beperking. U behoudt de functies voor uploads, albums, delen, mobiele back-ups en zoeken op datum, locatie en bestandsnaam. U verliest de mogelijkheid om te zoeken op beschrijving, het automatisch groeperen van gezichten in personen en tekstherkenning in afbeeldingen. Voeg een swap-bestand van 2 GB toe zodat een piek in de import de server vertraagt in plaats van dat een container wordt beëindigd.

Waarom stopt mijn Immich-import zonder foutmelding?

Twee verschillende oorzaken zien er in de browser identiek uit. Ofwel een container is beëindigd vanwege een geheugentekort, waarbij docker ps -a de status Exited (137) toont en de container al opnieuw is opgestart, of de host gebruikt swap, waardoor elke container nog wel draait maar alles extreem traag verloopt. vmstat 1 5 maakt het onderscheid: aanhoudende waarden die niet nul zijn in de kolommen si en so duiden op swap-gebruik. Verlaag in beide gevallen de job-concurrency voor het genereren van miniaturen, gezichtsherkenning en slim zoeken.

Wat betekent exitcode 137 in de Immich-logs?

137 is 128 plus signaal 9, wat betekent dat het proces is beëindigd met SIGKILL. In de praktijk betekent dit dat een geheugenlimiet is bereikt, hetzij de limiet van de container zelf, hetzij het geheugen van de host. Controleer dit met docker inspect immich_machine_learning | grep -i oomkilled. Een waarde van true bevestigt dat de kernel het proces heeft beëindigd vanwege geheugengebrek, en free -m plus sudo dmesg -T | grep -i oom-kill vertelt u vervolgens of dit de containerlimiet was of de gehele host. De machine learning-container is meestal het slachtoffer omdat dit doorgaans het grootste proces is.

Hoeveel schijfruimte heeft Immich nodig per foto?

Houd rekening met het originele bestand plus 10 tot 20 procent. Immich documenteert dat gegenereerde miniaturen en getranscodeerde video de bibliotheekgrootte met gemiddeld 10 tot 20 procent vergroten, en de database zelf is doorgaans 1 tot 3 GB, zelfs bij een grote bibliotheek. Video is de bepalende factor voor uw totale opslagbehoefte; meet daarom uw eigen gemiddelde bestandsgrootte voordat u een abonnement kiest, in plaats van een vermenigvuldigingsfactor toe te passen op het aantal foto's.

Heb ik een GPU nodig voor Immich?

Nee. Elk onderdeel van Immich draait op de CPU. Een videokaart versnelt de model-inferentie in de machine learning-container en de video-encoding, maar geen van beide is vereist. De meeste VPS-abonnementen bieden geen GPU aan. Op hardware die alleen op CPU draait, stelt u het aantal transcoding-threads in op 1 of 2, gebruikt u het buffalo_s-gezichtsmodel en laat u de eerste bulk-import 's nachts draaien.