Tagging and storing classic car data in a self-hosted inventory tracker
A self-hosted inventory tracker works best when each car gets one clear record, a small set of tags, and a storage layout that does not fall apart when attachments grow.
Start with the data you actually need. For a collector shortlist, that is usually make, model, year, chassis number, registration, colour, purchase status, location, and a short condition note. Add tags for fast filtering. A tagging system works well when each tag answers one plain question, such as project, sold, unrestored, matching numbers, or concours. Keep the tag set tight. If a tag only applies once a year, it is probably noise.
For notes, separate facts from opinions. Put dates, auction references, service history, and inspection findings in the note field. Put your judgement in a short summary line at the top. That keeps search useful. It also stops the record turning into a wall of text that nobody wants to open twice. If you are tracking multiple cars, use the same note pattern for every entry. Consistency beats cleverness.
Attachment storage needs more care than the rest of it. Store images, scanned logbooks, invoices, and inspection sheets outside the database, then link them from the record. In practice, that means an attachment storage path or object store, plus metadata in PostgreSQL. Keep filenames predictable. A simple pattern such as year-make-model-chassis-documenttype.pdf is easier to recover than IMG4837final2_reallyfinal.pdf. If you ever have to restore the lot at 2 a.m., future you will not thank present you for being creative.
Use a compose file to pin the stack. Keep the app container, PostgreSQL, and attachment storage service on the same network. Mount the database to a persistent volume. Mount the attachment store to a separate persistent volume or object-backed path. That separation matters because database restores and file restores do not fail in the same way. A broken database backup with healthy files, or the other way round, is still a broken restore.
The backup pattern should cover both parts together. Dump PostgreSQL on a schedule, then snapshot or copy the attachment storage on the same schedule. Keep the database dump and the file backup in matching timestamps or run IDs. That gives you a restore point that actually belongs together. Test one full restore before you trust anything. Check that the car records open, the tags still filter, the notes are intact, and at least one attachment loads. If the attachment path is wrong, the tracker will look fine right up until you need an invoice.
A simple tagging rule helps more than a fancy structure. Use one tag set for status, one for provenance, and one for type. For example, status tags can be project, stored, or sold. Provenance tags can be private sale, auction, or inherited. Type tags can be saloon, coupe, roadster, or parts car. That split keeps searches readable. It also stops you from creating overlapping tags that mean the same thing in slightly different words.
If you need to change the data later, do it in one place. Add fields for anything you sort on often. Keep notes for everything else. Use attachments for evidence, not for the only copy of information that matters. That is the boring version, which is usually the one that survives six months without drama.
