Lap: a local-first photo manager for large folders you already own

The problem Lap targets: big folders that already exist

Most photo managers assume you will hand your library over to them. You point the app at a folder, it copies or links everything into a database, and from then on the database is the source of truth. That works until you want to leave, or until you want to browse the same folders in Finder or Explorer.

Lap takes the opposite position. The README describes it as "folder-first": your originals stay as ordinary files in their existing folders, and Lap reads what is already embedded in them, such as EXIF capture date, camera, lens, GPS and orientation, when it indexes. The stated target is browsing family albums, finding old photos quickly, and managing large personal media libraries offline. The README also claims optimization for libraries with 100k+ files, though it gives no benchmark for that claim, so treat it as a design goal rather than a measured result.

The audience is narrow and specific: someone with a large local archive, a dislike of uploading it, and enough patience to keep file operations inside one application. If your photos live in iCloud or Google Photos and you are happy there, Lap solves a problem you do not have.

How the index and the catalog split apart

The architecture visible in the README is a two-layer one, and the split is the most important thing to understand before adopting it.

The first layer is your filesystem. Lap does not own it. Photos and videos remain ordinary files, and when you rename, move, copy or delete them inside Lap, Lap updates its local catalog at the same time and keeps grouped assets together: Apple Live Photo components, AAE sidecars, and RAW plus JPEG/HEIC pairs when that grouping is enabled. Those pairs stay separate files on disk; Lap just treats them as one item in the interface.

The second layer is Lap's own database and library configuration. Collections, tags, comments, favorites, ratings and culling states live there. So do Smart Albums and their rules, and so do AI search data, face data, thumbnails and other index and cache data. The README is explicit that none of this is written into EXIF, IPTC or XMP sidecars, and that it does not travel with a file when the file is copied, exported or moved outside Lap.

That is a clean design, and it has a direct cost. Everything you build up in Lap is invisible to Lightroom, digiKam, or any other tool that reads sidecars. The README acknowledges the failure mode: changes made outside Lap, such as renaming or replacing files, "can disrupt organization that is stored only in Lap." Rescanning detects many filesystem changes, but detection is not the same as repair.

Installing Lap and running a first search

Lap ships as a desktop application. The README points to the latest release page on GitHub and lists packages per platform: `_aarch64.dmg` or `_x64.dmg` for macOS, `_x64_en-US.msi` or `_arm64_en-US.msi` for Windows 10 and 11, and `_amd64.deb` or `_arm64.deb` for Debian-based Linux distributions. The macOS builds are described as notarized by Apple. The Windows installers are unsigned, and the README says that if SmartScreen blocks the download you should click Keep anyway.

On macOS there is also a Homebrew cask. Two commands, both from the README:

brew tap julyx10/lap
brew install --cask lap

After installing, the first real task is pointing Lap at a folder rather than importing one. The README describes multiple libraries, drag-and-drop import, copy-paste import and filesystem sync as the folder-first workflow. There is no documented CLI for creating a library, so this step happens in the interface.

The second task is search. Lap's local AI search accepts text prompts, visual similarity, subjects and face clustering, with optional multilingual search in 50+ languages according to the README. The AI runs on your machine; the README frames this as a privacy property, and the practical consequence is that the first index of a large library is a local compute job whose duration depends on your hardware. Lap does not publish indexing times.

One storage decision is worth making early. The README says the database location can be managed and a backup created under Settings, in the Storage section. If you intend to rely on tags or collections, back up that database alongside your photos, because it is the only place that data exists.

Where Lap is the wrong tool

The clearest limitation is metadata portability, and it deserves to be stated plainly rather than buried. If your workflow depends on ratings and keywords being readable by other applications, Lap will not provide that. Its ratings, tags, comments and culling states are stored locally and, per the README, are not written into EXIF, IPTC or XMP. An export from Lap is a copy of the image, not a copy of your organization.

The second limitation is the mirror image of the first. Because Lap tracks your filesystem, external changes are a hazard. The README's own recommendation is to rename and move files in Lap whenever you rely on collections, tags, comments, favorites, ratings or culling states. That is a real constraint on how you use your computer, not a minor caveat.

The third is scope. Lap is a desktop application for macOS, Windows and Linux. There is no server mode, no web interface and no mobile client in the README. If you want a self-hosted library that a phone can reach, this is not that product.

Finally, there is the question of platform packaging. The Windows builds are unsigned, which means every install involves a SmartScreen warning. That is a friction point and a small trust decision the user has to make.

A fourth point is maintenance signalling. The last push to the repository was on 2026-08-18, and the most recent release, v0.3.1, carries the same date. That is recent enough that the project is not abandoned, but the version number says more: at 0.3.x, Lap is pre-1.0, and the README does not document a migration path for the database between releases. Backing up the database before upgrading is the only safe assumption.

Lap compared with digiKam and Lightroom

The obvious open-source comparison is digiKam, and the difference is architectural rather than cosmetic. digiKam writes metadata to sidecar files and to the image files themselves, so tags and ratings survive a move to another application and can be read by anything that understands XMP. Lap keeps that data in its own database, which makes it faster to manage internally and completely opaque externally. If interoperability matters more than speed, digiKam's approach is the one that ages better.

Against Lightroom, the split is about ownership and cost. Lightroom is a commercial catalog with cloud services attached; Lap is GPL-3.0, free, and explicitly positioned as a privacy-focused alternative to cloud photo services, with no required account or upload. But Lightroom's catalog is also a mature, documented format with an established migration story, and Lap at 0.3.x has neither.

The honest summary: Lap trades portability for locality. It keeps your originals untouched and your AI on your own machine, and in exchange it asks you to do your file management inside it. Whether that trade is acceptable depends almost entirely on whether you ever plan to use a second tool on the same folders.

Licence, uninstall and what stays on disk

Lap is licensed under GPL-3.0. For an end user running the application, that is a permissive situation: no subscription, no account, and the source is inspectable. For anyone thinking about embedding Lap's code in a proprietary product, the copyleft terms apply and are worth reading in full rather than summarizing here. This is not legal advice.

The uninstall documentation is unusually careful, and it clarifies the data model. Removing the application does not delete your photos, because Lap never owned them. The README notes that deleting Lap's database or configuration removes local organization and index data but leaves original media files alone.

On macOS with Homebrew, removal is a single command:

brew uninstall --cask lap

A complete removal also deletes the database, cache and configuration files. The README gives the paths explicitly, including `$HOME/Library/Application Support/com.julyx10.lap`, `$HOME/Library/Caches/com.julyx10.lap`, `$HOME/Library/WebKit/com.julyx10.lap` and `$HOME/Library/Preferences/com.julyx10.lap.plist` on macOS, and `$env:LOCALAPPDATA\com.julyx10.lap` on Windows via PowerShell.

The upgrade cost is the part the README does not cover. There is no documented database migration procedure between versions, and no documented rollback if a new release changes the schema. The README does say you can manage the database location and create a backup under Settings, Storage. That is the mechanism to use before every upgrade, and it is the one piece of operational discipline this project requires.

Editorial conclusion

Lap fits people with large, already-organized photo folders who want local AI search and are willing to do their renaming and moving inside the app. It is the wrong tool if you need a server, a mobile client, or metadata that other applications can read. Before committing a library, verify one thing: whether your tags, ratings and collections survive when you move a file in Finder or Explorer, because the README states that this data is stored in Lap's database and not written into EXIF, IPTC or XMP sidecars.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes