Self-hosted photo backup on Android: powerful, but not automatic
Self-hosted photo backup on Android means running your own NAS photo server, often powered by Docker and apps like Immich, so your pictures sync from phone to hardware you control instead of a big cloud provider’s platform, but this control comes with fragile background sync and notification behavior that users must actively manage.
The hard truth: Android is not designed to treat self-hosted photo backup apps the way it treats Google Photos. Android limits how long apps can run in the background on purpose, prioritizing battery and system health over your desire to push gigabytes of images to a server at home. Immich’s backup runs as a background worker, so when the system decides to put the app to sleep, photos stay stranded on the device. Meanwhile, Google Photos has exemptions “set from the moment the phone boots,” so you would have to go out of your way to break its backups. If you expect a self-hosted solution to behave like Google’s app without extra effort, you will be disappointed.
Where Android sabotages self-hosted sync: silent failures and missing photos
The most dangerous Android sync issues are the ones you never see. One user searched for a weekend photo and discovered their Immich backup was several days out of date; nothing had warned them, and nothing looked broken. During those days, the phone had been quietly killing Immich’s background workers, so photos never left the device. Self-hosters are vulnerable because we assume “no error message” means “everything is fine.” It doesn’t.
Even when photos do reach your NAS photo server, Android still favors cloud providers that integrate with the system Photo Picker. Immich could back up every photo and video to a NAS, but it could not surface them in Android’s Photo Picker, so older images stored only on the server vanished from everyday workflows. That unified view of decades of photos and smart features like face search remained tied to Google Photos, while the self-hosted library sat in its own silo. In other words, self-hosting can protect your data but still make your photos feel less present on your phone.
Why self-hosted backup needs hands-on care, not blind trust
Moving a 1TB+ library to a self-hosted photo backup platform like Immich is appealing because it gives ownership and control over your memories. These systems run in Docker, using a Docker Compose file and an environment file to define containers and storage paths, and a few terminal commands can turn an old Mac, PC, or Linux machine into a personal photo server. With the containers running, you can open a browser and go to http://localhost:2283 to manage your library. Now your photos are no longer on Google’s servers; they live in the location you configured in your self-hosted setup.
But this freedom is not as automated or feature-rich as Google Photos, and controlling your own hardware and storage means you are responsible for what happens to your photos. Android’s strict battery optimization can still kill background workers even when permissions are granted, with reports of uploads resuming only when the app is opened manually on some devices. That’s why Immich’s documentation points users to guides like “Don’t Kill My App,” and why version 3.0 added a setup flow that requests notification access, warns about battery optimization, and introduces a periodic task scheduler so Android can upload an entire library in the background instead of only new photos. The quote to remember is: “The warning arrived in version 3.0, alongside a new periodic task scheduler that lets Android upload an entire library in the background rather than only newly taken photos.”
Practical fixes: hardening your Immich Android client
If you want Immich to behave like a dependable self-hosted photo backup, you must treat the Android app as critical infrastructure, not a normal gallery. First, go through the current setup flow carefully: grant notification access so Immich can warn you, and disable battery optimization for the app so the system does not put its background workers to sleep. Where your device allows it, pin Immich as an always-allowed app in power settings and enable foreground service notifications for uploads.
Second, build habits that catch silent failures. Open Immich at least once after major events, check that recent photos appear on the server, and periodically verify that the upload queue is empty. Version 3.0’s periodic scheduler makes full-library uploads possible in the background, but Android can still interfere, especially on aggressive devices. Remember that self-hosting means monitoring: you are the reliability engineer now. If you treat Immich as “set and forget,” you will eventually find a week of memories trapped on your phone.
The hybrid strategy: NAS archive plus cloud safety net
For most people, the sane choice is a hybrid approach, not self-hosting purity. One writer continues to back up photos and videos to Immich while still using Google Photos; keeping both was not the original plan, but it provides the control of self-hosting without giving up the deep integration and convenience of Google’s app. Google Photos never needed manual exemptions or power tweaks because its permissions and privileges are baked into Android, making it much harder to accidentally break backups.
In practice, that means using your NAS photo server as the long-term archive and Google Photos (or another cloud provider) as a secondary safety net for critical mobile photos. These few steps are enough to turn an old machine into a personal photo server and give you independent storage, while the cloud handles the messy realities of Android’s background limits. As one self-hoster put it, they are “comfortable moving more of their digital life onto hardware they own,” but only after acknowledging that Android will not protect those backups by default. The conclusion is simple: self-hosted photo backup can be reliable, but only if you pair it with disciplined monitoring or a cloud fallback.
