# fregie/pho: a serverless photo viewer and sync client for SMB, WebDAV and NFS

> Pho is a Flutter mobile app with an embedded Go server that uploads photos to network storage using a plain date-based folder tree. The open source build ships Android only, and several features live behind the paid Pro version.

**fregie/pho** — A serverless application for viewing and synchronizing photos to cloud storage

- Repository: https://github.com/fregie/pho
- Website: https://pho.tools
- Stars: 1,165 · Forks: 95
- Language: Dart
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/fregie-pho

## The problem Pho targets: getting phone photos onto your own storage

The README states the goal plainly: replace the phone's built-in gallery app and sync photos to network storage. That is a narrower job than it sounds. Most self-hosted photo tools ask you to run a server process, keep a database, and then trust that database to describe where your files live. Pho takes the other route. The README lists "no database, no server" as a feature, and the storage layout backs that up: files are written to the storage backend as ordinary files in a date-based tree, so you can read them with any file manager later.

The audience is the homelab owner with a NAS or a home server already exporting SMB, WebDAV or NFS. If that describes your setup, Pho is a client, not a platform. It does not index your library on a remote machine, does not serve a web gallery, and does not deduplicate across devices. It browses local photos and cloud photos, uploads incrementally, and can sync on a schedule in the background. The feature list in the README stops there.

That restraint is also the boundary. Anyone who wants face detection, shared albums, map views or a browser interface is looking at the wrong project.

## How Pho works: Flutter UI, embedded Go server, gRPC between them

The repository layout shows two languages and a protocol definition directory. The Flutter app lives under lib/, and a Go program lives under server/. The proto/ directory holds the protobuf definitions, and the Makefile generates Go and Dart stubs from them with protoc, using protoc-gen-go, protoc-gen-go-grpc and the Dart protoc_plugin. The Go module is named github.com/fregie/img_syncer and depends on google.golang.org/grpc, which tells you the two halves talk over gRPC rather than through platform channels.

The Go side is compiled into the app rather than deployed separately. The Makefile has targets that bind it with gomobile for Android and iOS, producing android/app/libs/server.aar and ios/Frameworks/RUN.xcframework, plus shared libraries for Linux and Windows. So the "server" in this project is a process inside the phone, and the storage protocol clients live in Go: the module pulls in go-smb2, gowebdav and go-nfs-client, with the last two replaced by forks under the fregie account. EXIF parsing comes from dsoprea/go-exif, which is how the app can place a file by capture time rather than upload time.

The storage layout is the part worth studying before you adopt it. The README shows a tree of year, month, day directories holding the original filenames, with a parallel .thumbnail directory at the root mirroring the same structure. The README's stated reason is that you can use your backed-up photos in other ways without depending on the app. The trade-off is that the folder shape is fixed in the open build: the README lists configurable directory structure (YYYY/MM/DD or YYYYMMDD) as a Pro feature, so the open version gives you the default and nothing else.

## Installing Pho and pointing it at a WebDAV share

The README does not describe a package manager install. It says the open source build is distributed as an Android APK from the GitHub releases page, and that the repository provides APK downloads only. iOS users are directed to the App Store, and Android users to Google Play, for the Pro version. So the first step is downloading the APK from the releases page and installing it, with the usual sideloading permission on Android.

If you would rather build it yourself, the README lists the toolchain: Flutter 3.41.4 with Dart 3.11.1, Go 1.25 (toolchain go1.25.4), JDK 17, Android SDK compileSdk 36, and the Android NDK for the gomobile bind step. The build sequence in the README is:

```bash
make prebuild      # install protoc plugins
make protobuf      # generate Go + Dart stubs
make server-aar    # Android: android/app/libs/server.aar
make apk           # Android APK
```

The README adds a note that matters if you plan to iterate: flutter run does not build android/app/libs/server.aar automatically, so run make server-aar first or the Go server will not start. Tests are run with make test, which the README says needs Docker for the SMB, WebDAV and NFS test containers.

Once the app is on the phone, the flow implied by the feature list is: grant photo access, open the sync page, add a storage backend, and start an incremental sync. The README's screenshots are named for the local gallery, the cloud gallery, the sync page and the photo viewer, which matches that order. The README does not document the exact configuration fields for each backend, so expect to fill in host, share or path, and credentials from what your own server exports.

## Where the open build falls short: encryption, filters and iOS

