Skip to main content

crewship system

Show system information including container runtime, license, and Keeper security status.

Subcommands


crewship system info

Show container runtime details and license information.
Runtime output: Available, Runtime name, Version, Socket path — and, when more than one runtime answered, a Detected: inventory with the one being driven marked (in use).
Installed and in use are different facts, and the inventory is the only place that tells them apart. There is no setting that names a runtime: container.provider accepts docker, apple or auto only, so the two ways to change which one is driven are to point DOCKER_HOST at the socket you want, or to stop the daemon that currently wins the probe order.
License output: Edition, Max crews, Max agents/crew, Max members, Licensee. With --format json|yaml|ndjson the command emits a structured payload (runtime + optional license key; license is omitted when the endpoint is unavailable). The same applies to system keeper, system stats, and system onboarding status. The runtime object carries the endpoint’s full inventory — runtimes[] with in_use per entry, and install_links, the map of every runtime Crewship can drive to where you get it:
runtime / version / socket are empty when runtimes are installed but none is in use — the server booted without a container provider (crewship start --no-docker). The human output says so rather than printing blanks. When nothing answered at all, system info names what it probed and prints the install links instead of empty fields.
Host detail (runtime name, version, socket) is ADMIN-gated: the server sends it only to an ADMIN or OWNER of the workspace on the request, and answers everyone else with a bare {"available": true} (#865). With no workspace selected, or a role below ADMIN in the selected one, the command says that rather than rendering the redaction as “no runtime detected”. Select a workspace you administer (crewship workspace use <slug>) or pass --workspace.
containerd and nerdctl are not runtimes Crewship can use, and neither system info nor doctor names them. containerd serves its own gRPC API over HTTP/2 while Crewship’s client speaks the Docker REST API over HTTP/1.1, so no version of either can answer a probe. If you are on a containerd host, run Docker Engine, podman system service, or switch Rancher Desktop’s container engine to dockerd (moby) — restarting containerd cannot help.

crewship system keeper

Show Keeper security system status.
Output: Status (enabled/disabled), Ollama URL, Model, Ollama status (online/offline), Secret credential count (the active workspace’s SECRET-type credentials that are ACTIVE and not deleted — the set the Keeper SecretStore manages).
Keeper status is workspace-scoped and requires the ADMIN or OWNER role in the active workspace — the Ollama endpoint/model and request counts are operational data, not exposed to every member. The request stats you see are scoped to that workspace’s agents.A MEMBER gets a 403 explaining the role requirement; run the command against a workspace where you’re an admin (crewship workspace use <slug> or --workspace <slug>). If no workspace is set at all, the CLI stops early with a “no workspace set” error rather than calling the server.

crewship system stats

Show admin-level statistics.
Output: Workspaces, Users, Agents, Running agents.

crewship system onboarding

Inspect or drive the onboarding wizard for the current user. The bare crewship system onboarding invocation delegates to status for backwards compatibility with scripts that pre-date the subcommands.

Subcommands

crewship system onboarding status

Show whether onboarding is complete for the current user. Hits GET /api/v1/onboarding/status. Output defaults to JSON (the raw API payload); --format yaml/ndjson is honored.

crewship system onboarding setup

Provision a starter crew, agent, and LLM credential in one shot — the headless equivalent of the web onboarding wizard. POST /api/v1/onboarding/setup. --crew and --agent are required.
Pipe the key on stdin with --credential-value-stdin rather than passing --credential-value — the latter is visible in ps and shell history.

crewship system onboarding complete

Mark onboarding as completed for the current user without running the setup wizard. Useful when a workspace was provisioned through other channels (CLI agent create, restore from backup).

crewship system aux-status

Show which model judges each auxiliary subsystem — the credential-access judge, skill review, the behaviour monitor, memory health, negative lessons, run summaries — and whether that model can actually run. Same surface the admin console’s Judge models card reads.
Requires the ADMIN or OWNER role in the active workspace — the resolved provider/model/timeout matrix is operator configuration, not for every workspace member to enumerate. A MEMBER gets a 403, same as system keeper above.
Source column — how the subsystem’s model was resolved: Status column — a different question from source: not is this configured but can it run. Sample output:
Anything that cannot run is listed underneath with the server’s own reason — a red status with no reason is not actionable. The timeout column renders in seconds when >=1s and milliseconds below that, so the 3-30s span the MVP defaults use stays readable without mental math.
Against a server older than the subsystems reshape (which still answers with the previous {"slots": […]} payload) the command errors rather than printing an empty table — an empty table reads as “nothing configured”, which is the opposite of the truth. Upgrade the server, or run a CLI from the same release.

crewship system log-level

Show or change the server’s log level at runtime — no restart needed. Backs GET/PUT /api/v1/admin/log-level (OWNER/ADMIN). The change takes effect on the live logger immediately, so you can flip a misbehaving instance to debug, catch the repro, and revert — without a restart that would lose the state you’re trying to observe.
--ttl exists for a reason: a forgotten debug on a busy instance is a firehose that can itself fill the disk. Prefer a bounded window (--ttl 15m) over an open-ended flip.
Output fields: level (live), baseline (the configured level it reverts to), expires_at (RFC3339, present only while a timed override is active).

crewship system health

Report the running server’s uptime, current log level, and disk headroom for the data-dir volume. Backs GET /api/v1/admin/health (OWNER/ADMIN). The disk figure is the signal that flags a filling volume before it hits 100%.
disk reports total_bytes / free_bytes / used_bytes / used_pct for the default data-dir filesystem (free_bytes matches df “Avail”). A custom DATABASE_URL on a different volume isn’t reflected — the default location is the volume that fills in practice (DB + agent outputs + logs all live under it).

crewship system openapi

Fetch GET /openapi.json from the target server and write it to stdout unchanged. Aliased as system spec.
The spec is generated from the server’s actual route registrations, so it always matches the instance you’re pointed at — paths, methods and path parameters are exact. Request/response bodies use a generic placeholder schema: it’s a route contract, not a hand-authored data model. Output is a byte-for-byte passthrough — the spec is the artifact, so it isn’t reformatted. If the server answers with a non-JSON content type (the SPA catch-all serving index.html, which is what a build without the spec route does) the command fails loudly rather than writing an HTML page into your openapi.json.
Regenerating the embedded spec after adding or renaming a server route is a maintainer step: go generate ./internal/api/. A stale spec silently under-reports the API to anything using it as the contract.

See also