a7f5d2d0bf
The pieces existed across three pages and nothing connected them, so "can we go from IIS to Docker" had no answer to point at. It is a fair question with a short answer: the application keeps state in exactly two places, the database and the instance directory, and nothing is encrypted at rest with SECRET_KEY or JWT_SECRET_KEY, so a move is a dump plus a directory copy. The schema is identical across topologies. What the page spends its length on is the part that is NOT the data, because that is where the time goes. The server address is baked into things that are not the server: GE-Enforce manifests, the generated collector script, the printer client scripts, and printed QR codes, which cannot be swept at all. Keeping the hostname and repointing DNS makes the migration invisible to the fleet; changing it does not. Three other traps, each of which has a symptom that shows up later rather than at cutover: an aliased IIS site needs MOUNT_PATH and a dist built for that subpath, while the image builds for the root; an older dump can carry latin1 or 3-byte utf8 table definitions that load quietly into a utf8mb4 server and only misbehave on the first accented name; and a restored instance directory needs chown, because docker cp writes under the copying user's uid and the container runs as shopdb. Covers both directions plus Docker to a new Docker host, and ends with a cutover checklist that leaves the old stack stopped rather than removed until a bay has checked in on a working day. Also fixes two links in START-HERE that pointed at files which are not there: the ADR index needed its adr/ prefix, and LLM-GUIDE.md is llms.txt.
3.2 KiB
Start here
ShopDB is a per-site asset platform: one instance per plant, plugins for what each site tracks. These pages document the server, the plugin contract, and the tools that run on shop-floor PCs.
Find yourself below. Each row is the shortest correct path, not everything that exists.
I am standing up ShopDB at a new site
- INSTALL-WINDOWS - one offline installer, start to finish.
- OPERATE-WINDOWS - restart, logs, backups, upgrades.
- CSV-IMPORT if the site's data is in spreadsheets, or IMPORT-API if there is a source database to script against.
- FLOOR-MAP - load the site's floor plans and place markers. Also the page to read BEFORE a plan changes: it covers moving every marker onto a redrawn plan without doing it one at a time.
Do not follow INSTALL-WINDOWS-IIS for a new site. That is the manual procedure, kept for hand-built servers that predate the installer, and following it produces a server the installer then refuses to upgrade.
I am deploying the shop-floor tools
Read FLEET-ARCHITECTURE first - it is one page and it is what makes the rest make sense.
Then ADOPTING-AT-ANOTHER-SITE, which has worked examples for Intune, GE-Enforce and manual installation, and says where each artifact comes from.
I am writing a plugin
- PLUGIN-QUICKSTART - scaffold and first run.
- PLUGIN-HOOKS - the contract. Authoritative.
- PLUGIN-LAB-PRINTEDPARTS - a real plugin built end to end, to type along with.
- PLUGIN-EXTERNAL-REPO if it lives in its own repository, and CONTRACT-STABILITY before you choose a version pin.
I am integrating with the API
- LLM-GUIDE (
docs/llms.txtin the repo, also served at/api/docs/llms.txt) - auth, the response envelope, common recipes. Short, and the envelope section is the part people get wrong. GET /api/docson any running instance - the full spec, browsable.- API-REFERENCE for prose, COLLECTOR-INTEGRATION if you are feeding data in from a PC.
I am trying to understand why something is built this way
The ADRs. They are the decision record, they say what was rejected and why, and they are the fastest way to avoid relitigating a settled question. PROJECT-MAP lists them all with their status, along with the current versions and every migration head - it is generated, so it is never stale.
Something is broken
- Server: OPERATE-WINDOWS, then
shopdb-admin.ps1 check -Json. - A PC or a bay: the symptom table at the end of FLEET-ARCHITECTURE says which piece to open first.
- A deploy that half-worked: UPGRADE and BACKUP-RESTORE.
I am moving a site to a different server or stack
MIGRATE-TOPOLOGY - Windows/IIS to Docker, Docker to a new host, and back. The data moves cleanly; the URL the fleet points at is the work.