Category
Photos, files and sync
Getting photos off a phone, making an archive searchable, and keeping two laptops in step are three separate problems. Most disappointment here comes from buying one tool for all three.
Three different problems get sold as one category here, and buying the wrong tool for yours is the most common mistake people make.
Getting photos off a phone is a background upload problem: a maintained mobile app that survives iOS backgrounding, deduplicates on re-upload and needs you to remember nothing.
Making an archive searchable is an indexing problem: faces, dates, places and a fast browser over tens of thousands of files, without owning the storage.
Keeping devices in step is a replication problem: conflict handling and low latency, and actively hostile to being used as either of the first two.
A tool that does one of these well will do the others badly. That is not a gap in the market, it is what the right data model for one job costs you on the others.
The default: Immich for the camera roll, Syncthing for devices#
Immich is the answer for phone backup: real first-party apps, face and semantic search, and since v2.0.0 on 1 October 2025 it follows semantic versioning, so any 2.x app talks to any 2.x server and reading release notes before every pull is now only mandatory across majors.
Budget honestly. The docs ask for 6 GB minimum and 8 GB recommended, it idles around 900 MB across four containers, and machine learning is most of that. On ARM it runs, but GPU acceleration exists only for Mali via ARM NN and RK3588-class Rockchip via RKNN.
For files between your own machines, Syncthing: 60 MB, ops load 1, no server, no account, no cloud. It is the least demanding thing here and the most misused, which is the next section.
Two situations point somewhere else.
You already have a folder tree you care about. PhotoPrism indexes an existing archive in place and gives it search, faces, places and a calendar for 450 MB. Know two things: photoprism/photoprism:latest is the Plus-licensed build and the pure AGPL one is the ce tag, and Import moves files into PhotoPrism's own date-based naming while Index leaves them alone. People who drop an archive into import/ to try it find their layout rewritten.
Other people need shares, links and calendars. Then Nextcloud, knowing the release calendar: majors every four months, one year of support each, no skipping. An instance on 31 goes 31, 32, 33, 34, each with its own migration and PHP window. For the sync engine without the suite, Seafile is faster and blunter, and Professional is free for three users.
Sync is not backup#
Syncthing's FAQ states it plainly: all changes, modifications and deletions included, propagate to every device. That is the feature, and it is why a synced NAS copy is worth nothing against the two failure modes that actually take people's photos: a mistake you make yourself, and software running as you.
The same logic applies one level up. Immich's trash deletes originals when it empties. Nextcloud's has a retention period. Neither is a backup, and a library manager is never a backup of itself. Everything here needs a repository it cannot write to, which is what Backup is for.
The mistakes people actually make#
- Letting the phone free up space before the server is backed up. The upload succeeded, so the phone offers to delete the local copies, and the only copy is now on a server whose backup you have not tested.
- Putting a SQLite database on a network share. Audiobookshelf, Trilium and others corrupt this way, quietly, weeks later. It is not an error, it is a corruption class.
- Upgrading Immich across a major without a dump. Downgrades are unsupported even within a minor, because migrations run forward only on startup.
v3.0.0removed pgvecto.rs, so instances predating 1.133.0 must reach VectorChord first. - Choosing SQLite in the Nextcloud installer. It is offered, it survives a single-user trial, and it collapses under concurrent sync clients with locking errors. Migrating later is a maintenance window on live data.
- Backing up Seafile in the wrong order. Dump the three databases first, then copy the data directory. Reversed, objects written during the file copy get referenced by a later dump and libraries come back corrupt.
- Standardizing on an archived tool. File Browser was archived on 2026-09-01 with no further security fixes, and its JWT sessions cannot be revoked at all. The successor is a fork, not an upgrade.
What to read next#
Replace Google Photos, Replace Dropbox and Replace Google Drive are the migration paths off the services most people leave. For the head-to-head calls: Immich vs PhotoPrism, Immich vs Nextcloud for photos, Nextcloud vs Seafile and Syncthing vs Nextcloud. Then Backups that actually restore and Backing up a running database, because everything here sits on a database a file copy will not save, and Backup planner to size it.
Every photos and files tool we profile#
Sorted by operational load, lightest commitment first. Every row links to a full profile with the resource numbers, the upgrade traps and the restore path.
| Tool | Ops load | Idle RAM | Licence | Identity | Backup shape |
|---|---|---|---|---|---|
| File Browser | 1, Set and forget | 20 MB | Apache-2.0 | Trusted proxy header | Mixed |
| Syncthing | 1, Set and forget | 60 MB | MPL-2.0 | Local accounts only | SQLite backup |
| PhotoPrism | 2, Light | 450 MB | AGPL-3.0 (Community Edition); default images ship under the PhotoPrism Plus License | Native OIDC | MySQL dump |
| Immich | 3, Moderate | 900 MB | AGPL-3.0 | Native OIDC | Postgres dump |
| Seafile | 3, Moderate | 700 MB | GPL-2.0 with an OpenSSL linking exception (server, Community Edition); Professional Edition is proprietary | OIDC via plugin | MySQL dump |
| Nextcloud | 4, Heavy | 600 MB | AGPL-3.0-or-later | OIDC via plugin | MySQL dump |
Profiles#
File Browser
Single-binary web file manager for a directory you already have. Archived on 2026-09-01
ops 1/5 · 60 MBSyncthing
Continuous peer-to-peer file sync between your own devices, with no server and no account
ops 2/5 · 450 MBPhotoPrism
Indexes an existing photo archive in place and gives it search, faces, places and a calendar
ops 3/5 · 900 MBImmich
Self-hosted photo and video backup with real phone apps, face search and semantic search
ops 3/5 · 700 MBSeafile
Fast file sync with block-level dedup, library versioning and a clear community/pro split
ops 4/5 · 600 MBNextcloud
File sync and share plus calendar, contacts, office and an app store, on your own server
Head to head in this category#
- Immich vs Nextcloud for photosNextcloud Photos is not in Immich's category. This page says so, then explains when it does not matter.
- Immich vs PhotoPrismThese are not competitors. One takes photos off your phone; the other searches the folders you already have.
- Nextcloud vs SeafileOne gives you calendar, contacts and office. The other gives you sync that is genuinely fast and files you cannot read off disk.
- Paperless-ngx vs NextcloudA document archive with OCR against a file sync platform. Most people who run one should run both.
- Syncthing vs NextcloudOne of these is not a server product at all. Knowing that before you install it is the whole value of this page.
Leaving a cloud service in this category#
- Replace DropboxHow to pull a whole Dropbox account out with rclone, and why Syncthing is sync rather than backup.
- Replace Google DriveDocs convert lossily, Takeout skips Shared with me, and rclone moves about two files a second. Plan accordingly.
- Replace Google PhotosTakeout's split archives and JSON sidecars, the hours and terabytes involved, and the test to run before you cancel Google One.
Questions#
Is Syncthing a backup?
No, and its own FAQ says so. Syncthing replicates every change, deletions included, to every device sharing the folder. An rm -rf on your laptop or a ransomware run reaches the NAS within seconds, exactly as designed. There is no server and no authoritative copy: every peer is equal and any of them can propagate a destructive change. The mitigations are a receive-only folder on the archival device and file versioning with a real retention policy, but the actual answer is a separate backup, in a repository Syncthing cannot write to.
How much RAM does Immich need?
The docs ask for 6 GB minimum and 8 GB recommended, and the machine learning container is most of that. It idles around 900 MB across four containers and reaches several gigabytes during face and search indexing. Exit code 137 on the ML container means it was killed for memory, not that search is broken, and every extra value of MACHINE_LEARNING_WORKERS loads a second full copy of the models. On a 4 GB host you can run with IMMICH_MACHINE_LEARNING_ENABLED=false, which costs you face grouping and semantic search.
Immich or PhotoPrism?
Immich if the requirement is automatic phone backup, because it has real first-party iOS and Android apps and PhotoPrism does not: PhotoPrism documents PhotoSync as the phone-side option for every tier, paid ones included. PhotoPrism if you already have a well-organized folder tree and want search, faces and places layered over it in place, for 450 MB instead of 900 MB and one fewer moving part. The tell is whether your photos currently live in a structure you care about. If they do, do not hand them to something that reorganizes them.
Can one app replace Google Photos and Dropbox?
Nextcloud is the one that tries, and the cost is a release calendar rather than the software. Majors ship every four months with a twelve month support window, you cannot skip a major, and each one has its own PHP requirement, so drifting eighteen months turns an update into four sequential upgrades. It idles at 600 MB across four containers and scores 4 on ops load. Running Immich for photos and Syncthing or Seafile for files is more containers and considerably less attention per month.
What do I actually need to back up from a photo server?
The originals and the database, and nothing else. For Immich that is the library/ subdirectory of UPLOAD_LOCATION plus a pg_dumpall; upload/, thumbs/, encoded-video/ and profile/ all regenerate from the admin jobs page at the cost of another ML and transcode pass. For PhotoPrism it is originals/ plus the index, taken with photoprism backup -i -f on MariaDB, and keep storage/sidecar/ because that holds the metadata edits you made in the UI. Restore order is database first, then files.
Does deleting a photo in Immich delete the file?
Yes. Immich's trash is not a soft view over a preserved copy: emptying it, or letting the retention period expire, removes the original from UPLOAD_LOCATION for real. Combine that with a mobile client that offers to free up space on the phone after upload and it is entirely possible to hold exactly one copy of a photo and then delete it from a web UI. Immich is not a backup of itself, and neither is any other library manager. The archive needs its own backup with its own retention.
Syncthing or Seafile or Nextcloud for file sync?
Syncthing when the devices are all yours and there is no server: 60 MB, ops load 1, peer to peer, no accounts. Seafile when you want the fastest sync engine and block-level dedup for large files, accepting that what sits on the server is an object store rather than your files, so ls shows you nothing readable and a restore needs the database and data directory taken in the right order. Nextcloud when other people need shares, links, calendars and contacts, and you accept ops load 4 for it.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.