Keysat
97ed07fd07
Removes the one-time `/data` snapshot from the deployed Docker image now that the cutover from the legacy `workout-log` package is verified done (v1.0.0:1 + :2 in production). Dockerfile - Drops `COPY start9/0.4/seed/data /app/seed/data`. - Drops the `WORKOUT_BAKED_SEED_DB_PATH` env var. - Comment block explains the rationale + how to re-seed if ever needed. docker_entrypoint.sh - Step 1 collapses to single-branch fallback: if /data is empty AND /app/prisma/data/app.db exists, copy the empty-schema fallback. The baked-seed branch is gone. - Comment cross-references v1.0.0:3 for the rationale. start9/0.4/seed/README.md rewritten to reflect historical-only status + how to re-seed for the rare "spin up another instance with this history" case. Version graph - Adds startos/versions/v1.0.0.3.ts with empty up/down migrations and release notes. - Promotes v1.0.0:3 to `current`; v1.0.0:1 and :2 move to `other` so hosts on either upgrade in place. No schema changes, no data migration. /data on existing installs is left exactly as-is. Image size drops by ~1.7MB (the snapshot size).
2.4 KiB
Seed snapshot (historical, post-cutover)
This directory holds the one-time snapshot of /data/ that was used to
cut the legacy workout-log StartOS package over to proof-of-work in
v1.0.0:1. As of v1.0.0:3 the snapshot is no longer baked into
the deployed image — it stays here purely as a historical artifact and
as a starting point if you ever want to spin up a new instance with
pre-loaded history.
Privacy: the snapshot contains real workout history, exercise records, and a bcrypt'd password hash. The repo's
.gitignoreexcludesstart9/*/seed/data/*.dband*.bakso it never ends up in version control. Do not change that.
Source
| Field | Value |
|---|---|
| Source files | proof-of-work-2026-05-09T16-46-11-646Z.db (latest cutover snapshot) |
| Exported from | StartOS 0.4 host running workout-log v0.1.0:20 |
| SQLite integrity check | ok at snapshot time |
The earlier app.db.bak file (when present on disk) is the previous
snapshot kept around as a manual rollback; it is also gitignored.
What the entrypoint did with this seed (v1.0.0:1 only)
On first boot of v1.0.0:1, docker_entrypoint.sh checked for
/app/seed/data/app.db. If /data/app.db did NOT exist AND
/data/.seeded did NOT exist, it copied the snapshot into /data/
and wrote /data/.seeded with a timestamp. On every subsequent boot
that branch was skipped.
v1.0.0:3 removed both:
- The
COPY start9/0.4/seed/data /app/seed/dataline in theDockerfile. - The baked-seed branch in
docker_entrypoint.sh.
The empty-schema fallback branch (used only for brand-new sideloads on a host that's never had the package installed) stays.
How to re-seed a future build (rare)
If you want to spin up another instance with this history pre-loaded (e.g. moving to a new StartOS host without using the in-app export/import flow), bring back the bake:
- Refresh the snapshot from the live host:
./start9/0.4/refresh_seed.sh <ssh-target> - Reintroduce the COPY line in the Dockerfile
(
COPY --chown=nextjs:nodejs start9/0.4/seed/data /app/seed/data). - Reintroduce the baked-seed branch in
docker_entrypoint.sh— see the comment in that file referencing v1.0.0:3 for the exact shape. - Rebuild and sideload as a brand new install (the entrypoint's first-boot guard will only seed if /data is empty).
For most "moving to a new instance" cases, the in-app Settings → Export & import my data flow is simpler.