Skip to content

Seed and clear data

Data operations preview by default. Seeding uses a live, authenticated Mainframe. Clearing runs offline with a database lock. Neither requires enabling development fixtures.

Terminal window
bun run deploy seed
bun run deploy seed --apply

For a Mainframe reachable directly, run the application tool with admin credentials in the environment:

Terminal window
bun run data seed --profile staging --url https://mainframe.dev.mainline.inc
bun run data seed --profile staging --url https://mainframe.dev.mainline.inc --apply

MAINFRAME_ADMIN_EMAIL and MAINFRAME_ADMIN_PASSWORD authenticate the operation. Use the current password if it has changed since bootstrap. Remote requests require HTTPS.

Seed files live in apps/mainframe/seeds/staging/ and seeds/dev/. The tool validates their document and fleet schemas, adds missing IDs, and waits for world-sim to confirm each new flight or aircraft. It never targets a hardware fleet. Existing revisions and aircraft are preserved. A retired or offline conflicting identity requires investigation instead of an automatic replacement.

Staging deliberately leaves mission launching to auto-operator. Its seed does not enable Core’s nearest-aircraft dispatch rule, so the demo does not create a second automatic dispatcher.

Take a backup and stop the deployment before applying a clear:

Terminal window
bun run deploy backup
bun run deploy down

Bring up only Postgres with the same project and environment, then preview the clear. The base Compose invocation below preserves the staging volume names through the environment’s project name:

Terminal window
docker compose --env-file deploy/.env.staging -f deploy/compose.yaml up -d postgres
bun run deploy clear --scope history

The preview prints the database identity and row counts. To apply, add --apply --confirm followed by that exact database@host:port identity. The tool refuses the operation while a running Mainframe holds its advisory lock.

Scope Cleared
history Samples, snapshots, rollups, events, and command audit rows
operational Everything above, plus missions, areas, rules, alerts, proposals, pins, airframe definitions, and their document history

Both scopes preserve users, roles, grants, provider keys, entity identities, stream sequences, media/blob indexes, review documents, and map catalogs. Recorded video remains in the bucket. Use media retention when you intend to delete recordings; do not erase the index while leaving unmanaged objects behind.

Restart with bun run deploy up. Seed explicitly if you cleared operational documents. World-sim’s persisted fleet remains separate. Its factory-reset operation removes the simulator overlay; it does not clear Mainframe’s database. Do not reset one side and assume the other was reset too.

Seed production documents without a simulator

Section titled “Seed production documents without a simulator”

Use a reviewed directory containing any of areas.json, missions.json, rules.json, and defs.airframes.json. Each file is an array of documents using the normal collection schema. Omitted collections are left alone.

Terminal window
bun run data seed --url https://mainframe.example.com --seed-dir ./production-seed --documents-only
bun run data seed --url https://mainframe.example.com --seed-dir ./production-seed --documents-only --apply

This mode does not require world-sim or create aircraft. Keep admin credentials in the environment or supported secret files. It uses the same authentication, schema validation, audit trail and revision checks as Terminal; it preserves existing IDs and deliberate deletions. Perform offline history maintenance when aircraft are idle: clearing snapshots also removes the last persisted tasking state.