Damselfly

Self-hosted photo management, honestly reviewed. No marketing fluff, just what you get when you run it on your own server.

TL;DR

• What it is: Open-source (GPL-3.0) server-based photo management system designed for large, folder-based photo libraries with machine learning face recognition and object detection built in [README].
• Who it’s for: Photographers, archivists, and privacy-conscious households sitting on tens or hundreds of thousands of images who want a searchable, taggable library without paying Google or Amazon a monthly subscription [README][1].
• Cost savings: Google Photos charges $2.99/mo for 100 GB and $9.99/mo for 2 TB. iCloud+ runs $2.99–$9.99/mo. Damselfly itself costs $0 in licensing. Running it on a VPS adds $5–15/mo depending on storage needs.
• Key strength: Blazing fast search across enormous libraries. The README claims sub-second search across a 500,000-image catalogue. Face detection and recognition run locally and offline — no Azure, no Google Vision API, no external data leaving your server [README].
• Key weakness: No native mobile app, a relatively small community (1,752 GitHub stars), no dedicated roadmap page, and the ML features require at least 4 GB of RAM — which disqualifies cheap $5 VPSes [1][README].

---

What is Damselfly

Damselfly is a server-side photo management application built on Microsoft .NET and Blazor WebAssembly. You point it at a folder tree of images on your server, it indexes everything in the background, and you get a web UI that lets you search, tag, browse, and export — from any browser, on any device [README].

The design inspiration is stated plainly in the README: it’s “loosely based on the much-loved Google Picasa app.” If you used Picasa before Google killed it in 2016, Damselfly will feel familiar. The basket-based workflow (search for images, add them to a basket, export or process the batch) is the core interaction pattern. There’s nothing clever or novel about the UX concept — it’s deliberately borrowing from something that worked [README].

What makes Damselfly worth evaluating in 2026 is the combination of local ML and library scale. Its face detection and recognition pipeline runs entirely on-device using ONNX models (no cloud API calls required), and the indexing engine is built to handle libraries that would choke most alternatives. For a photo management tool that a solo developer maintains with 89 forks and 1,752 GitHub stars, the scope is ambitious [README][1].

---

Why People Choose It

The comparison table in the MakeTechEasier roundup of self-hosted photo managers [1] puts Damselfly’s profile in context against its seven direct competitors. Most of the lightweight alternatives (PiGallery2, Lychee, Piwigo) have no ML support at all and run on 512 MB–1 GB of RAM. Most of the ML-capable alternatives (Immich, PhotoPrism, Photonix) require 4 GB of RAM just like Damselfly. So Damselfly doesn’t win on resource requirements — it competes in the same weight class as the heavy hitters.

What it does offer that’s distinct:

The Picasa workflow. People who spent years in Picasa’s “select → basket → export” model find the mental map comfortable. Damselfly is the only self-hosted alternative that explicitly replicates this.

RAW file support out of the box. Damselfly handles JPG, PNG, HEIC, TIFF, WebP, BMP, and RAW formats including DNG, CR2, ORF, and NEF. For photographers coming off Lightroom or Darktable, this matters. Many lighter tools skip RAW entirely [README].

Non-destructive EXIF tagging. When you add keyword tags in Damselfly, it uses ExifTool to write metadata without re-encoding the JPEG. Your original file stays bit-for-bit identical; only the metadata changes. This is the correct behavior, but not every tool gets it right [README].

All ML runs locally. Some competitors have used cloud APIs for face recognition. Damselfly explicitly moved away from Microsoft Azure Face API (which got locked down) and rebuilt face detection and recognition locally using ONNX models. Your photos don’t leave your network for any processing step [README].

Geolocation and camera metadata filtering. You can filter by camera make/model, lens, file size, orientation, date range, or whether an image has GPS data. That level of metadata filtering is more useful for photographers managing a working archive than for family photo libraries [README].

---

Features

Based on the README and source [1]:

Image format support:

• JPG, PNG, HEIC, TIFF, WebP, BMP (standard formats)
• DNG, CR2, ORF, NEF (RAW camera formats)
• Thumbnail generation happens automatically in the background [README]

AI / Machine learning (all local, all offline):

• Face detection
• Face recognition — tag a person once, Damselfly finds them in other photos
• Object detection and recognition
• Image colour classification [README]

Search and browse:

• Full-text search with multi-phrase partial-word matching
• Advanced filters: date range, objects, identified faces, camera/lens make and model, file size, orientation, images with no tags, visually similar images
• Sub-second search claimed for 500,000-image libraries [README]

Organisation and workflow:

• Move/copy images between folders
• Delete images via a trashcan folder (non-permanent)
• Non-destructive EXIF keyword tagging via ExifTool
• Selection basket — save images from searches, then download, export, or upload to WordPress
• Baskets can be personal or shared with other users [README]

Export and sharing:

• Download/export with watermarking for social media
• Email export
• Integration with Digikam and Photoshop workflows via the desktop client [README]

Multi-user:

• User accounts with role-based access control
• ReadOnly role prevents users from keyword-tagging images [README][1]

GeoLocation:

