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.mdfile 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.htmlin 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.