Nobody reads your library
No advertising profile, no training data, no scanning. Face recognition and search run as local processes on your box — there is no cloud service to send them to.
Self-hosted gallery & file manager
Your photos and files.
Your photos and files.
Your machine.
Your rules.
Smriti is a complete gallery and a real file manager, running on a server you own. It finds faces, understands what is in your pictures, and helps you clean up twenty years of duplicates — while your documents, videos and folders stay exactly where you put them. Every bit of it happens on your hardware: your photos and files never leave your machine.
Runs on modest hardware — the reference deployment is a fanless 4-core i3 with no graphics card.
Why run it yourself
The photos are yours. The server should be too.
Every cloud gallery is the same deal: they hold your memories, and you pay monthly for permission to look at them. Smriti is the other deal.
No subscription to see your own photos
You already bought the disks. Smriti does not meter them, does not expire your library, and does not lock features behind a monthly renewal.
No upload limits
Your ceiling is the size of your drives. Add a disk and the ceiling moves. Administrators can still set per-user quotas when a server is shared.
A real replacement
Smriti is built to take over from Google Photos or Immich, not sit beside them. It reads your existing folders where they already are.
What is in the box
A gallery and a file manager, not a compromise between them.
Most self-hosted photo apps make you choose: a pretty timeline you cannot organise, or a file browser with no sense of what a photograph is. Smriti is both, over the same files.
Timeline gallery
Scroll years in a flick with a date scrubber, open anything in a viewer with deep zoom, and gather what matters into albums.
People, found automatically
Faces are detected and grouped into people on your own machine. When it guesses wrong you correct it, and the merge review loop learns from the correction.
Search by what you remember
Describe the picture rather than the filename. Semantic search matches on image content, alongside ordinary search by name, tag and date.
Full file manager
Browse, move, copy, rename and delete — individually or in bulk — with tags, favourites and bookmarks over the same library.
Trash that actually recovers
Deletes go to a recoverable trash rather than straight off the disk, so a misplaced click is an undo and not a phone call about backups.
Duplicates, dealt with
Twenty years of copied folders get detected and consolidated down to one copy — the reason this project exists.
Rules engine with a dry run
Describe how you want things filed. Smriti stages the matches for your review, shows you the dry run first, and every applied batch can be undone.
Memories and places
Resurfaced memories from years past, and an offline map that turns the coordinates in your photos into the names of the places you went.
Share a link, keep control
Public share links for the people who are not on your server, protected with a password and an expiry date you set.
Genuinely multi-user
Every member of the household gets their own library, strictly isolated from the others — enforced in the database, not just hidden in the interface.
An admin panel worth the name
Users, storage roots, background jobs, statistics, quotas, notifications and an audit trail — all in the app, no editing config files over SSH.
Backups that tell you when they stop
The database backs itself up nightly, and raises an alarm if a backup ever goes stale — because a silent backup failure is the same as no backup.
The Vault
A private half of the app, behind a PIN.
Some photographs are nobody else's business. Unlock the Vault with a PIN and the whole application re-scopes to your private content — the same gallery, the same file manager, the same face recognition, over a completely separate set of files.
It is a sandbox, not a hidden folder. Nothing in the Vault appears in the normal library, and nothing from the normal library leaks into the Vault. Isolation runs in both directions.
- Full feature parity — the Vault is not a stripped-down viewer. Albums, search, faces, rules and file operations all work inside it.
- Enforced below the interface — scoping is applied at the data layer, so a forgotten filter in one screen cannot expose vaulted content.
- Separate by default — vaulted media stays out of timelines, search results, people pages and share links unless you are unlocked.
- Move things in and out — drag content into the Vault when you decide it belongs there.
1,284 duplicates found across 6 foldersAwaiting review
Photos of one person, gathered to a folderDry run
Loose screenshots tidied by file typeUndoable
Illustration of the staged-review flow. Numbers are an example, not live data.
Consolidation
It proposes. You decide. Nothing moves behind your back.
A photo library that grew across phones, laptops and backup drives is mostly duplicates. Smriti scans for them in the background and then does the careful thing: it tells you what it found and waits.
Every organising action shows a dry run before it touches a file, stages the result for your approval, and stays undoable afterwards. Your originals are the one thing the product will not gamble with.
How you use it
Point it at what you already have. Nothing moves until you say so.
No import, no re-upload, no new folder structure to learn.
-
1
Point it at your folders
Your existing directories on your existing disks. Smriti reads them where they are.
-
2
It reads and understands them
Faces, places, text in documents, duplicates — computed by models running on your own box.
-
3
You review, then it acts
Every clean-up is proposed first, applied only on your word, and undoable afterwards.
What you get out of it
Twenty years of mess, made findable.
Ask for anything
Search finds the photo of a card, the person in it, or the beach you went to — by name, not by filename.
One copy, not eleven
Duplicate detection reclaims the space a decade of phone backups quietly ate — reversibly.
A private half
The Vault is the whole app again, sealed behind a PIN — not a hidden folder with the lights off.
Files, properly
Real file operations with a recoverable trash — the gallery does not hold your documents hostage.
Get started
Run it on your own server today.
One command for a Linux box, a form for TrueNAS SCALE, or read the Compose file yourself first — your choice.
On your server
Not published yet
Docker + Compose on any Linux host. Checks the container runtime, disk space and the port before touching anything, and prints the plan before it starts.
curl -fsSL https://get.smriti.cloud/install.sh | shThe installer is written, but Smriti's source is not public yet, so this command does not run today — it goes live with the first public release. The Docker install & configuration guide already documents every step and setting if you want to set it up by hand now.
On TrueNAS SCALE
Packaged as a community catalogue app. Storage roots, ports, passwords and resource limits are all on the install form — no compose file to hand-edit.
Not published yetThe app is packaged but not yet submitted to the TrueNAS catalogue. The full TrueNAS install guide covers adding the catalogue, every setting on the form, and the dataset and permission setup TrueNAS's NFSv4 ACLs need.
Desktop, Android and iOS apps are being built — nothing is downloadable yet. Until then, the web app is fully responsive and already works today in any modern browser, on a phone, a tablet or a desktop.
Desktop
Windows, macOS, Linux
In developmentAndroid
Phone & tablet
In developmentiOS
iPhone & iPad
In developmentTablets
Adapted native layout
In development
For developers
The short technical version.
Not a stack list — how the interesting parts actually work.
- Finding duplicates
- Exact copies: group by file size first — a unique size cannot have a twin — then
SHA-256only the survivors and group by digest. Near-duplicates (the same shot resized, re-compressed or screenshotted): a perceptual hash per image, clustered by Hamming distance under a threshold you control. - Recognising people
- Detect faces, turn each into a vector, then cluster the vectors into people. When you merge two clusters or say "that isn't them", the correction is stored and feeds the next clustering pass — it is a review loop, not a one-shot guess.
- Understanding pictures
- Each image gets an embedding that puts pictures and words in the same vector space, so "beach at sunset" matches a photo that was never tagged. Stored next to your data and searched by vector similarity.
- When the work happens
- Nothing heavy runs in a web request. Indexing, thumbnails, face scans, dedup passes and your rules are queued jobs on schedules you set in the admin panel — and they are change-driven, so an idle library costs nothing.
- Not melting your box
- Heavy jobs check the CPU temperature before and during each unit of work and back off when it climbs. The reference machine is a fanless i3, so throttling is a first-class feature rather than an afterthought.
- Keeping users apart
- Isolation is enforced in the database with row-level security, not by remembering to add
a
WHEREclause. Every file path is additionally jailed to its owner's root, so a crafted path cannot escape it.
The stack, briefly, for the person deploying it: Python/FastAPI, PostgreSQL with
pgvector, Redis-backed job queue, a separate CPU-only ML container with no
published port, a React front end served as static files, all via Docker Compose.
What self-hosted concretely means
Every one of those containers runs on your box. The database is yours, the thumbnails are yours, the face vectors and the search index are yours. Smriti reads your existing folders in place — it does not demand that you import your library into an opaque store first.
The ML runs on your hardware
Face detection and CLIP embeddings are computed by a local worker on CPU. Model weights are baked into the image at build time with pinned checksums, so nothing is fetched at runtime and no image is ever sent anywhere for inference. Slower than a GPU cloud; it is your data, and it only has to happen once per file.
Hardware expectations
The reference deployment is a fanless 4-core i3 with 16 GB of RAM and no GPU, on TrueNAS SCALE. Heavy work is queued, throttled and thermally aware rather than assumed to be free. A GPU is not required and is not used.
Honest scope
What it does not do — stated plainly.
A privacy product that oversells itself is not a privacy product. This is the part most landing pages leave out.
About the network
- Your photos and your data never leave your machine. No content, no thumbnails, no embeddings, no telemetry, no analytics.
- Smriti is designed to run on your LAN, and the media pipeline makes no outbound connections at all.
- Optional extras that genuinely need the internet — such as downloading offline map tiles for your region once — are administrator-enabled, off by default, and carry none of your content.
- This very page loads no trackers, no analytics and no third-party scripts. The fonts are served from the same origin.
Not built yet
- No live video transcoding. Playback is direct play with seeking; there is no adaptive bitrate. The reference hardware has no GPU and this is a deliberate scope decision, not an oversight.
- No native apps to download today. Android, Windows and Linux clients are in progress; there is no iOS or macOS build. Smriti runs in the browser.
- Semantic search is new. It works, and the index is still being backfilled — treat it as young rather than finished.
- Translations are partial. 60+ languages are selectable, 14 have hand-written catalogues; the rest fall back to English rather than shipping machine-translated guesses.
Smriti · स्मृति · memory
Keep your memories where you can reach them.
Named for the Sanskrit word for remembrance. Built to outlast whichever company would otherwise have been holding your photographs.