• Map display of photo locations where GPS metadata exists [README]

Desktop client:

• Electron.NET desktop app available for macOS (universal), Windows, and Linux
• Syncs images from the server basket to a local folder for editing
• Gives closer OS integration than the browser UI alone [README]

Self-exclusion:

• Add a .nomedia file to any folder to prevent Damselfly from indexing it — useful for excluding work-in-progress or private folders [README]

Platform:

• Docker deployment (primary method)
• Runs on Windows, Linux, macOS
• Built on .NET 7, Blazor WebAssembly, Entity Framework Core 7 [README][1]

---

Pricing: SaaS vs Self-Hosted Math

Damselfly has no pricing page because it has no SaaS tier. It’s GPL-3.0 software — download, self-host, done [README].

What you’re comparing it against:

• Google Photos: Free for 15 GB (shared across Google account), then $2.99/mo for 100 GB, $4.99/mo for 200 GB, $9.99/mo for 2 TB
• iCloud+: $0.99/mo for 50 GB, $2.99/mo for 200 GB, $9.99/mo for 2 TB
• Amazon Photos: Unlimited photo storage included with Prime ($139/year), but video is capped at 5 GB
• SmugMug: $9/mo (basic) to $33/mo (pro)

Self-hosting Damselfly:

• Software license: $0 (GPL-3.0)
• Storage: depends on your library. A 100,000-photo library at average RAW sizes (~25 MB each) is roughly 2.5 TB. A Hetzner Storage Box at 2 TB runs €3.81/mo. A dedicated server with enough RAM and storage runs €40–80/mo for serious collections.
• VPS with 4 GB RAM and 200 GB SSD (Hetzner CX32): ~$6–8/mo — enough for a medium-sized library without RAW files or heavy ML use

Concrete math for a photographer with 80,000 images:

• Google Photos at 2 TB plan: $9.99/mo = $120/year
• Damselfly on a Hetzner CX32 + Storage Box: ~$12–15/mo = $144–180/year

For a small library, the cost savings aren’t dramatic. The real value proposition is ownership and privacy, not cost. You’re not saving money versus Google Photos unless you already have a server running other services and can share the fixed cost across them.

Where the math gets compelling is scale. A 500,000-image professional archive would require a multi-terabyte Google Photos plan at $20–30/mo. Self-hosting on owned hardware — a used server or NAS — effectively reduces marginal cost to electricity and bandwidth.

---

Deployment Reality Check

According to the comparison in [1], Damselfly “comes with a Docker image” — the same installation path as Immich, PhotoPrism, and Photonix. A Docker Compose file is included in the repository, which handles the application server, SQLite database, and thumbnail cache [README].

What you actually need:

• A Linux server with at least 4 GB of RAM — the ML features for face recognition and object detection require this minimum [1]
• Docker and Docker Compose
• Storage mounted at the path Damselfly expects (configurable)
• A reverse proxy (Caddy or nginx) for HTTPS if you’re exposing it beyond localhost

What makes it simpler than some alternatives:

• SQLite as the default database — no separate Postgres instance to manage
• No external ML API keys required — everything runs locally
• The .nomedia exclusion file pattern means you can integrate it into an existing folder structure without reorganizing

What can go sideways:

• The 4 GB RAM floor is real. Trying to run it on a 2 GB VPS will cause the ML services to crash or refuse to start. The face recognition pipeline in particular loads ONNX models that require headroom [1].
• The Microsoft Azure Face API dependency was removed, but the migration to local ONNX models is relatively recent. Older documentation still references Azure. Make sure you’re on a current release and not following outdated setup guides [README].
• No native mobile app means no background photo upload from your phone. If you want automatic photo backup from iOS or Android, you’ll need a separate solution (Nextcloud, Syncthing, rsync over SSH) to get photos onto the server first, then Damselfly indexes them from there [1].
• 1,752 GitHub stars and 89 forks indicate a small community. If you hit a bug that isn’t already filed, your options are opening a GitHub issue and waiting, or fixing it yourself. This is a solo developer project [README].

Realistic time to a working instance for someone with basic Docker experience: 45–90 minutes, not counting the time Damselfly takes to index an existing library (which runs in the background and can take hours to days depending on library size and whether ML features are enabled).

---

Pros and Cons

Pros

• Fully local ML. Face detection, face recognition, and object detection run offline on your server. No Azure, no Google Vision, no external API calls for any ML step [README].
• RAW format support. DNG, CR2, ORF, NEF — out of the box, no plugins [README].
• Non-destructive EXIF tagging. ExifTool writes metadata without re-encoding JPEGs [README].
• Scale-built search. Sub-second search across 500,000 images is a real benchmark, not marketing copy [README].
• Multi-user with RBAC. ReadOnly roles, shared baskets, multiple accounts — it’s not single-user software [README][1].
• Picasa-style basket workflow. Niche but meaningful for people who built habits around Picasa’s select-and-export model [README].
• Desktop client for sync. The Electron.NET client for macOS/Windows/Linux lets you sync basket selections to a local folder for editing — useful if your workflow involves Lightroom or Photoshop [README].
• GPL-3.0 license. True open source. Fork it, modify it, host it for clients [README].

