Skip to main content

Environment Variables

All Crewship configuration can be set via environment variables. These override values from the YAML config file. The mapping is defined in applyEnvOverrides in internal/config/config.go.
As of PR #446, no env vars are required for first boot — secrets are auto-generated and persisted. Set variables here only to override a default or hand a secret to an external manager. Jump to a group: Server · Container · Storage · Auth · Encryption · Keeper · CLI client · Installer.

Server

IPC

Container

Runtime image pinning

Before starting a crew container, Crewship resolves the runtime image tag to an OCI manifest digest (a registry HEAD) and then pulls that digest, not the tag. A tag can be repointed between the check and the fetch; a digest cannot. The digest is recorded on the crew’s provisioning.step journal entry (payload.digest, plus payload.pinned), stamped with the run’s trace_id, so the audit trail can answer which image produced this run. Read it back with:
No new endpoint or command was needed for this — the digest rides the existing provisioning.step payload, which crewship journal already returns. Offline and air-gapped installs are unaffected. When the registry cannot be reached at all, the digest lookup returns nothing and Crewship keeps using the local copy exactly as before — it just logs the local digest alongside, so even an offline run is attributable. When the pull fails but the registry answered. This is the one case that changed. Reaching a pull with a local copy present means the registry did answer the digest check and the local image is a different manifest than the tag now names — provable drift, not a guess. Crewship refuses to start the container rather than silently running the wrong image:
The most common cause is a registry rate limit (Docker Hub answers HEAD generously and throttles blob pulls). If you would rather keep running on the older image than stop the fleet, set CREWSHIP_ALLOW_STALE_RUNTIME_IMAGE=1. The journal then records the local digest — what actually ran — not the one that was wanted, and each start logs a warning naming both. Locally built devcontainer cache images (crewship-cache:*) exist in no registry and therefore have no digest. Their provisioning.step rows omit the digest key entirely; their provenance is the base image recorded on the build’s own steps.

Set by Crewship inside the container

These are not configuration — Crewship sets them on the crew container itself, and an agent (or a postCreateCommand) can read them.
CREWSHIP_CONTAINER_PREFIX is essential for multi-instance deployments. Without it, multiple Crewship instances will create containers with colliding names like crewship-team-engineering.

Storage

State

Public-facing URL

Origin enforcement (CORS / EnforceOrigin)

Rate limiting & proxy trust

Metrics

Webhooks / hooks (SSRF guard)

Profiling & observability

These are off by default and intended for operators debugging performance.

Crash reporting (Sentry)

Email (password recovery)

Google sign-in (optional)

Logging

CLI and runtime context

These names are used by CLI commands, test harnesses, or the agent runtime rather than by the server’s main YAML configuration. They are listed here so a deployment or script can distinguish an intentional context variable from a typo.

Authentication

As of PR #446 (internal/secrets), the three persisted secrets — ENCRYPTION_KEY, NEXTAUTH_SECRET, and CREWSHIP_ADMIN_TOKEN_HMAC_KEY (the managed list in internal/secrets/bootstrap.go) — are bootstrapped on first start: missing values are generated with crypto/rand, persisted atomically to <dataDir>/secrets.env at mode 0600, and re-exported into the process environment so existing os.Getenv call sites see them unchanged. Explicit env vars override the file; partial persistence is handled (one missing key is filled, the other valid keys are preserved). CREWSHIP_INTERNAL_TOKEN is handled separately — the config loader generates it per boot when unset and does not persist it, so it rotates on each restart. For clustered deployments, set all four explicitly via your secret manager.

Auto-Derived Values

  • CREWSHIP_NEXTJS_URL: If not explicitly set, defaults to http://localhost:{CREWSHIP_PORT}. In single-binary mode, the internal resolver calls itself on the same port.
  • CREWSHIP_INTERNAL_TOKEN: Generated fresh per boot by the config loader when unset; not persisted, so it rotates on restart. Pin it explicitly only for multi-instance IPC bus sharing.

Encryption

Composio integrations

Keeper (AI Security Gatekeeper)

Setting KEEPER_OLLAMA_URL auto-enables Keeper (unless KEEPER_ENABLED is explicitly false). This means you only need to set the URL to activate Keeper.

Local models (coding agents)

LLM Proxy

Paymaster (Billing Modes)

These variables tag every cost-ledger row written from inside an agent run. The orchestrator sets them on the agent’s environment from the credential type before exec; the sidecar reads them once at startup and includes them on every POST /api/v1/internal/cost/record call.
Operators do not set these manually for normal use. They are propagated automatically based on the credential’s auth type (API key → metered, OAuth/subscription → flat_rate). They are listed here only for sidecar-image authors and tooling that intercepts the orchestrator handoff.
See Paymaster for the full billing-mode model and Migrations for the v62 cost-ledger schema.

Ollama (Episodic Memory + Keeper)

Feature toggles & runtime tuning

Backup webhooks

Operational skip flags (dev / CI)

These bypass safety or convenience behaviours. Never set them in production.

License

Seed Data

These variables are used by the ./dev.sh seed command:

Container Runtime

The Docker provider checks DOCKER_HOST first, then auto-detects from candidate socket paths.

Devcontainer Cache GC

Crewship runs a background sweeper every 30 minutes that detects three kinds of leaks: temporary provisioning containers orphaned by a crewshipd crash (matched by the crewship-provision-* name and the crewship.temp=provision label — see Devcontainers → Background GC for why the name is the one that authorises deletion), unreferenced crewship-cache:* images left behind when the process is killed between docker commit and the database write that links the image to a crew, and intermediate crewship-feat:* BuildKit feature images (per-feature layers that are regenerable and never directly referenced by a crew row). Temp containers older than one hour are always removed. Cache and feature images are logged only by default; deletion must be explicitly enabled. A 5-minute age floor protects images that were committed in the last few minutes (closing the race between docker commit and the DB update inside Provision()), so enabling auto-delete is safe even on busy systems.
Leave CREWSHIP_CACHE_GC_AUTODELETE unset on developer machines. Enable it on long-running production hosts where reclaiming disk matters more than preserving incidental cached images. Inspect the orphan list in the logs first to verify nothing important would be removed.

CLI client

These configure the crewship CLI on a developer/operator machine (not the server). They override values in ~/.crewship/cli-config.yaml. Resolution order and parsing live in internal/cli/config.go.

Installer

Read by scripts/install.sh (the curl … | bash install path), not by the running server.

Complete Example

Validation

The config is validated at startup (Config.Validate). These constraints are enforced: