Scoping a Local-First Image Archive

A screenshot of a simple image archive viewer showing a folder of photos with thumbnails and metadata. The interface is minimal, with a clean layout and basic navigation.
My quick prototype. An image archive viewer that's can be opened in a browser by clicking an html file

For a long time I’ve been thinking about how we store and access our digital files, especially photos. Everything keeps drifting toward cloud platforms and increasingly complex apps that sit on top of what is, at its core, just a folder of images.

I don’t really want that.

I want something simple. No server. No database. No lock-in. Just something that works directly with files and folders, something that could disappear tomorrow without breaking anything, or be run once and still make sense years later.

After building a rough Node.js prototype and seeing the value, this is a clearer dump of why I want to take it further.

1. The problem with modern photo platforms

Tools like Google Photos and iCloud Photos are excellent for managing a current stream of life. Syncing, search, and quick organisation all work well.

But they are not really designed for long-term archiving.

They assume:

  • a database will always exist
  • AI and indexing layers will always run
  • subscriptions and ecosystems will continue
  • exports are a reasonable fallback

In practice, exports are messy, metadata is fragile, and organisation often disappears once you leave the platform.

For non-technical families, the real question is simpler:

In 10 or 20 years, can someone just browse these photos?

That should not be complicated.

A well-structured folder on a few drives, properly backed up, is already a solid archival solution. We tend to overbuild on top of it.

2. Files last longer than apps

There’s a broader shift back toward plain text and filesystem-first thinking. Notes, documentation, and knowledge bases are moving away from databases and proprietary formats toward simple, readable files.

Because files endure.

The same idea applies to images:

  • a folder is already a collection
  • a small meta.md file can hold optional context
  • removing the viewing tool should not damage anything
  • the filesystem itself is the structure

This isn’t reinvention. It’s restraint.

3. A local, zero-dependency image archive

The goal is a tiny tool that:

  • works fully offline by opening an index.html in a browser
  • has no server and no database
  • never renames or alters original files
  • leaves nothing behind if removed
  • uses minimal, customisable CSS

In practice, it behaves like a static site generator that lives inside your photo library.

Ignore it completely and your files remain normal. Use it when you want a clean way to browse.

4. Minimal JavaScript

Ideally the output is just HTML and CSS.

JavaScript should only enhance:

  • folder navigation
  • lazy loading
  • small accessibility improvements

If JavaScript is disabled, the archive should still function.

5. Filesystem as the database

Structure stays simple:

Photos/
    β”œβ”€β”€ 2024-Scotland-Trip/
    β”‚   β”œβ”€β”€ image1.jpg
    β”‚   β”œβ”€β”€ image2.png
    β”‚   β”œβ”€β”€ meta.md
    β”‚   β”œβ”€β”€ .thumbs/
    β”‚   └── index.html
    β”œβ”€β”€ 2023-Italy/
    β”‚   β”œβ”€β”€ photo.jpg
    β”‚   β”œβ”€β”€ meta.txt
    β”‚   β”œβ”€β”€ .thumbs/
    β”‚   └── index.html
    β”œβ”€β”€ style.css
    └── index.html
  • Folders act as categories
  • Metadata is optional and readable
  • Thumbnails are generated but originals stay untouched

No services. No hidden state. Just files that remain understandable years later.

6. How it runs

A small background process, or a manual command:

  • scans for changes
  • generates thumbnails
  • writes static indexes
  • never touches originals

Open the root folder in a browser and browse normally.

That’s the whole system.

7. Moving beyond Node.js

The prototype works in Node, but it’s heavier than it should be. Dependencies grow, distribution is awkward, and any UI tends to drift toward Electron.

The real goal is a tiny native binary written in Rust or Go:

  • a single small executable
  • fast and low memory
  • no runtime dependencies
  • simple cross-platform use

Run it, point it at a folder, and it quietly does its job.

8. Keep it simple

This idea is intentionally opinionated:

  • folders are the source of truth
  • metadata is optional and readable
  • nothing relies on the cloud
  • removing the tool changes nothing

It’s not another photo manager. It’s just a lightweight way to browse an archive of images in a form that will still make sense years from now.

I’ll start experimenting with a Rust version soon. If this resonates, I’d be interested to hear how others think about long-term photo storage too.