The README is explicit that this repository is the open version and that a list of features exists only in Pro. The list includes AES encryption on upload, with AES-128-CFB and AES-256-GCM named, and Range playback for encrypted video. It also includes parallel upload tuning, file filters by type or date, the directory structure option mentioned above, theme color customization, and Baidu Netdisk support. The open build supports Samba, WebDAV and NFS, and nothing else.

That split decides a lot. If your storage endpoint is reachable only over the public internet, the open build gives you no encryption layer of its own, so you are relying on the transport and on whatever your storage server does. If you want to exclude screenshots or videos from a sync run, the filter feature is not in this repository. And the README states that iOS users should go to the App Store, which means the open repository is not the path to an iOS build even though ios/ exists in the tree and the Makefile has a server-ios target.

The README's supported-storage checklist is honest about the rest: Aliyun Drive, OneDrive, Google Drive and Google Photos are all unchecked. Anyone arriving because the repository topics mention google-photos-alternative should read that list before installing. Pho is an alternative in the sense that it keeps your photos on your own storage; it does not import from or sync with Google Photos.

## Pho compared with a self-hosted gallery server

The obvious alternative class is a self-hosted photo server such as Immich, which the topics list does not name but which occupies the same shelf. The difference in approach is architectural. A gallery server runs as a service on a machine you own, keeps an index in a database, and serves a web interface that any browser can open. Pho runs entirely on the phone, keeps no index outside the storage tree, and offers no browser interface at all.

That changes what you can do. With a server, multiple users and devices see the same library, and search or albums are computed centrally. With Pho, each phone syncs its own camera roll into the shared folder tree, and the folder tree is the only shared state. There is no server to back up, but also no server to query. If you want a web gallery for family members, Pho does not provide one.

The closer comparison is a plain sync client like rclone or a mobile folder-sync app. Those move files; Pho adds a gallery view over both the local camera roll and the remote tree, plus thumbnail generation into .thumbnail. It is a viewer and a sync client in one app, and the README's stated aim is to replace the built-in gallery, not to sit beside it.

## Version history, licence and what upgrading costs you

The releases tell a story worth noting. v1.4.2 and v1.4.5 landed in September 2023, and then v1.5.0 arrived on 2026-07-29, a gap of nearly three years between releases. The last push to the repository was on 2026-08-20, so work has happened since that release, but the release cadence is not steady and the README does not describe an upgrade or migration procedure. There is no documented rollback path either.

Because the storage format is plain files in date folders, an app upgrade does not put your photos at risk in the way a schema migration would: there is no database to migrate. The risk sits elsewhere. If a future version changes how thumbnails or directory names are written, the README does not say how that would be handled, so keep your own copy of anything you cannot re-upload.

The licence is GPL-3.0, per the LICENSE file at the repository root. For a phone app you install yourself, that is mostly a question of what happens if you redistribute a modified build: the GPL's source-availability terms apply to what you distribute. The Pro version is a separate paid product on the App Store and Google Play and is not covered by this repository, which the README states directly. Nothing here is legal advice; if you plan to ship a fork, read the licence text.

## Conclusion

Adopt fregie/pho if you run SMB, WebDAV or NFS storage at home and want photos written as ordinary files you can open without the app. Skip it if you need iOS from the open repository, encrypted uploads, or a sync filter, since those sit in the paid Pro build. Before committing, verify that your server can be reached from the phone, and read the .thumbnail directory the app creates at the storage root.

## FAQ

### Is fregie/pho available for iOS?

The README says the open repository provides APK downloads only, and directs iOS users to the App Store for the Pro version. The ios/ directory and the server-ios Makefile target exist in the source tree, but the README does not present them as the supported install path for iOS users.

### Which storage backends does the open source version of fregie/pho support?

Samba, WebDAV and NFS. The README states that the open version supports only those three, and lists Aliyun Drive, OneDrive, Google Drive and Google Photos as unchecked items.

### Does fregie/pho encrypt photos before uploading?

Not in the open build. The README lists AES encryption upload, with AES-128-CFB and AES-256-GCM named, as a Pro-only feature alongside parallel upload tuning and file filters.

### What folder structure does fregie/pho create on the storage server?

The README shows a year, month, day tree holding the original filenames, with a .thumbnail directory at the root mirroring the same structure for generated thumbnails. The README lists a configurable directory structure as a Pro feature, so the open build uses the default layout.

## Sources

- [fregie/pho on GitHub](https://github.com/fregie/pho)
- [License: GPL-3.0](https://github.com/fregie/pho/blob/master/LICENSE)
- [Project website](https://pho.tools)
- [README](https://github.com/fregie/pho/blob/master/README.md)
- [Releases](https://github.com/fregie/pho/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fregie-pho