It's not normal for - model-cache:/cache to be deleted on restart or even upgrade. You shouldn't need to do this.
this post was submitted on 08 Jul 2025
105 points (97.3% liked)
Selfhosted
49386 readers
568 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Yes, it depends on how you're managing the service. If you're using one of the common patterns via systemd, you may be cleaning up everything, including old volumes, like I do.
E: Also if you have any sort of lazy prune op running on a timer, it could blow it up at some point.
Doing a volume like the default Immich docker-compose uses should work fine, even through restarts. I'm not sure why your setup is blowing up the volume.
Normally volumes are only removed if there is no running container associated with it, and you manually run docker volume prune
Because I clean everything up that's not explicitly on disk on restart:
[Unit]
Description=Immich in Docker
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
WorkingDirectory=/opt/immich-docker
ExecStartPre=-/usr/bin/docker compose kill --remove-orphans
ExecStartPre=-/usr/bin/docker compose down --remove-orphans
ExecStartPre=-/usr/bin/docker compose rm -f -s -v
ExecStartPre=-/usr/bin/docker compose pull
ExecStart=/usr/bin/docker compose up
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
But why?
why not just down up normally and have a cleanup job on a schedule to get rid of any orphans?
But why?
I a world where we can't really be sure what's in an upgrade, a super-clean start that burns any ephemeral data is about the best way to ensure a consistent start.
And consistency gives reliability, as much as we can get without validation (validation is "compare to what's correct", but consistency is "try to repeat whatever it was").
Wow, you pull new images every time you boot up? Coming from a mindset of having rock solid stability, this scares me. You're living your life on the edge my friend. I wish I could do that.
I use a fixed tag. 😂 It's more a simple way to update. Change the tag in SaltStack, apply config, service is restarted, new tag is pulled. If the tag doesn't change, the pull is a noop.
Ahh, calmed me down. Never thought of doing anything like you're doing it here, but I do like it.
That's wild! What advantage do you get from it, or is it just because you can for fun?
Also I've never seen a service created for each docker stack like that before..
Well, you gotta start it somehow. You could rely on compose'es built-in service management which will restart containers upon system reboot if they were started with -d, and have the right restart policy. But you still have to start those at least once. How'd you do that? Unless you plan to start it manually, you have to use some service startup mechanism. That leads us to systemd unit. I have to write a systemd unit to do docker compose up -d. But then I'm splitting the service lifecycle management to two systems. If I want to stop it, I no longer can do that via systemd. I have to go find where the compose file is and issue docker compose down. Not great. Instead I'd write a stop line in my systemd unit so I can start/stop from a single place. But wait 🫷 that's kinda what I'm doing isn't it? Except if I start it with docker compose up without -d, I don't need a separate stop line and systemd can directly monitor the process. As a result I get logs in journald too, and I can use systemd's restart policies. Having the service managed by systemd also means I can use aystemd dependencies such as fs mounts, network availability, you name it. It's way more powerful than compose's restart policy. Finally, I like to clean up any data I haven't explicitly intended to persist across service restarts so that I don't end up in a situation where I'm debugging an issue that manifests itself because of some persisted piece of data I'm completely unaware of.
Interesting, waiting on network mounts could be useful!
I deploy everything through Komodo so it's handling the initial start of the stack, updates, logs, etc..
Oh, and if you haven't changed from the default ML model, please do. The results are phenomenal. The default is nice but only really needed on really low power hardware. If you have a notebook/desktop class CPU and/or GPU with 6GB+ of RAM, you should try a larger model. I used the best model they have and it consumes around 4GB VRAM.
Which model would you recommend? I just switched from ViT-B/32 to ViT-SO400M-16-SigLIP2-384__webli since it seemed to be the most popular.
I switched to the same model. It's absolutely spectacular. The only extra thing I did was to increase the concurrent job count for Smart Search and to give the model access to my GPU which sped up the initial scan at least an order of magnitude.
Seems to work really well. I can do obscure searches like Outer Wilds and it will pull up pictures I took from my phone of random gameplay moments, so it's not doing any filename or metadata cheating there.
Is this something that would be recommended if self-hosting off a Synology 920+ NAS?
My NAS does have extra ram to spare because I upgraded it, and has NVME cache 🤗
That's a Celeron right? I'd try a better AI model. Check this page for the list. You could try the heaviest one. It'll take a long time to process your library but inference is faster. I don't know how much faster it is. Maybe it would be fast enough to be usable. If not usable, choose a lighter model. There's execution times in the table that I assume tell us how heavy the models are. Once you change a model, you have to let it rescan the library.
That’s a Celeron right?
Yup, the Intel J4125 Celeron 4-Core CPU, 2.0-2.7Ghz.
I switched to the ViT-SO400M-16-SigLIP2-384__webli model, same as what you use. I don't worry about processing time, but it looks like a more capable model, and I really only use immich for contextual search anyway, so that might be a nice upgrade.
What's your consideration for choosing this one? I would have thought ViT-B-16-SigLIP2__webli to be slightly more accurate, with faster response and all that while keeping a slightly less RAM consumption (1.4GB less I think).
Seemed to be the most popular. LOL The smart search job hasn't been running for long, so I'll check that other one out and see how it compares. If it looks better, I can easily use that.
Did you run the Smart Search job?
Running now.
Let me know how inference goes. I might recommend that to a friend with a similar CPU.
I decided on the ViT-B-16-SigLIP2__webli model, so switched to that last night. I also needed to update my server to the latest version of Immich, so a new smart search job was run late last night.
Out of 140,000+ photos/videos, it's down to 104,000 and I have it set to 6 concurrent tasks.
I don't mind it processing for 24h. I believe when I first set immich up, the smart search took many days. I'm still able to use the app and website to navigate and search without any delays.
Let me know how the search performs once it's done. Speed of search, subjective quality, etc.
OK, indexing finished some time yesterday and I ran a few searches like:
"Child wearing glasses indoors"
"Cars with no wheels"
"Woman riding a bike"
Results come up (immich on android) in three seconds.
But the quality of the results do appear to be considerably better with ViT-B-16-SigLIP2__webli compared to the default model.
I'm pretty happy. 👍
Nice. So this model is perfectly usable by lower end x86 machines.
I discovered that the Android app shows results a bit slower than the web. The request doesn't reach Immich during the majority of the wait. I'm not sure why. When searching from the web app, the request is received by Immich immediately.
Interesting, it's slightly slower for me through the web interface both with a direct connect to my network, or when proxied through the internet. Still, we're talking seconds here, and the results are so accurate!
Immich has effectively replaced the (expensive) Windows software Excire Foto, which I was using for on-device contextual search because Synology Photos search just sucks. Excire isn't ideal to run from Linux because it has to be done through a VM, so I'm happy to self-host Immich and be able to use it even while out of the house.
Search speed was never an issue before, and neither was quality. My biggest gripe is not being able to sort search by date! If I had that, it would be perfect.
But I'll update you once it's done (at 97,000 to go... )
Ok I should know this by now, but what actually is the current “./“ directory when you use that? Is it the docker daemons start dir like /var/docker ?
./ will be the directory you run your compose from
I'm almost sure that ./ is the directory of the compose.yaml.
Normally I just run docker compose up -d in the project directory, but I could run docker compose up -d -f /somewhere/compose.yaml from another directory, and then the ./ would be /somewhere, and not the directory where I started the command.
That seems like a bad idea
Its convenient because your data is stored in the same folder that your docker-compose.yaml file is in, making backups or migrations simpler.
Yup. Everything is in one place and there's no hardcoded paths outside of the work dir making it trivial to move across storage or even machines.
As other stated it’s not a bad way of managing volumes. In my scenario I store all volumes in a /config folder.
For example on my SearXNG instance I have a volume like such:
services:
searxng:
…
volumes:
- ./config/searx:/etc/searxng:rw
This makes the files for SearXNG two folders away. I also store these in the /home/YourUser directory so docker avoids using sudoers access whenever possible.
So why would you not write out the full path? I frequently rerun compose commands from various places, if I'm troubleshooting an issue.
So why would you not write out the full path?
The other day my raspberry pi decided it didn’t want to boot up, I guess it didn’t like being hosted on an SD card anymore, so I backed up my compose folder and reinstalled Rasp Pi OS under a different username than my last install.
If I specified the full path on every container it would be annoying to have to redo them if I decided I want to move to another directory/drive or change my username.
I'd just do it with a simple search and replace. Have done. I feel like relative paths leave too much room for human error.
It's not.
It usually is the directory where you execute the docker compose command.