Frequently Asked Questions

CrewWork is an autonomous software delivery platform that runs inside your network. It takes a feature request, a production error, or a quality finding through planning, implementation, validation, and review on infrastructure you control, with models you choose, and it accepts only evidence it produced itself as proof that work is done. You decide what merges.

Technical founders and small B2B engineering teams with production errors and more software work than they can continuously supervise. Private deployment also makes CrewWork a fit for regulated and source-residency-constrained organizations.

CrewWork is built and running as a single-host deployment but is not yet generally available. To talk about your use case and deployment, email the founder at scott@crewwork.ai.

Proposed changes are prepared in isolated workspaces with scoped writes and configurable execution limits, on a separate local branch that is never pushed until you opt in. Review the changes and validation evidence before anything merges.

Run and queue state is saved in Postgres, with checkpoints supporting recovery after interruptions. Workspace locks coordinate repository writes. Configured time, token, and iteration budgets bound execution; repeated identical failures stop after three consecutive occurrences by default, with the count preserved across restarts.

Code intelligence supports Python, JavaScript, TypeScript/TSX, Go, Rust, Java, and C/C++. The code reader, diffs, and logs work with other project languages too. The test engine supports Python, JS/TS, Go, Rust, Ruby, PHP, .NET, JVM projects, and C/C++. Measured coverage is available for Python and JS/TS; support differs by capability.

Automatic error-repair triggers are opt-in and off by default. Set event thresholds, cooldowns, and daily repair budgets per project. Integration health is visible, and a circuit breaker halts ingestion after repeated webhook failures. You can also start work from a specific error or finding.

The default generative model is Qwen3.8 27B, used for planning, coding, review, structured extraction, and chat. Semantic search uses a separate embedding model. Each lane’s model and endpoint can be set separately, so routine work can stay on local hardware while planning or review goes to a larger hosted model. Any OpenAI-compatible endpoint works; local hosting is the default, and public endpoints require explicit opt-in.

The application runs as a Docker Compose stack on one host, including its data services, workers, and observability tools. Model-serving hardware is configured separately. Plan for model capacity, repository storage, backups, and service administration. The Compare page describes the reference setup and the deployment model.

Projects can generate evidence reports covering scans, quality results, releases, and audit history, organized into PCI DSS-oriented and OWASP ASVS-oriented views. These reports organize evidence and do not certify compliance. Project members with read access can inspect them.

CrewMate exposes an MCP server with six read-only tools. External MCP clients can read files, search code, and inspect Git status for a connected project using a scoped API key.

Completion requires admissible evidence from validation the platform ran itself. A model’s own success report cannot satisfy that requirement. Required checks vary with the work and its validation contract; a completed run does not imply that every possible check was run or that every defect has been found.

Integration health and failure reasons are surfaced for inspection. Repeated webhook failures trip a circuit breaker, so ingestion stops until the connection is recovered.

The run records its status and diagnostics, repair attempts stay bounded by configured limits, and the proposed changes stay on their own branch so you can inspect what happened before deciding the next step.