Cons

• No native mobile app. No iOS or Android app, no background upload. You need a separate pipeline to get photos onto the server [1].
• 4 GB RAM minimum for ML. Eliminates the cheapest VPS tiers. If you skip ML, you could run leaner, but then you lose the main differentiator [1].
• Small community. 1,752 stars, 89 forks, primarily a solo developer project. Support means GitHub issues, not a Slack channel or active Discord [README].
• No cloud sync or remote backup. Damselfly manages your library but doesn’t back it up. You need a separate backup strategy for the underlying storage.
• GPL-3.0 restrictions. Unlike MIT, GPL-3.0 requires derivative works to also be GPL. If you’re embedding this in a commercial product, that’s a constraint.
• Limited third-party reviews. Finding real-world user reports beyond comparison roundups is difficult. Most community discussion happens on Reddit (r/DamselflyPhotos) and Twitter, which gives less signal about production reliability at scale than a tool with thousands of forum posts [README].

---

Who Should Use This / Who Shouldn’t

Use Damselfly if:

• You have a large existing folder-based photo library (tens or hundreds of thousands of images) and want fast, searchable access to it.
• You’re a photographer with RAW files who wants non-destructive EXIF tagging and local face recognition.
• Privacy is a hard requirement — you need everything indexed and processed on your own hardware.
• You used Picasa and want something with a familiar basket/export workflow.
• You’re comfortable with Docker and can provision a server with 4+ GB of RAM.

Skip it (use Immich instead) if:

• You want a mobile app for automatic photo upload from your phone. Immich has polished Android and iOS apps. Damselfly does not [1].
• You want a more active community, faster release cycles, and a project with broader adoption. Immich has significantly more GitHub activity and user base.

Skip it (use PhotoPrism instead) if:

• You want a more mature, better-documented self-hosted photo tool with similar ML capabilities. PhotoPrism has been around longer, has more third-party guides, and a larger user community [1].

Skip it (use Nextcloud Memories instead) if:

• You’re already running Nextcloud. Adding the Memories app is one click and reuses your existing infrastructure [1].

Stay on Google Photos if:

• You’re not willing to manage a server. Damselfly requires ongoing maintenance — OS patches, Docker updates, disk management. Google Photos costs money but requires zero server operations.
• Your library is under 100 GB and you’re within Google’s free tier.

---

Alternatives Worth Considering

From the comparison in [1] and the merged profile:

• Immich — the current community favorite for self-hosted photo management. Mobile apps for Android and iOS with background upload, active development, larger community. Requires 4 GB RAM for ML. More polished than Damselfly but less focused on large archival collections [1].
• PhotoPrism — the most mature option in this category. ML-backed face detection, good documentation, progressive web app. Also requires 4 GB RAM for ML. The freemium model (some features require a paid license) is worth understanding before deploying [1].
• Nextcloud Memories — best option if you’re already a Nextcloud user. Shares infrastructure, has a mobile app, integrates with Nextcloud Files. No ML support [1].
• Piwigo — older, PHP/MySQL-based, has Android and iOS apps, large plugin ecosystem. No ML. Good choice if you prioritize mobile access over face recognition [1].
• Lychee — lightweight, minimal resource requirements (512 MB RAM), clean UI, but no ML and no mobile app. Good for a public-facing photo gallery rather than a personal archive [1].
• PiGallery2 — the lightest option (512 MB RAM), runs on a Raspberry Pi, no ML, no mobile app. Best for a simple read-only gallery from an existing directory structure [1].

For a photographer archiving RAW files with face recognition requirements, the realistic shortlist is Damselfly vs PhotoPrism vs Immich. Damselfly wins if you value the Picasa workflow and purely local processing. PhotoPrism wins if you want better documentation and community. Immich wins if you need a mobile app.

---

Bottom Line

Damselfly occupies a specific niche: large, folder-based photo archives, managed by someone who cares about local processing and non-destructive workflows. It’s not trying to replace Google Photos for family photo backup (no mobile app), and it’s not trying to be a Lightroom alternative (no editing). It’s trying to be the self-hosted equivalent of Picasa with machine learning — and for that specific use case, it does the job.

The caveats are real. Small community, 4 GB RAM floor, no mobile client, limited third-party coverage to verify production claims. If you’re building a family photo station on a Raspberry Pi, look elsewhere. But if you’re a photographer with a 200,000-image RAW library sitting on a NAS who needs fast search, offline face recognition, and non-destructive EXIF tagging, Damselfly is worth an afternoon to evaluate. If that afternoon is the blocker, that’s exactly what unsubbed.co’s parent studio upready.dev deploys for clients.

---

Sources

1. MakeTechEasier — “Best Self-hosted Photo Management Software to Replace Google Photos”. https://www.maketecheasier.com/self-hosted-photos-management-software/

Primary sources:

• GitHub repository and README: https://github.com/Webreaper/Damselfly (1,752 stars, GPL-3.0 license)
• Project community: https://reddit.com/r/damselflyphotos
• Twitter: https://twitter.com/damselflyphotos