Immich

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me photo backup that replaces the cloud services, in the shape Immich has: my phone uploads by itself, everything is searchable, and nothing leaves my own machines.

Read this first, twice. Immich is free and excellent, and this prompt exists because the honest cost here is not money — it is that you are now the one responsible for never losing your family's photographs. Nobody is coming to restore them. If you are not going to test a restore, keep paying somebody else.

STACK
- Node 20+ with Fastify for the server
- SQLite through better-sqlite3, WAL mode, with FTS5 for search
- sharp for thumbnails, ffmpeg for video, exiftool or an equivalent for metadata
- A mobile app, or a PWA with background sync where the platform permits it
- Caddy in front

THE DATA MODEL
- assets: id, owner_id, device_asset_id, kind, original_path, original_name, sha256, bytes, width, height, duration_ms, taken_at, taken_at_offset, timezone, latitude, longitude, camera_make, camera_model, lens, iso, aperture, shutter, is_favourite, is_archived, deleted_at, uploaded_at
- derivatives: id, asset_id, kind, path, width, height, bytes — thumbnails and transcodes, regenerable and therefore not backed up
- albums, album_assets, shares, share_tokens
- people: id, name, cover_asset_id; faces: id, asset_id, person_id, bbox_json, embedding_blob, confidence
- places: derived from coordinates against a local gazetteer, never an online lookup
- tags, and search_index over filename, camera, place, people and any recognised text
- jobs: id, kind, asset_id, status, attempts, error — thumbnailing, metadata, transcoding, face detection
- The original file is never modified. Not to rotate it, not to strip anything, not ever. Every operation produces a derivative

UPLOADING FROM A PHONE, WHICH IS THE ENTIRE PRODUCT
- Background upload of new photos and videos, on wifi by default, resumable, and it must survive the app being killed
- Deduplication by hash before upload: the client asks whether the server has this hash and skips it. Re-uploading a library over mobile data is how somebody ends up with a large bill and a grudge
- Chunked upload with resume from the last confirmed chunk
- The device keeps the file until the server confirms the hash of what it stored. Confirm by re-hashing on the server, not by trusting the client
- Upload state visible: how many remain, what failed and why. A backup you cannot verify is not a backup, and this screen is where trust is built or lost
- Never delete from the device automatically. Offer it, once, after the asset is confirmed and backed up

METADATA AND TIME
- EXIF read on ingest: the time the photo was taken, its offset, the camera, the lens and the coordinates
- Store the local time and the offset separately. A photo taken at 8pm on holiday was taken at 8pm, and showing it at 3pm because the server is elsewhere is wrong in a way people notice immediately
- Files with no EXIF fall back to the filename pattern, then the file time, and the source of the date is recorded so a wrong one can be found later
- Live photos, bursts and RAW-plus-JPEG pairs kept together as one asset with several files
- Video metadata from ffprobe, with rotation respected

DERIVATIVES AND SEARCH
- Thumbnails at a few sizes, generated by a worker, with the queue visible
- Video transcoded to a widely playable form, keeping the original untouched
- Faces detected and clustered locally, with a name attached by hand. No cloud service, ever — the point is that these photographs are seen only by you
- Places from coordinates against an offline gazetteer
- Optional local text recognition, so a photo of a sign becomes searchable
- Search across dates, places, people, cameras, filenames and text, with everything filterable together

VIEWING AND SHARING
- A timeline that scrolls years quickly, grouped by day and month
- Albums, favourites, archive, and a real trash with a stated retention before it actually deletes
- Share an album or an asset by a long unguessable token, optionally with a password and an expiry, revocable
- A shared link must not expose anything but what was shared, including in the API responses behind it

STORAGE AND THE THING THAT MATTERS
- Originals on a filesystem laid out by date, so they are usable with no software at all if this application disappears. That property is worth more than any feature
- Storage usage per owner, and a warning long before the disk is full
- A second copy, always, on a different machine or a different provider. RAID is not a backup, a snapshot on the same disk is not a backup, and a copy you have never restored from is not a backup
- Verify: a scheduled job that re-hashes a sample of originals and reports any that have changed. Silent bit rot over ten years is the failure nobody plans for
- A restore rehearsal documented and performed, with the time it took written down

OPERATIONS
- .env: DATABASE_PATH, LIBRARY_PATH, DERIVATIVE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once
- Reachable over a VPN rather than exposed to the internet, unless you have decided otherwise deliberately
- Nightly backup of the database, plus an off-site copy of the originals with its own schedule and its own verification
- Health endpoint reporting free space, queue depth and the age of the last verified backup

WHAT MATTERS MOST
Upload reliability and the second copy. Build resumable deduplicated upload with server-side hash confirmation, then set up the off-site copy and restore from it onto a clean machine before you move a single real photograph. Everything else here is a gallery.

Give me the repository, the upload client, migrations, .env.example, the backup and restore scripts, and a README that opens with the restore rehearsal.