Skip to main content

​
crewship seed

Replaces the old prisma/seed.ts script. Creates a full demo environment — admin user, workspace, four connected crews, agents with system prompts, credentials, integrations, routines, schedules, and sample issues — entirely through the REST API so business logic (validation, encryption, audit logging) is exercised end-to-end.
On a fresh database, seed bootstraps the admin user (demo@crewship.ai) itself. On an existing database, it requires authentication (run crewship login first) and a selected workspace.

​
Flags

​
Examples

​
First run on a fresh dev DB

The token + workspace are saved to ~/.crewship/cli-config.yaml, so any follow-up command picks up the demo session.

​
Reset and reseed

seed --nuke is an alias for crewship nuke all — the full teardown: DB entities plus inbox items, escalations, and each crew’s docker container(s)+volumes. Cached devcontainer images are preserved, so the reseed reuses them instead of forcing a rebuild. Use the nuke subcommands directly when you want to clear just one thing (e.g. crewship nuke inbox --kind failed_run to drop failed-run spam without touching data). Wipes the active workspace’s contents first, then seeds. Two guards:
  • Auth before nuke — the auth step runs before --nuke, so a typo in --server or a stale token fails before anything is deleted (it can’t trash a different workspace).
  • Typed-slug confirmation — --nuke prints a blast-radius summary (workspace, server, crew/agent counts) and requires you to type the workspace slug exactly before it proceeds. This is the guard against an accidental wipe of the intended workspace.
For CI or scripted resets, pass --yes to skip the prompt:
In a non-interactive session (no TTY), --nuke refuses to run unless --yes is given — it never wipes unattended on a guessed confirmation.
--yes removes the only interactive safety on the most destructive command in the CLI. Reserve it for automation against throwaway/dev instances; never wire it into a script that could point at a real workspace.

​
CI-friendly run that waits

Blocks until every crew is provisioned, then sends one prompt to each agent. Non-zero exit on any failure — drop straight into pnpm test:e2e after this lands.

​
Skip the issue phase for a faster crew-only seed

The issue/project/label phase is the slowest because it inserts dozens of rows and creates realistic issue backlogs; --skip-issues halves wall-clock time for crew-development work.

​
Backup self-test (CI guardrail)

Implies --wait-provision. Picks the first provisioned crew (preferring research because its container is small and dependency-light), runs a backup/restore round-trip via the admin self-test endpoint, and fails the command if the canary doesn’t verify. Use as a CI guard for the backup pipeline.

​
Seed phases (in order)

The async-by-default model means a plain crewship seed returns quickly (~seconds for the API mutations) while crew containers warm up in the background. Pair with crewship crew provision status <slug> to check on individual crews.

​
What the seeded chat surface shows

A fresh workspace is meant to demonstrate the chat features, not ship them switched off, so three of the seven agents come pre-configured: Everyone else falls back to the built-in role packs, which is the behaviour an unconfigured agent has always had — a demo where every agent has chips would say nothing about which ones were written for the job. Report a bug is the seeded ask form: what went wrong, steps to reproduce, severity, first seen, and a screenshot — five fields across five field types, including the photo upload, on the agent whose job is triaging an input into a structured finding. Preview it without a browser:
Both columns are edited afterwards like any other agent field — crewship agent update <slug> --suggested-prompts/--ask-forms, or the agent’s config tab. The definitions live in cmd/crewship/seeddata/builtin/agents.yaml and cmd/crewship/seeddata/askforms/*.json; the seed’s own tests validate every form against internal/askforms before it can ship, so an invalid one is a red go test rather than a 400 mid-seed.
POST /api/v1/agents does not model suggested_prompts or ask_forms — a create carrying them returns 201 and drops them. The seed therefore issues one follow-up PATCH per agent that has either, which is also how the manifest importer handles it (crewship apply). The PATCH runs on a re-seed too, so an existing demo workspace picks the values up on the next crewship seed.

​
Common errors

  • bootstrap request failed (is the server running at http://localhost:8080?) — the server didn’t answer. Start it with crewship start and retry.
  • **DB already initialized. not logged in — run \crewship login` first** — the database has a user but the CLI has no token. Log in (or use crewship admin reset-password` if you’ve lost UI access).
  • --test-backup requested, but no crew successfully started provisioning — every crew failed to trigger provisioning. The seed wasn’t going to be useful anyway; the explicit error is so CI doesn’t go green on a broken pipeline.
  • Routine seeding hit an error (continuing): … — printed but non-fatal. Routines depend only on crews, so a parse error in one DSL doesn’t torpedo the rest of the seed.

​
See also

  • crewship init — minimal admin-only bootstrap if you don’t want demo data.
  • crewship setup — interactive template picker for a single-crew workspace.
  • crewship crew — crewship crew provision status <slug> for checking background builds.
  • crewship apply — declarative manifest as a longer-term alternative to seed.