Pics.io already runs on storage you own. You point it at a Google Drive or an S3 bucket and the files stay in your account, which is the thing I had assumed I was building an alternative to and is not. What you are paying for is the software sitting on top. So what OpenPics actually replaces is the subscription rather than the storage, and the whole of that argument is in the README's setup section: make a bucket, paste in an IAM policy scoped to it, add a CORS rule so a browser can PUT straight into it, run one SQL file in the Supabase editor, fill in four keys. After that the running cost is whatever S3 was already charging you, a free Supabase project, and fractions of a cent an image. The bucket mine points at is one that already existed from client work, which is exactly the case this was built for and also the reason there is nothing sitting in it that I can photograph.

The search box says 'red car at night' in its placeholder, and it does find the red car, and the way it does that is less clever than it sounds. On upload the image goes to a vision model under a strict JSON prompt: eight to fifteen lowercase tags, two to five dominant colours chosen only from a fixed list of twelve, and one sentence covering subject, setting, mood and lighting. Then that sentence is what gets embedded. Not the image. The text the model wrote about the image, with the tags and the colours and the filename glued on the end, into 1536 dimensions in a pgvector column with a cosine index over it, and a query is embedded the same way and matched against those. Which means the search works exactly as well as the sentence does. If the model wrote 'a vintage sedan on a wet street at dusk', then 'red car at night' will not find it, and nothing in the system is capable of noticing. It also reads the 512 pixel thumbnail rather than the original, because that is cheaper, and I decided cheaper mattered before I had any way to measure what it cost me.

Postgres is what everybody is looking at, and for a long time nothing on top of it told a screen that anything had changed. Everything the interface knew it learned from a fetch it made itself, and the way it found out about a change was a counter in a React context that other code increments when it has a reason to. Tagging survives that by an accident of the schema rather than by design: tags are unique on name and kind, the join table is keyed on the pair of ids, and the writes are upserts that ignore duplicates, so two people adding 'sunset' to the same photo at the same moment produce one row and no argument. Everything else is last write wins with no version check, and that half does not go away when the screens start updating themselves. If you rename a file while I am renaming it, one of us wins and neither of us is told, and a subscription only means we both watch it happen sooner. The design spec I wrote for the ten second undo on delete says the quiet part in its own trade-offs section: the undo lives in the tab that pressed delete, and every other tab goes on showing the asset until the real delete lands. Then both S3 objects and the row are gone. There is no trash. The subscriptions are what I am adding now, and they close the smaller half of this. The larger half is deciding who wins.