Photofield: a single Go binary that renders your photo library as map tiles
A self-hosted non-invasive single-binary photo gallery with a focus on speed and simplicity.
At a glance
- What is it?
- Photofield turns a read-only directory of photos into a zoomable tiled canvas served from one static binary, with SQLite as a disposable cache. It is built for one fast viewer on commodity hardware, not for a household of concurrent users.
- Who is it for?
- Adopt Photofield if you have a large local photo directory on fast storage, you are the only regular viewer, and you want the filesystem to stay the source of truth with no import step. Do not adopt it if several people will browse at once, or if you need accounts: the README states there is no authentication or authorization.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 30 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Photofield picks: layout and delivery, not library management
Most self-hosted galleries ask you to import first. They copy or move files into a managed store, write their own database of record, and then render a grid. Photofield inverts that. The README describes the project as non-invasive and states that the file system is the source of truth while everything else is a more or less stale cache. Nothing is written back to your originals, and the documentation encourages mounting the photo directory read-only so that this stays true.
The target user is someone who already has a directory tree of photos, often tens of thousands of files, and wants to browse it quickly without a migration. The stated goal is to be as fast or faster than Google Photos on commodity hardware while showing more photos at once. The README's own demo asset is a zoom into a logo within a sample of 43k images on an i7-5820K with an NVMe SSD. That is a single-machine, single-viewer framing, and it shapes nearly every design decision in the project.
So the scope is narrow on purpose. Photofield is a viewer. It does not claim to be your backup, your metadata editor, or a multi-tenant service.
Tiles, not thumbnails: how the rendering pipeline is put together
The architecture borrows from web maps. The README lists OpenLayers as the in-browser tiled image renderer and Canvas (tdewolff) as the Go-side vector rendering library, which tells you where the work happens: the server computes layout and renders image tiles, the browser composites them on a zoomable canvas. Every view is zoomable, and the whole layout loads progressively from a low-resolution preview up to full quality.
Because layout is server-side, the browser is not deciding where each photo sits. That is the reason the README warns that initial load can be slow: all photos must be laid out the first time a page is opened at a particular window size and configuration, and on a slow CPU with a cold HDD cache that takes time. It is also the reason for the stated concurrency limit, since a lot of normally client-side state lives on the server.
The thumbnail system is where the project earns its speed claims. According to the README, small thumbnails are stored in SQLite, FFmpeg handles on-the-fly format conversion, embedded thumbnails are extracted directly from JPEG files, existing Synology Moments or Photo Station thumbnails are reused, and djpeg (libjpeg-turbo) decodes lower resolutions efficiently. Four different sources for one thumbnail, each cheaper than a full decode. Indexing is separate from enrichment: the README gives file indexing at 1000 to 10000 files/sec on fast SSD with hot cache, with EXIF metadata and prominent color extracted as follow-up operations at up to roughly 200 files/sec and 1000 files/sec respectively. Those are the project's own figures, not measurements taken here.
Getting a binary running and pointing it at a directory
The README points to a Quick Start page at photofield.dev/quick-start and a documentation site, and it states that the server is a single static binary with optional dependencies, plus Docker images. The repository's own documentation is the authority on the exact flags; the material supplied here does not enumerate them, so treat the quick-start page as required reading rather than guessing at a command line.
What the README does make concrete is the shape of the deployment. You give the server a directory of photos, and the README recommends mounting that directory read-only. The cache lives in SQLite as a single file, and the README describes it as disposable: remove the database and things still work, though links may break. Optional capabilities are gated behind separate components rather than baked in. Semantic search and face detection both depend on photofield-ai; reverse geolocation for roughly 50 thousand places comes from tinygpkg and is described as supported in the Timeline and Flex layouts with negligible overhead; FFmpeg is needed for on-the-fly format conversion. Tagging and face detection are both labelled alpha in the README, and tags are stored in the cache database rather than in your files, which means they share the cache's disposable status.
That last point deserves emphasis. If you tag photos and then delete the SQLite cache to rebuild it, the README's own description of tags living in the cache database implies those tags go with it. There is no sidecar file mentioned.
Where Photofield breaks: concurrency, accounts, and the first page load
The README's Limitations section is unusually blunt, and it should be read before installation rather than after. First, the project is not optimized for many clients. Because server-side state does the heavy lifting, more than a few simultaneous users will likely produce CPU or memory problems. A family of five browsing at once is outside the design envelope.
Second, there are no user accounts. The README says this is not the focus right now, and that while you can define separate collections for separate users through directory structure, there is no authentication or authorization support. Exposing this to the open internet without a reverse proxy that handles auth is not something the project protects you from.
Third, the initial load can be slow, for the layout reason described above. On a cold spinning disk with a weak CPU, the first page in a given window size is the worst case.
Fourth, there are no permalinks in the durable sense. Deep linking to images works, but the README warns that links may break if you remove the database or move files around. Combined with the cache-as-disposable model, that means URLs are stable only as long as the cache is.
Video is a fifth boundary. Videos are supported, including multiple resolutions if they were pre-generated by something like Synology Moments, but the README states plainly that on-the-fly transcoding is not supported. A directory of arbitrary phone videos will not be normalized for you.
How it differs from Immich and PhotoPrism
The obvious alternatives are Immich and PhotoPrism, and the difference is not feature count. It is where the source of truth lives. Both of those projects ingest photos into an application-managed library with its own database and its own metadata model; the app becomes the system of record, and features like user accounts, mobile upload, and sharing are built on top of that assumption. Photofield does the opposite. It reads the directory, caches derived data in SQLite, and treats the cache as replaceable. The README even frames the project as something that can complement other gallery software rather than replace it.
That inversion buys you no import step and no risk of a migration mangling your originals, and it costs you everything that depends on a managed library: accounts, per-user permissions, upload flows, durable tags and faces. Photofield's tagging and face detection are alpha and stored in the cache. Immich's equivalents are part of the product's data model. If you want a photo service with logins, pick the other category. If you want a fast lens over a directory you already control, Photofield is the narrower and cheaper thing.
Maintenance, releases, and what the MIT licence leaves you
The release cadence visible in the material is steady and recent: v0.24.0 in June 2026 added faces, filename search, and layout improvements; v0.24.1 two weeks later was labelled security patches; v0.25.0 in August 2026 added an MCP server alongside stability improvements. The existence of a dedicated security-patch release is a signal worth noting, and it also means you should expect to track versions rather than pin once and forget.
The upgrade cost is mostly in the cache. Because derived data lives in SQLite and the README treats it as disposable, a schema change between versions is plausibly handled by rebuilding rather than migrating, but the supplied material does not state an upgrade procedure, so verify against the documentation for your version before assuming. The same applies to tags and face data: anything stored only in the cache is at the mercy of a rebuild.
The licence is MIT, which is permissive and imposes no copyleft obligation on your deployment. This is not legal advice; read the LICENSE file in the repository if the distinction matters to your organisation. Note that the optional components are separate projects with their own licences: photofield-ai, tinygpkg, FFmpeg, and the Go and Vue libraries listed under Built With. If you ship a container that bundles FFmpeg, check that component's terms separately.
Who should run this, and what to check first
The fit is specific. You have a large photo directory on fast local storage. You browse it yourself, mostly from one machine at a time. You already have a backup strategy that does not depend on the gallery, because Photofield never becomes the source of truth. You want the zoomable, all-at-once browsing model rather than a paginated grid, and you are willing to accept that the first load in a new window size will pause while the server lays everything out.
The misfit is equally specific. Multiple simultaneous viewers, shared family access, or any exposure to the public internet without an authenticating reverse proxy in front. Anyone who needs on-the-fly video transcoding. Anyone who wants tags or face groupings to survive independently of the SQLite cache.
What to verify before you commit: run the quick-start from photofield.dev against a small subset of your library first and time the initial layout on your actual hardware, since the README's speed figures assume fast SSD and hot cache. Confirm which optional dependencies you need and whether they are present in your chosen deployment. Then decide whether the absence of accounts is acceptable for where you plan to put it.
Editorial conclusion
Adopt Photofield if you have a large local photo directory on fast storage, you are the only regular viewer, and you want the filesystem to stay the source of truth with no import step. Do not adopt it if several people will browse at once, or if you need accounts: the README states there is no authentication or authorization. Before committing, verify which optional dependencies your deployment actually needs (FFmpeg for on-the-fly conversion, photofield-ai for semantic search and faces, tinygpkg for reverse geolocation), and confirm that your video files already have pre-generated resolutions, because the README says on-the-fly transcoding is not supported.
Community notes